Waterfall Enrichment Explained: How to Build a Reliable Multi-Source Data Pipeline

This creates a fundamental problem for B2B data infrastructure: what should the system do when the first source cannot provide a reliable answer?

The common answer is to add another provider, then another, then another. But simply connecting more providers does not create a data system. It creates a collection of data sources. Waterfall enrichment provides a more structured approach. Instead of depending on one source, the system checks multiple sources in a defined order, applies validation and acceptance rules, and stops when it has a sufficiently trustworthy result.

DATA REQUIREMENT

↓

SOURCE SELECTION

↓

ENTITY MATCHING

↓

DATA RETRIEVAL

↓

VALIDATION

↓

ACCEPT / REJECT / REVIEW

↓

PROVENANCE

↓

FINAL VALUE

The goal is not to collect more data. The goal is to produce the best available data for the decision the system needs to make.

1. One Data Source Is Not the Market

A data provider is a view of the market, not the market itself. Provider coverage varies significantly across dimensions. A source with excellent coverage of US enterprise accounts in established industries may have weak coverage for smaller companies, emerging markets, niche industries, recently changed employees, or newly created organizations. The same asymmetry applies across data types — one source may be strong for company information, another for professional and contact data, another for technology data.

Salesforce describes enrichment as adding information from trusted sources to make existing data more complete, current, or useful, and recognizes first-party, second-party, third-party, and calculated enrichment as different approaches. A data system should not assume that one source contains everything it needs to know.

2. What Is Data Enrichment?

Data enrichment is the process of improving an existing record by adding information from another trusted source. The purpose can be to make the data more complete, more current, more accurate, more contextual, or more useful for a particular decision.

Salesforce places enrichment within a broader data-quality process and notes that enrichment can address missing values, stale information, limited context, and information that exists elsewhere but is unavailable where it is needed.

An existing account record might contain a company name, an employee count estimate, and a broad industry classification. Enrichment might add revenue range, technology environment, headquarters, subsidiary relationships, executive contacts, current employee roles, or hiring activity. But enrichment is not simply a matter of adding more fields. The objective is to improve the record's ability to support a decision, and that shapes how a waterfall should be designed.

3. What Is Waterfall Enrichment?

Waterfall enrichment is a multi-source enrichment strategy in which the system checks sources sequentially according to predefined rules:

SOURCE A

↓

VALID RESULT?

├── YES → ACCEPT

└── NO

     ↓

SOURCE B

     ↓

VALID RESULT?

├── YES → ACCEPT

└── NO

     ↓

SOURCE C

     ↓

VALID RESULT?

├── YES → ACCEPT

└── NO

     ↓

REVIEW / UNRESOLVED

Apollo's current implementation follows this basic model: when its own data does not provide the requested email or phone number, it checks connected third-party sources in a configured order until an acceptable result is found, with optional validation.

The key word is sequence. A waterfall is not simply Provider A plus Provider B plus Provider C. It is Provider A, then a decision, then Provider B, then a decision, then Provider C, then a decision. That makes the waterfall an operational policy rather than a vendor list.

4. Why Single-Source Enrichment Breaks

Suppose a system needs verified business emails for 100,000 contacts. The first provider returns 62,000, leaving 38,000 unresolved. A second source resolves another 17,000, bringing the total to 79,000. A third source resolves another 8,000, reaching 87,000 potentially usable records.

The point is not that three providers are always better than one. The point is that coverage differs by source, and a waterfall allows the system to exploit those differences without querying every provider for every record:

PRIMARY SOURCE

↓

UNRESOLVED RECORDS

↓

SECONDARY SOURCE

↓

REMAINING GAPS

↓

SPECIALIZED SOURCE

↓

REMAINING GAPS

↓

REVIEW

The system spends additional effort only where the previous source did not produce an acceptable answer — a more efficient architecture than querying all sources in parallel and reconciling the results afterward.

5. Coverage Is Not Accuracy

One of the most consequential tradeoffs in enrichment design is between raw coverage and usable coverage. A provider returning 80% of records with lower confidence is not automatically better than a provider returning 60% with high confidence. Choosing the broader provider because it returns more records may improve coverage while reducing trust.

The real objective is to maximize usable coverage, not raw coverage:

RAW COVERAGE

↓

VALIDATION

↓

ACCEPTED COVERAGE

↓

ACTIVATION-READY COVERAGE

A record returned by a provider is not automatically a good record. It becomes useful only after it passes the quality requirements of the intended workflow.

6. A Waterfall Is a Fallback Strategy

A waterfall defines a fallback sequence rather than a provider accumulation strategy:

PRIMARY SOURCE

↓

If no acceptable result

↓

SECONDARY SOURCE

↓

If no acceptable result

↓

SPECIALIST SOURCE

↓

If no acceptable result

↓

REVIEW / UNRESOLVED

Three reasons make this distinction matter operationally. Cost: there is no reason to pay multiple providers to answer a question the first provider already answered adequately. Consistency: the system needs a predictable rule for where data came from. Governance: the system needs to know why one value was accepted over another. A waterfall should be designed around fallback logic, not provider accumulation.

7. The First Result Is Not Always the Best Result

A naive waterfall might accept any value a provider returns and stop. A better system asks whether the returned value meets the acceptance criteria:

SOURCE

↓

CANDIDATE VALUE

↓

VALIDATION

├── PASS → ACCEPT

├── FAIL → NEXT SOURCE

└── UNKNOWN → REVIEW / NEXT SOURCE

A source returning a value is evidence that a candidate exists. It is not proof that the candidate is correct, current, complete, relevant, or valid for the intended use. Apollo's current implementation explicitly supports an optional validator and distinguishes between data returned by a provider and data that has passed additional validation. That distinction should exist in the architecture regardless of which tool handles it.

8. Acceptance Rules Come Before Provider Order

Before deciding which provider to query first, the waterfall needs to define what counts as an acceptable result. For an email field, acceptance might require correct syntax, a valid domain, current employment confirmation, a non-suppressed contact, and a minimum confidence threshold. For an industry field, acceptance might require a recognized classification system, a sufficiently recent source, a confirmed entity match, and acceptable confidence. For a phone number, acceptance might require correct person, correct country code, a valid number format, and currency for the intended workflow.

The architecture should start with field requirements, not provider selection:

FIELD

↓

QUALITY REQUIREMENT

↓

ACCEPTANCE RULE

↓

SOURCE ORDER

The quality requirement is what determines whether the waterfall has succeeded for a given field. Provider order is a downstream decision that follows from it.

9. Enrichment Should Be Field-Level

A record does not need one universal source of truth. Different fields may have different best sources:

RECORD

├── Company Name     → Source A

├── Industry         → Source B

├── Employee Count   → Source C

├── Technology       → Source D

├── Job Title        → Source E

├── Email            → Source F

└── Phone            → Source G

Different data fields have different update frequencies, source ecosystems, validation requirements, confidence thresholds, and business importance. A company record might contain high-confidence company identity, high-confidence email, medium-confidence employee count, and low-confidence technology data. Representing the entire record as "95% accurate" hides that variation. The quality model should preserve field-level quality information wherever practical.

10. How to Choose Provider Order

Provider order should not be arbitrary. A useful waterfall evaluates each candidate source across several dimensions before assigning it a position in the sequence:

DIMENSION        QUESTION

────────────────────────────────────────────────────────

Coverage         How often does this source return a candidate?

Accuracy         How often is that candidate correct?

Freshness        How current is the information?

Cost             How much does a successful result cost?

Latency          How quickly does the source return?

Geography        Where does the source perform well?

Data Type        What kind of data is the source specialized in?

Validation       Can the result be independently validated?

The question is not which provider is best in the abstract. It is which provider is the best first source for this field, this segment, and this workflow. Provider order can therefore differ across fields — the best first source for email may not be the best first source for technology data or employee count.

11. Missing, Invalid, Conflicting, and Unknown Are Different States

A robust enrichment system should not reduce the result of a source query to found or not found. There are many possible states, and they require different responses:

MISSING           No source has returned a candidate

INVALID           A source returned a malformed or unacceptable value

CONFLICTING       Two sources returned different values

STALE             The value belonged to a previous context

UNVERIFIED        Value returned but not independently validated

PROVIDER ERROR    Source failed to respond

FOUND + ACCEPTED  Value returned and passed acceptance rules

FOUND + REJECTED  Value returned but failed acceptance rules

REVIEW REQUIRED   Ambiguous result requiring human judgment

Consider an email address. A missing result means the waterfall should continue to the next source. An invalid result should be rejected and the next source queried. A conflicting result from two sources should trigger conflict resolution rules or a review queue rather than silent selection of one. A stale result — an email from a previous employer — should trigger revalidation rather than acceptance. A provider error should trigger a retry or fallback according to system policy. Treating all of these as "not found" loses information the pipeline needs to make the correct next decision.

12. Entity Resolution Comes Before Trusting Enrichment

Enrichment is only useful if the system enriches the right entity. Consider a contact record for Jane Smith, VP Sales at Acme Inc. Suppose a provider returns a record for Jane Smith, Chief Revenue Officer at Acme Holdings. These may represent the same person — or not. Without entity resolution, the enrichment may silently update the wrong record.

The correct sequence:

PERSON

↓

CURRENT EMPLOYMENT

↓

ACCOUNT

↓

IDENTITY

↓

ENRICHMENT

Not:

NAME

↓

SEARCH

↓

TAKE FIRST MATCH

Salesforce explicitly connects enrichment with identity resolution and record unification, including the use of external reference data to understand company relationships and resolve records. Bad entity resolution can turn high-quality enrichment data into inaccurate prospect records — and the error is often invisible because the record appears populated.

13. Enrichment Is More Than Filling Missing Fields

The simplest definition of enrichment is filling blank fields. That definition is too narrow. Enrichment can support at least five different needs.

Completeness addresses a required field that is missing. Freshness addresses a field that exists but may be outdated. Validation uses an independent source to confirm an existing value rather than replace it. Context adds information that supports a decision without replacing any existing field. Derived intelligence calculates a new value from multiple data sources — a model-based score or calculated classification rather than a value retrieved directly from a provider.

Salesforce explicitly describes enrichment as improving completeness, recency, context, and usability, including calculated insights derived from existing data. Enrichment is not just adding data. It is improving the usefulness of an existing record for a specific decision.

14. Enrichment Is Not Prospecting

The same data providers often support both enrichment and prospecting, which can blur the boundary between the two workflows. They have different architectural goals.

Prospecting finds new accounts or people:

MARKET

↓

ICP

↓

DISCOVERY

↓

NEW RECORDS

Enrichment improves records that already exist:

EXISTING RECORD

↓

MISSING / STALE / INSUFFICIENT DATA

↓

ENRICH

↓

BETTER RECORD

Salesforce explicitly distinguishes enrichment of existing records from prospecting and net-new sourcing. A waterfall designed to fill missing fields should not automatically become a discovery engine. Conflating the two creates architectural ambiguity about what the system is trying to produce and makes it harder to measure whether it is succeeding.

15. Provenance Must Travel With the Data

When enrichment changes a field, the system should know why. A useful provenance record contains:

FIELD PROVENANCE

├── Source

├── Source Type

├── Source Timestamp

├── Enrichment Timestamp

├── Method

├── Validation Status

├── Confidence

├── Previous Value

└── Current Value

For example: Job Title = VP Revenue Operations, Source = Provider B, Collected = 2026-10-05, Validated = 2026-10-05, Confidence = High, Previous Value = Director of RevOps. Now the system can answer where the value came from, why it is trusted, and when it should be checked again. Without provenance, enrichment can produce a cleaner-looking dataset while making the underlying data harder to audit — a poor trade.

16. Conflict Resolution Needs Explicit Rules

When three sources report 850, 1,200, and 980 employees respectively, the system needs a defined rule for which value to use. Taking the newest response is not always correct. The right answer may depend on source authority, source freshness, field type, confidence, geography, company structure, and measurement methodology.

Conflict resolution rules should be field-specific rather than universal. For employee count, a range may be acceptable and the most recent high-confidence value preferred. For job title, exact current employment may matter more than any source's timestamp, making corroboration across sources more important than recency alone. For email, identity confirmation and deliverability testing may carry more weight than which provider returned the value first. For industry, a standardized classification taxonomy may be preferable to free-text labels from any individual source.

A single conflict resolution rule applied uniformly across all field types will produce wrong answers in some fields. The system should maintain field-specific conflict logic as a governed configuration rather than a default behavior.

17. When Should a Waterfall Stop?

A waterfall without explicit stop conditions becomes an unbounded chain of provider calls with increasing cost and diminishing returns. The system should stop under three conditions.

Acceptance. A result passes the required quality threshold — valid, current enough, matched to the correct entity, and meeting the minimum confidence requirement. This is the normal stop condition.

Economic limit. Further enrichment is no longer justified by the priority of the record. A low-priority account may not justify three additional provider calls at incremental cost. The waterfall should have a configured cost ceiling per record or per field and should stop when that ceiling is reached.

Fundamental unresolvability. Some fields cannot be reliably enriched for some records. The system should be allowed to record an explicit terminal state:

ACCEPTED

REJECTED

REVIEW

UNRESOLVED

Not every record needs to end with a populated field. An explicit "unresolved" state is more useful than a low-confidence value that appears populated but cannot be trusted.

18. Freshness and Re-Enrichment

Enrichment is not a one-time event. A value that is valid today can become stale as people change roles, companies change structures, and technology environments evolve. Job titles, employment status, email addresses, company size, technology environments, funding information, and hiring activity are all subject to decay at different rates.

Salesforce notes that enriched attributes decay over time and that organizations may use enrichment continuously to keep data current. The lifecycle:

ENRICHED

↓

VALID

↓

AGING

↓

STALE

↓

REVALIDATE

↓

RE-ENRICH

This connects to the data decay framework established earlier in the series. The relevant question is not whether a record was enriched at some point. It is whether a specific field is still trustworthy for the decision the system is about to make.

19. Enrichment Depth Should Reflect Account Priority

Not every record deserves the same enrichment investment. A tiered model aligned with account prioritization produces a more efficient system.

High-value accounts can justify multiple sources, deeper validation, more contextual enrichment, stronger entity resolution, and just-in-time verification at the point of activation. Standard accounts can use a primary source with one fallback and standard validation. Low-priority accounts can use a lower-cost source with basic validation and limited enrichment depth.

ACCOUNT PRIORITY

↓

DATA REQUIREMENTS

↓

ENRICHMENT DEPTH

↓

VALIDATION DEPTH

↓

ACTIVATION

This connects to the prioritization framework from P2-39. The highest-value accounts can justify greater data investment. Treating every record as equally important is both inefficient and creates a situation where high-priority accounts receive the same data quality as accounts that will never be activated.

20. Measure the Waterfall by Usable Data

A waterfall can appear successful because it produces a high number of matches. Match rate alone is insufficient. A more complete measurement model tracks multiple dimensions:

METRIC                        QUESTION

─────────────────────────────────────────────────────────────────

Raw Match Rate                How often did a source return something?

Accepted Match Rate           How often did the value pass acceptance rules?

Validation Pass Rate          How often did the result survive validation?

Conflict Rate                 How often did sources disagree?

Stale Rate                    How often were enriched values no longer current?

Cost per Accepted Field       What did it cost to produce a usable field?

Cost per Activation Record    What did it cost to create an activation-ready record?

Downstream Quality            Did enriched data improve bounce rates or conversion?

These metrics connect waterfall performance to business outcomes:

PROVIDER PERFORMANCE

↓

FIELD QUALITY

↓

ACTIVATION QUALITY

↓

OUTCOME

↓

WATERFALL OPTIMIZATION

The waterfall should be optimized based on business usefulness, not on how many candidates each provider returned.

21. The Complete Waterfall Architecture

A mature waterfall connects data requirements to outcomes through a governed sequence of decisions:

DATA REQUIREMENT

↓

FIELD PRIORITIZATION

↓

SOURCE SELECTION

↓

SOURCE ORDERING

↓

ENTITY MATCHING

↓

DATA RETRIEVAL

↓

VALIDATION

↓

CONFLICT RESOLUTION

↓

ACCEPT / REJECT / REVIEW

↓

PROVENANCE

↓

FINAL FIELD

↓

FRESHNESS CHECK

↓

ACTIVATION

↓

OUTCOME

↓

RE-ENRICHMENT

The intro diagram showed the conceptual flow at the level of a single source query. This diagram shows the full operational architecture — including the governance layers (conflict resolution, provenance, freshness check) and the feedback loop (outcome, re-enrichment) that turn a one-time process into a continuously improving data system. The difference between these two representations is the difference between describing how enrichment works and describing how to build enrichment infrastructure.

22. From Data Requirements to Waterfall Design

The waterfall should be designed starting from the decision the system needs to make, not from the vendors available. Suppose the outbound workflow needs to determine whether an account is ready for a specific campaign. The required information spans four areas:

ACCOUNT FIT

├── Industry

├── Employee Count

├── Geography

└── Business Model

CONTACT FIT

├── Current Role

├── Seniority

└── Responsibility

ACTIVATION

├── Current Employment

├── Verified Email

└── Suppression Status

CONTEXT

├── Technology

├── Hiring

└── Funding

Only after defining what is needed should the system determine, for each field:

FIELD

↓

REQUIRED QUALITY

↓

SOURCE OPTIONS

↓

VALIDATION

↓

FALLBACK

This follows the broader data-pipeline principle established earlier in the series: start with the decision, then define the data required to support it. The waterfall is an implementation of that principle applied to multi-source enrichment.

Conclusion

Waterfall enrichment is often described as a technique for combining multiple data providers. That framing is accurate but incomplete. A waterfall is a data architecture pattern for dealing with incomplete, fragmented, uneven, and changing coverage. It creates a controlled process for answering one question: if one source cannot provide a sufficiently trustworthy answer, where should the system look next — and when should it stop?

A good waterfall requires more than a vendor list. It requires data requirements, field-level quality rules, source prioritization logic, entity resolution, validation, conflict resolution, provenance tracking, stop conditions, freshness rules, cost controls, and outcome measurement.

DATA REQUIREMENT

↓

SOURCE

↓

MATCH

↓

RETRIEVE

↓

VALIDATE

↓

ACCEPT / REJECT / REVIEW

↓

PROVENANCE

↓

FINAL VALUE

↓

REFRESH

The objective is not to fill every blank field, maximize the number of providers, or collect the largest possible dataset. The objective is to produce data that is trustworthy enough, current enough, and complete enough for the decision the system needs to make. A good waterfall does not ask which provider has the most data. It asks which source can provide the most trustworthy answer for this field, for this record, at this moment. Coverage is an output. Data quality is a system property.

The next question is how enrichment connects to campaign eligibility — specifically, what quality thresholds a record must meet before it can be activated into an outbound motion, and what the system should do when those thresholds are not met.

Sources

Salesforce — Define Data Enrichment. Available at: https://trailhead.salesforce.com/content/learn/modules/data-enrichment-fundamentals/define-data-enrichment

Salesforce — Enhance Customer Insight with Third-Party Data Enrichment. Available at: https://trailhead.salesforce.com/content/learn/modules/data-enrichment-fundamentals/improve-customer-understanding-with-third-party-enrichment

Salesforce — Enrichment Considerations. Available at: https://help.salesforce.com/s/articleView?id=sf.c360_a_enrichment_considerations.htm&language=en_US&type=5

Apollo — Waterfall Enrichment Overview (October 2, 2026). Available at: https://knowledge.apollo.io/hc/en-us/articles/34071089002509-Waterfall-Enrichment-Overview

Clay — Complete Guide to Waterfall Enrichment. Available at: https://www.clay.com/guides/waterfall-enrichment

Deepline — B2B Data Enrichment Waterfall (August 2026). Available at: https://deepline.com/use-cases/b2b-data-enrichment-waterfall