Start with a field contract
An import, demo request or stale account starts this workflow. Its output is a usable record with field-level provenance, not a bigger collection of personal data. Each field has an owner, acceptable sources, a freshness rule and permission to overwrite. An existing customer and an unmatched new domain need different treatment.
For a company record, the contract might require canonical domain, business model, employee range and territory. Contact requirements depend on the job. Account research does not need a personal mobile number. Routing should use the existing owner immediately when possible instead of waiting for every enrichment call.
Run the waterfall
- Normalize identifiers and look up contacts, companies, customers and open opportunities. Preserve the original submitted value for inspection.
- Resolve parent company and subsidiary separately. A shared parent is not permission to merge two legal entities or territories.
- Apply the ICP and exclusion rules before paid lookups. Stop ineligible accounts and honor contact suppression.
- Read trusted CRM values and freshness. Create a per-field gap list. A whole-record “enriched” flag hides partial failures.
- Try the lowest-cost approved source that meets the field's quality bar. Evaluate the returned evidence, not merely a nonempty response.
- Fall back only for remaining gaps. Cap attempts and spend per record. A provider timeout is an error, not evidence that a person does not exist.
- Keep conflicting values in an exception queue. Prefer an authoritative current source over a confident AI guess. Do not overwrite an owner-maintained field automatically.
- Write accepted fields with source, observed date and job version. Mark the processed event so writeback cannot trigger an endless enrichment loop.
What the record should show
- Company domain
- example.test, matched to an existing company
- Industry
- Infrastructure software, verified on company site
- Employee range
- Unknown; provider values conflict
- Next action
- Retain owner. Review the conflicting size field.
- Cost control
- Only missing required fields were eligible for lookup.
“Unknown” is a valid outcome. It should remain visible in both scoring and the sales brief. Inferring an employee range from a polished website gives the CRM an invented fact.
Exceptions that change the path
| Situation | Decision |
|---|---|
| Customer or open deal exists | Keep the owner; enrich only the allowed gaps |
| Two domains may be the same company | Hold the association for review |
| Field is protected or newer than the provider | Keep it and log the rejected update |
| Provider budget is exhausted | Queue remaining gaps with a retry time |
| Email is catch-all or unverified | Keep the verification state; do not call it deliverable |
Test before connecting the CRM
Replay a complete record, an excluded company, a duplicate event, a timeout and a conflicting field. Verify that a second run makes no additional writes or paid calls for fields already accepted. Test a partial success followed by retry: it must resume missing fields, not start the entire waterfall again.
Track cost per accepted field, coverage of required fields, conflict rate and routing delay. A high fill rate is useful only if the data is accurate enough for the next decision. Our enrichment evaluation separates tested logic from provider coverage that still needs an account-level trial.
Tool choices
Use your CRM's existing data and actions first. A waterfall layer becomes useful when gaps require multiple sources and controlled fallback. Clay documents its waterfall behavior; test its providers, credit use and overwrite rules on your sample before choosing it. This is a reference design, not a claim of a completed Clay implementation.
Publication and source record
Published on GTMhub: . Last reviewed: .