Why Enrichment Waterfalls Built Inside Salesforce Flow Fall Over

Flow is where your other record automation already lives, so keeping enrichment logic there feels consistent, and a simple two- or three-provider waterfall genuinely is easy to build as a sequence of decision elements checking whether the previous call returned data. For a low-volume trickle of new leads, this works and stays invisible as a problem for a surprisingly long time.

Salesforce enforces governor limits on the number of callouts and total execution time within a single transaction context, and a waterfall making sequential calls to multiple enrichment providers, each with its own latency, can hit those limits under real lead volume even when each individual call succeeds on its own. The failure often doesn't throw a visible error to a rep. A record just silently doesn't get enriched, and nobody notices until someone happens to check the field weeks later and finds it empty on a meaningful share of new leads.

The problem tends to appear exactly when it matters most: a marketing campaign or a list import that spikes lead volume well above the trickle the Flow was originally tested against. That's precisely the moment a growing team most needs enrichment to keep working reliably.

The fix is architectural, not a bigger Flow: move the waterfall's sequential provider logic into middleware or a lightweight backend service that Flow calls once, asynchronously, rather than Flow itself managing three sequential API calls within its own execution limits. Flow's job becomes triggering the enrichment request and, later, writing the result back to the record, not orchestrating the waterfall's internal branching logic itself.

For example, Flow can fire a single request whenever a lead is created, passing the record to a middleware service. The service tries the first provider, falls back to the second and third as needed, and writes one result back asynchronously. Flow never waits on three sequential calls, so a list import does not stack up against execution limits. Add a status field with values such as pending, enriched or failed, so a record that missed enrichment shows up in a report instead of sitting silently empty.

Simple, single-call automation genuinely belongs in Flow, and moving everything out on principle adds unnecessary complexity for cases that don't need it. The line is roughly: if the logic involves more than one external call with conditional fallback between them, or if it needs retry logic for a failed call, move it out. If it's a single call with a straightforward success or failure path, Flow can usually still handle it without hitting governor limits under normal volume.

Document this line somewhere your admin team can reference it, since the temptation to add "just one more fallback provider" to an existing Flow is exactly how a simple single-call automation quietly becomes the multi-step waterfall that eventually hits a limit.

Move enrichment logic out of Flow when any of these apply:

• The logic makes more than one external call, with conditional fallback from one provider to the next.
• The logic needs retry handling for a failed provider call, which Flow is poorly suited to manage.
• Lead volume can spike well above what the Flow was tested against, such as after a campaign or list import.
• Someone keeps asking to add one more fallback provider to an existing single-call automation.

Run the new middleware-based waterfall in parallel with the existing Flow-based one for a defined test window, comparing enrichment results on the same batch of leads, before turning the old Flow logic off. This catches any behavioral difference, like a provider timeout being handled differently, before it affects live leads. Once results match consistently, retire the Flow-based waterfall rather than leaving both running indefinitely, since two active enrichment paths on the same field is its own source of confusing, inconsistent data. Enriched contact data feeding into cold outbound campaigns is worth getting right specifically, since campaigns built on stale or missing fields underperform the wider average cold email reply rate of 3.43 percent by a wide margin¹.