Waterfall Enrichment: How It Works and How to Control Costs

What is waterfall enrichment?

Waterfall enrichment queries multiple data providers in a defined order to fill missing contact or company fields. A record moves to another source when the previous result fails the workflow's acceptance rules. It stops when the required data passes those rules, the available sources run out, or a budget or time limit is reached.

For a sales operations team, the starting point might be a contact's name and employer domain. The missing field is a work email. The useful outcome is an address attached to the right person, with a status your team accepts for its next action.

Query additional sources when a target field is still missing

A single provider may resolve much of your list while leaving gaps in particular roles, regions, or companies. A waterfall lets you direct additional queries toward those gaps. Records that already have an accepted email can leave the email search flow while unresolved records continue to another source.

The value comes from the additional usable records. A second source that returns the same contacts adds little to a list you have already accepted. The broader lead enrichment guide covers field selection and CRM updates; this article focuses on the decisions involved in querying several sources.

Separate a returned match from a usable result

Keep three questions separate: did the source identify the intended person, did it return the required field, and does that field meet your quality requirements? A profile match with an empty email field answers only the first question. An address with an unresolved verification status may still require review.

Stopping behavior depends on the implementation. Apollo's waterfall documentation describes an optional validator and explains that its configured flow can continue until a validated result is found. That is Apollo's product behavior. When designing your own workflow, specify the conditions under which a result is acceptable.

How does a waterfall enrichment workflow work?

Define the identifiers and acceptance rules first

Start with one target field and one business action. For a work email search, your input record might contain an internal record ID, a name, an employer domain, and a professional profile URL if available. Check the identifiers accepted by each selected operation before sending the record.

Write down what the workflow must preserve. Keep an accepted existing address unless there is a documented reason to replace it. Retain conflicting values with their sources for review. A shared name alone should not be enough to merge two professional profiles.

For an initial evaluation, define these rules:

These are suggested workflow rules. Specify them in your agent prompt, or implement them in your application when building a persistent workflow.

Continue only when the result fails your acceptance rules

The basic sequence is prepare the record → query source A → evaluate the result → query source B if needed → save the accepted result or its unresolved status.

Use a record log to make each transition inspectable. The following is a fictional example for one contact, C-017. The source labels, outcomes, and charges illustrate the workflow; they are not provider responses or current prices.

A timeout belongs in an execution-error category. An empty successful response belongs in a no-data category. Neither establishes that the person has no email address. Give errors a separate retry or review policy so a temporary service failure does not become a permanent data conclusion.

Before moving to another source, check the record's cumulative cost, elapsed time, and remaining options. Stop at the first accepted result for the target field, or record why no result was accepted. A provider's returned status should remain attached to the value so later users can review that decision.

How should you choose and order data providers?

Test providers on the same target segment

Use a sample from the population you actually need to reach. Keep the contact inputs, target field, region, and acceptance criteria consistent. Compare performance separately for materially different groups; a sequence chosen for one market may be wasteful in another.

During an evaluation, querying several sources for the same sample can reveal overlap. Record that evaluation spend separately from the intended production flow, which may stop after an earlier source succeeds. Otherwise, the experiment's cost can be mistaken for the cost of the final sequence.

To evaluate sources through Glasser, ask your agent to find suitable operations in its data-source catalog and check their inputs and prices before running the sample. Let the target field and your evaluation results determine the shortlist and order. The same selection approach applies across supported sources for contact, company, technology, and other data tasks.

Put complementary sources ahead of repeated coverage

For each possible next source, ask how many unresolved records it makes usable, what that costs, and how much time it adds. The least expensive first query may be a poor choice if it leaves most of the target segment unresolved.

Track these measures:

• Accepted records from the source under the same quality rules.
• Additional accepted records after accounting for earlier sources.
• Total data and validation charges for that stage.
• Conflicts and records that still require manual review.

Choose the order from that evidence. Revisit it when your input population changes or a provider's coverage, terms, or output changes. A fixed provider ranking cannot account for those differences.

How much does waterfall enrichment cost?

Include lookups, verification, and workflow maintenance

The bill depends on which records reach each stage and how those stages charge. Some operations charge per request; others charge per returned result. Verification can add another charge. Empty results, provider errors, and timeouts require their own contract checks.

Make a budget for the full task: source queries, any separate verification, refreshes, required subscriptions or minimum purchases, and implementation or review time. Do not apply one provider's billing rule to another provider or to an intermediary's operation.

Measure the cost of each additional usable record

Use two calculations for different decisions:

Blended data cost per usable record = total source and validation charges ÷ unique accepted records.

Incremental data cost per usable record = a fallback stage's source and validation charges ÷ additional unique accepted records from that stage.

Here is a hypothetical budget for 100 contacts needing a work email. Each accepted record contains one email that passes the same rule. Each stage's spend includes the data and validation charges attributed to that stage.

The three-stage flow produces 80 accepted records for $9, or $0.1125 per usable record. Stopping after source B produces 75 accepted records for $7, or about $0.0933 per usable record. Source C costs an additional $2 for five additional accepted records.

That difference gives you a concrete decision: are those five records worth the extra expense and review effort? If a stage adds zero usable records, report zero incremental coverage and the amount spent; its cost per additional record has no finite value.

These figures explain the arithmetic. They are not a benchmark, supplier quote, or forecast. Add engineering and manual review costs separately before judging the economics of the complete workflow.

When should you use a waterfall, and how can Glasser support it?

Use additional sources for measurable gaps

A waterfall is worth evaluating when a primary source leaves a meaningful gap, another source can address that gap, and the added records pass your acceptance rules at an acceptable cost. It also needs an owner who can maintain the matching, branching, and result review.

For a small list with little missing information, another source may add more work than value. If identities are ambiguous or your acceptance rules are undefined, resolve those issues before increasing the number of queries. More returned fields will not resolve an unclear matching policy.

Ask your agent to run waterfall enrichment through Glasser

Connect your agent to Glasser, then prompt it to enrich your records using waterfall enrichment across suitable supported sources. Specify the fields you need, acceptance rules, and a spending limit; ask for the accepted data, sources, remaining gaps, and total cost.

This approach applies to contact, company, technology, and other supported data tasks. Choose sources that match your target fields and available identifiers, and ask the agent to try another suitable source when gaps remain. The sequence and stopping rules are instructions for your agent to follow. Review a small sample and its recorded charges before increasing volume.

This guide uses public documentation reviewed on October 29, 2026. Its examples are illustrative; no paid provider calls or comparative coverage tests were performed for the article.

Frequently asked questions

Does waterfall enrichment verify every email automatically?

Verification depends on the selected product, data source, and configuration. Check the meaning of returned statuses and add a separate validation step when your acceptance rules require it.

Does a waterfall stop at the first returned result?

Set the stopping condition to the first result that meets your stated rules. A returned profile with a missing target field or an unacceptable validation status may need further processing.

Is waterfall enrichment always cheaper than one provider?

The answer depends on incremental coverage and the charges incurred at each stage. Compare blended cost with the cost of the additional usable records, including verification and maintenance.

What should happen when providers return conflicting data?

Retain the conflicting values with their sources and review status. Apply a documented rule for identity, freshness, and acceptable evidence before updating an existing accepted field.