The Flow was fine. The formula it read was not. In the constructed case below, a Salesforce Flow regression in lead routing looked like a bad Flow deploy, and the Flow was byte-identical in sandbox and production. The fault sat one layer down, in a field the Flow depended on that had changed in one org only. The conclusion: compare the two orgs, Flow plus dependencies, before you decide which change to revert.
The symptom, as the routing owner saw it
This is a constructed case with illustrative numbers. A record-triggered Flow assigns new Leads to reps by territory. Anything it cannot match falls through to a catch-all queue. The routing owner noticed the queue filling up.
Baseline week: 38 of 980 new Leads landed in the fallback queue, 3.9%. The week after a Flow change shipped: 412 of 1,030, 40.0%. Same lead sources, same form, volume up 50 Leads. Measured once, over two seven-day windows, which is enough to act on and not enough to call a trend.
The first suspect, and the measurement that cleared it
The obvious suspect was the Flow change itself. It shipped on the first day of the bad window, it touched the territory decision, and it replaced the Central outcome for Germany, Austria and Switzerland with a new DACH outcome. Blaming it was reasonable.
So the check was a replay. A set of 120 test Leads, built with a country mix matching the baseline week, went through the sandbox where the change had been tested. Result: 3 of 120 in the fallback queue, 2.5%. The sandbox did not have this Salesforce Flow regression. Production did.
Then a cross-org compare of the Flow metadata itself, sandbox against production. Zero differences. Same elements, same decision criteria, same active version content. First hypothesis down: the Flow as deployed was the Flow as tested.
Walking a Salesforce Flow regression one layer at a time
Same Flow, the same mix of inputs, different outputs. That leaves the things the Flow reads. Walk them in order:
- Input records: the replay used production-shaped Leads, so not the data.
- The Flow: compared, identical.
- Fields the decision reads: the Flow branches on a Territory formula field, not on Country directly.
- Queue and user records: present in both orgs.
Layer 3 was the break. Of the 412 queued Leads, 371 had Country set to Germany, Austria or Switzerland, which is 90.0% of the queue. In sandbox, the Territory formula returned "DACH" for those countries. In production it still returned "Central", the old value. A separate change had updated the formula in sandbox and never been promoted. The Flow no longer routed those countries to Central, no Lead carried "DACH", and they fell through.
The mechanism, and the fix measured afterwards
Mechanism, not correlation: the Flow change was correct and depended on an undeployed field change. Each object was valid alone. Together, in production, they produced a Salesforce Flow regression that no review of the Flow diff could show, because the Flow diff was right.
The fix was to promote the formula change, then rerun the same comparison. Next seven-day window: 41 of 1,060 in the fallback queue, 3.9%, back to baseline. Arithmetic re-checked: 412 / 1,030 = 0.400, 371 / 412 = 0.900, 41 / 1,060 = 0.039.
Where a tool fits, and where it does not
The useful pair here is dependency analysis plus a cross-org compare of what it finds, not a diff of only the file you changed. Salto lists "PR-gated approvals, automated promotion to production, and drift detection on every change" across Salesforce and other business apps, according to Salto's homepage, read 1 Oct 2026. If a team runs several business applications, that breadth wins.
For a Salesforce-only team that wants the change itself reviewable, FlowSprite AI is built for that case. Any AI the team already uses drafts the metadata change. The change lands as a GitHub pull request in the customer's private repo. It is tested in a sandbox before production, a human approves before deploy, and production is never auto-touched. The Professional plan, EUR 99 per month for 10 users and 6 Salesforce connections, includes cross-org compare, drift detection, deploy preview and dependency analysis. Honest limits: it does not fit a team that wants scratch-org pooling or a longer evaluation window. Hutte includes scratch-org pooling from its Core plan and lists a 30-day trial with no card, according to Hutte's pricing page, read 1 Oct 2026. Gearset's pricing page says "Try it out for 30 days, with no card details required" (read 1 Oct 2026), against a 14-day trial with no card for FlowSprite. Gearset also sells Flow and Apex error monitoring at $1 per Salesforce user per month with a $100 minimum, according to Gearset's pricing page, read 1 Oct 2026.
What the fix does not address, and the alert that would have caught it
The fix did not reroute the Leads already queued. Excess over baseline: 412 minus roughly 40 expected, about 370 Leads that sat in a queue for up to a week. Someone has to reassign them, and the response-time cost is not recoverable.
It also did not address why a field change could live in sandbox for weeks unpromoted. That is a process gap, and the next Salesforce Flow regression of this shape will come from the same gap.
The check that would have caught it earlier is two lines:
- Before deploy: dependency analysis on the Flow, then a cross-org compare of every referenced field between sandbox and production. Any difference blocks the deploy.
- After deploy: alert when fallback-queue Leads exceed twice the trailing four-week rate over any 24-hour window with at least 100 new Leads. Report it as numerator over denominator, never a bare percent. Both numbers are starting values chosen for this constructed case; tune them to your own Lead volume.
Set the threshold, name the owner role, and let the queue tell you about the next Salesforce Flow regression in a day instead of a week.