The Short Answer
- Clay enrichment is a pipeline inside a Clay table that chains data providers to fill sparse lead records with firmographics, verified contacts, technographics and intent signals.
- A waterfall stops querying providers the moment a valid result returns, controlling credit spend but not guaranteeing data accuracy.
- Clay Functions let RevOps encode enrichment logic once and call it as a single column in any table, replacing per-table rebuilds when providers change.
- What the workflow measures directly (did a provider return a field?) differs from what it infers (is this company growing based on hiring signals?). Both should be labeled accordingly in any CRM or scoring model.
- Without a stable primary key and a Raw/Enriched/Verified table structure, enrichment writes can overwrite CRM records or produce duplicate contacts on sync.
Clay enrichment is the process of routing lead and account records through a sequence of data providers inside a Clay table to fill in missing firmographics, verified contact details, technographics and intent signals. A clay enrichment workflow guarantees only that one or more providers responded to a query about a given input record, not that the returned data is accurate or current. This article documents how to design a clay enrichment workflow for production outbound, how waterfall sequencing controls cost, how Clay Functions standardize logic across tables, and where governance breaks in workflows that scale to thousands of rows.
What Clay Enrichment Measures Directly and What It Only Infers
Clay enrichment measures one thing directly: whether a configured provider returned a value for a given input field. A provider that processes a LinkedIn URL and writes a work email to the output column records a hit; a provider that times out or returns an empty result records a miss. The hit-or-miss run status per row is what RevOps teams should monitor in production, not just whether an output column is populated.
What enrichment infers is materially different. When Clay pulls hiring activity and a downstream formula flags that a company added ten engineers in 90 days, that flag is an inference built on measured hiring events. It’s a proxy for growth, not a confirmed purchase signal. Most “intent” data inside a clay enrichment workflow falls into this category: technographic stack changes, funding rounds, and org-chart shifts that a provider labels as buying signals. They’re correlates of intent, not direct observations of it.
What clay enrichment cannot see is equally important to document. Clay enrichment has no access to first-party behavioral data from your own product or website unless you pipe that data in as a seed field. It can’t confirm that a returned phone number is the person’s current direct line. It can’t verify that a job title reflects real budget authority. RevOps teams that treat inferred fields as measured facts build qualification and routing logic that looks correct in testing and produces wrong results at scale.
Clay’s enrichment documentation describes the setup as selecting an integration, connecting provider credentials, and configuring run settings inside a Clay table. The configuration step is mechanical. The harder judgment call is deciding which returned fields to label as measured data and which to flag as inferences before they reach a CRM property or a scoring model.
The Four Components of a Clay Enrichment Workflow
A clay enrichment workflow has four moving parts: the input rows, the enrichment steps, the run settings, and the output columns. You need to understand all four before building a workflow that will run reliably in production without manual intervention after every provider update.
The input is any row in a Clay table. Rows arrive from a CSV upload, a webhook payload from a CRM or form tool, or a manual entry. Clay accepts company domains, LinkedIn URLs, work emails, full names paired with company names, and company names alone as seed identifiers. The richer the seed, the higher the resolution rate at each enrichment step. A domain plus a LinkedIn URL resolves to a unique person or company far more reliably than a company name alone, which can match dozens of entities in a provider’s database.
Enrichment steps are added via the Add enrichment control inside a Clay table. According to Clay’s integration overview, you select a provider integration, connect your provider account (or use Clay’s own API keys for supported providers), and map the provider’s output fields to columns in your table. Each enrichment step runs as a separate column that stores both the returned value and the run status. The run status is the operational signal, not just the populated field value.
Run settings determine when a step fires. Per-row triggering runs enrichment as each new row arrives, which is the standard pattern for inbound lead workflows. Batch triggering runs enrichment across a set of rows on demand or on a schedule, which is standard for outbound list processing. Output columns should be named to match CRM field API names from the start, not display labels, to avoid remapping when the CRM write-back step is added.
How Clay Enrichment Waterfalls Sequence Providers and Control Credit Spend
A clay enrichment waterfall chains multiple providers for the same field so that if provider A fails to return a result, the workflow automatically tries provider B, then C. The waterfall stops the moment any provider returns a valid result. This stop-on-match design controls credit spend: if Apollo finds a work email in the first waterfall position, no LeadIQ or LeadMagic credit is consumed on that row.
Documented outbound workflows sequence providers in estimated cost-per-match order, putting the provider with the widest coverage for the target audience first. The correct ordering depends on which providers your team has contracted and which return better hit rates for your specific target industry or geography. A common documented pattern for B2B outbound places Apollo first for broad company and contact coverage, LeadMagic as a secondary step for domain-level contact discovery, and LeadIQ as a tertiary fallback. Claygent, Clay’s own AI research agent, typically sits at the tail of the waterfall for rows where no structured provider matched.
Apollo appears in documented multi-step outbound enrichment workflows for both company-level enrichment (headcount, funding, technographics) and contact-level enrichment (title, LinkedIn URL, email). LeadIQ is available as a direct integration inside Clay’s integrations directory and is configured through the standard Add enrichment flow. LeadMagic is added in Clay workspace settings and placed as a waterfall column to populate verified contact data automatically. Claygent handles custom research for rows where structured providers return nothing, using AI to research public sources for the missing fields.
Email verification is not a waterfall stage. A provider returning an email means only that it found a record match in its database, not that the address is currently deliverable. A separate verification step against a dedicated email verification tool must run after the waterfall and before any export to a sequencer.
| Provider | What it measures directly | What it infers | Primary use in a waterfall |
|---|---|---|---|
| Apollo | Email, title, LinkedIn URL returned from Apollo’s database on a given domain or URL input | Company growth stage from headcount and funding data in its database | First-pass company and contact enrichment on most outbound lists |
| LeadIQ | Contact data returned from LeadIQ’s network against a company or person input | Buying signals inferred from role change and company event activity | Secondary email fallback when Apollo returns no result for a row |
| LeadMagic | Verified B2B email returned against a domain-level contact lookup | Contact relevance inferred from job title matching logic | Mid-waterfall step for domain-level contact discovery gaps |
| Claygent | Custom field value returned by AI research against public web sources | Qualification context inferred from unstructured web content about the company or person | Final-stage fallback for rows no structured provider matched |
How Clay Functions Standardize Enrichment Logic Across Multiple Tables
Clay Functions define enrichment logic once, in a dedicated table, and expose it as a single column callable from any other Clay table. Clay’s Functions page describes them as a way to replace per-table rebuilds when providers change: without Functions, every new Clay table that needs company firmographics requires the same enrichment steps to be rebuilt from scratch, and a change to the Apollo field mapping in one table does not propagate to others.
A Clay Function accepts defined inputs (a company domain, a person LinkedIn URL, a full name and company name combination) and chains enrichment steps, conditional logic, nested functions, and AI agents inside its own table. When the function runs, it executes the full sequence and returns structured output fields to the calling table. The calling table sees one column per output field rather than the full intermediate chain. Clay positions this as building a workflow once and applying it many times without creating column bloat in individual tables.
Claygent can be included as a step inside a Clay Function. The recommended pattern is to place Claygent near the end of the function, after structured providers have run, so it only fires on rows where the standard waterfall returned nothing. Because Claygent uses AI to research custom fields from public sources, it runs slower and costs more per row than a direct API call to a structured provider. Calling it on every row rather than only on enrichment misses is one of the most common causes of unexpectedly high AI credit consumption in production clay enrichment pipelines.
For RevOps teams running both inbound automation and outbound campaigns, Functions create a shared enrichment library. The inbound lead flow and the outbound prospecting table can call the same company firmographic Function and receive identical, consistently structured output. When a provider changes its field names or a new provider replaces an old one, updating the Function propagates the change to all tables that call it.
How to Connect Clay Enrichment to HubSpot, Salesforce, and Sequencers
Clay enrichment integrates with HubSpot and Salesforce in two directions: the CRM pushes new lead records to Clay via webhook for enrichment, and Clay writes enriched values back to the CRM via Clay’s HTTP API. Both directions require deliberate design to avoid overwriting previously accurate CRM fields with blank or stale enrichment output.
HubSpot and Salesforce push new contact records to Clay via webhook. When a new contact is created, an automation rule sends the record’s available fields (email, company name, domain) to a Clay table webhook endpoint. Clay receives the payload, maps the fields to table columns, and runs the configured enrichment steps. Clay’s inbound automation documentation shows this pattern applied to end-to-end inbound workflows: a Typeform submission with only name and email triggers a Clay table that enriches company domain, firmographics, contact details, lead scoring and AI copy before routing back to the CRM or sequencer.
Clay writes enriched values back to HubSpot or Salesforce using Clay’s HTTP API integration. After enrichment and scoring logic complete, a Clay step fires an API call to the matching HubSpot or Salesforce object and writes enriched values to the correct CRM properties. A Clay community post on HubSpot and Salesforce integration describes this pattern as enabling an on-demand enrichment button inside the CRM, where a RevOps team member triggers a fresh enrichment run from the CRM UI without opening Clay.
For sequencer connections (Instantly, LemList and similar tools), the output is either a webhook push to a sequencer that accepts it directly, or a CSV export of enriched and verified contacts. In both cases, the sequencer should receive only rows that passed email verification. Exporting unverified rows from an enriched list to a sequencer is a deliverability risk, not a Clay limitation.
Note: Salesforce write-back steps require Clay output column names to match Salesforce field API names exactly, not display labels. A mismatch writes nothing to the CRM record and may not surface a visible error in the Clay table.
Clay Enrichment Governance: Failure Modes, Cost Monitoring, and the Three-Layer Table Structure
Production clay enrichment workflows fail in predictable places, and most failures are silent. Identity resolution fails when the seed identifier is ambiguous: a company name without a domain resolves to the wrong entity in a provider’s database, or fails to resolve at all. Provider API timeouts leave a row with a blank output and a failed run status. Schema changes at the provider level break downstream Clay formulas and CRM write-back steps without throwing a visible error in the sequencer or CRM UI.
The three-layer table architecture that reduces these risks uses Raw, Enriched, and Verified tables. The Raw table holds source records exactly as received, with no modifications. The Enriched table copies from Raw and adds all enrichment output columns, tracking run status per enrichment step. The Verified table holds only rows that passed all required enrichment gates, including email verification. A stable primary key, typically the work email or a CRM object ID, must be consistent across all three layers to prevent duplicate records when data syncs back to a CRM.
Cost monitoring starts with tracking provider credit consumption per workflow run. Clay shows run status per row, so you can calculate cost-per-enriched-row by dividing total credits consumed by rows that returned a valid result, not by total rows processed. A rising failure rate against a fixed list often signals degrading input quality: stale LinkedIn URLs, wrong domains, or low-quality source data from the original prospecting step.
Rollback planning matters for any clay enrichment workflow that feeds a live CRM automation. When a Clay Function or enrichment column breaks due to a provider API change, tables that depend on that column stop receiving data. The fix is rarely immediate. Any CRM automation built directly on a Clay enrichment column should include a fallback condition so that a blank Clay output does not overwrite a CRM field that was previously populated from an earlier enrichment run.
Key Takeaways
- A waterfall stopping on the first valid result controls credit spend but does not mean the returned value is accurate. Email verification is a required separate step after the waterfall, not a stage inside it.
- Clay Functions propagate changes to all tables that call them, including live inbound workflows. Updating a Function without testing downstream effects first can break active lead routing or scoring logic.
- Claygent costs more per row than a structured API call. Triggering it on every row rather than only on enrichment misses can exhaust AI credits faster than credit estimates suggest.
- Identity resolution quality depends on seed input richness. A company name alone resolves to the wrong entity more often than a domain plus LinkedIn URL, regardless of which providers are in the waterfall.
- CRM write-back field mismatches are silent. A mismatched API field name or a Clay step timeout writes nothing to the CRM record without surfacing a visible error in the sequencer or CRM dashboard.
- The three-layer Raw/Enriched/Verified structure is not optional at scale. Without it, a partial enrichment run or a provider outage can overwrite previously clean CRM data with empty fields.
Clay enrichment is a data infrastructure problem before it is a provider selection problem. Which providers you chain in a waterfall matters less than whether your table architecture separates raw from verified data, your primary keys are stable across layers, and your Clay Functions are maintained as the providers they depend on update their APIs. The measure-vs-infer distinction is not academic: RevOps teams that label inferred fields (hiring signals, tech stack changes, funding-as-intent) as measured facts will build qualification and routing logic that produces wrong results at pipeline scale. The governance patterns documented in this article, including Raw/Enriched/Verified layers, run status tracking, and rollback conditions, are what separate a clay enrichment workflow that runs reliably in production from one that requires manual repair after every provider change.
Frequently Asked Questions
What are the core stages of a Clay enrichment workflow for B2B outbound?
The core stages are: input (a CSV or webhook carrying seed identifiers such as LinkedIn URLs or domains), enrichment (a multi-provider waterfall that stops on the first valid result per field), validation (a separate email verification step after the waterfall), and output (CRM sync or verified-only export to a sequencer).
How do Clay Functions help standardize enrichment workflows across multiple tables?
Clay Functions define inputs, provider steps, conditional logic and AI steps in one dedicated table. Any other Clay table calls the function as a single column and receives structured outputs. Updates to provider logic are made once in the function and propagate to every table that calls it, avoiding per-table rebuilds when a provider changes its API or field names.
Which enrichment providers can you chain together inside Clay for a waterfall?
Apollo, LeadIQ, LeadMagic and Claygent are all available as enrichment providers inside Clay. A typical email waterfall places Apollo or LeadMagic first for coverage, LeadIQ as a secondary fallback, and Claygent last for rows where structured providers return no result. The correct ordering depends on which providers your team has contracted and their hit rates for your target audience.
How should RevOps teams design separate Raw, Enriched and Verified tables in Clay?
Keep the Raw table as an unmodified copy of source records. Copy rows to the Enriched table and add all enrichment output columns with per-step run status tracking. Promote only rows that pass all required enrichment gates to the Verified table. A stable primary key, typically work email or CRM object ID, must be consistent across all three layers.
How can Clay enrichment workflows be triggered from HubSpot or Salesforce?
A HubSpot or Salesforce automation sends new contact records to a Clay table via webhook when a trigger condition fires. Clay enriches the record and writes results back to the CRM via Clay’s HTTP API, enabling an on-demand enrichment pattern that a RevOps team member can trigger from inside the CRM without opening Clay directly.
Prices, limits and product capabilities were checked on 2026-09-02 and change without notice. Nothing here is a prediction of results for your list, domain or market.
