Salesforce Flow drift and the automation nobody remembers building

Both systems reported success. Only one of them wrote what it meant to. The cheapest alert for a sync that quietly goes wrong is not an error monitor, because nothing errors. It is a check for Salesforce Flow drift, a daily comparison of what is active in the org against what the repository says should be active, routed to an owner role that can say "keep" or "delete". The trace below is constructed; its numbers are illustrative, not measured.

Two systems, one direction, one contract

Constructed setup: a marketing automation platform (hypothetical API) pushes new leads into Salesforce once a night at 02:00 Europe/Berlin. The payload carries email, company, country and a campaign code. Assumed: Salesforce upserts the Lead on an external ID field holding the platform's record ID, the idempotency key, returns the Salesforce record ID, and the platform requests assignment rules on each call. Retries: three attempts, five minutes apart. A 4xx stops them, except a 429: the job backs off, honours the rate limit and resumes.

Follow one record: country "DE", campaign code "WEB-EVENT", before the edit. No external ID matches, so a Lead is created, the requested assignment rules route it to the DACH queue, and the platform stores the returned ID. Clean.

The Flow that was not in anyone's list

Somewhere in the org sits an after-save record-triggered Flow built for a one-off event two years earlier. In this setup it runs after the assignment rules have fired and sets the Lead owner to a holding queue. Nobody on the current team built it; it never reached the repo. On a Monday afternoon someone edited it in production, widening its entry condition to any campaign code starting "WEB-", and activated it.

That night the next "WEB-EVENT" lead syncs, and this time the widened entry condition matches it. Nothing fails. The upsert succeeds, the Flow runs, the lead lands in a queue nobody works: a partial outcome reported as a full write.

What each side believes after the run

The platform believes every record was delivered, and it is right: each upsert returned an ID, so no retry fired. Salesforce believes every Lead was processed, also right.

The constructed numbers: 1,400 leads per night, of which 9% carry a "WEB-" code. That is 1,400 x 0.09 = 126 misrouted leads per night. It surfaces on day 11, when a regional manager asks. 126 x 11 = 1,386 leads in a queue nobody reads.

The reconciliation bill, and why Salesforce Flow drift is the alert

Reconciliation means checking and reassigning each misrouted Lead. Assume 2 minutes per record (illustrative). 1,386 x 2 = 2,772 minutes, or 46.2 hours of someone's time.

An error monitor would not have helped: the Flow did not error. Gearset sells Flow and Apex error monitoring as Observability at "$1 per Salesforce user, per month" with a "$100/month minimum", per the vendor's pricing page, read 1 Oct 2026. Right tool for a Flow that throws, wrong alarm for one that runs against the wrong data. The same page lists change monitoring jobs in Gearset's Automation tier, five on the $550 per team per month Starter plan (read 1 Oct 2026); change monitoring is closer to the drift question.

The alert that fits is Salesforce Flow drift. A 06:00 check comparing active Flow versions in production against the repository shows the hand-activated version as a difference the next morning. Reconciliation covers one night: 126 x 2 = 252 minutes, or 4.2 hours. Salesforce Flow drift is an ownership signal, not a bug signal: something is live that no reviewed change put there.

Who owns it, and when to delete the automation

A drift alert needs a recipient: a role, not a person. Here it is the RevOps automation owner, the role that already approves Flow changes. Does this Flow have an owner role and a reason in the repo? Keep it and land it as a reviewed change, fix it the same way, or deactivate it.

A suggested deletion rule (the thresholds are a judgment call, not a standard): a Flow with no owner role after 14 days of an open drift alert gets deactivated, and after 30 more days with no complaint it gets deleted. The event Flow should have died when the event ended.

In this loop, any AI the team brings drafts the Salesforce change, and FlowSprite AI lands it as a pull request in the customer's private GitHub repo. Every change is tested in a sandbox before production and needs a human's approval before it deploys; production is never auto-touched. FlowSprite's Professional plan includes drift detection, at EUR 99/month for 10 users and 6 connections, with a 14-day free trial and no card. Whichever tool runs it, aim for the 06:00 check above. It is not a runtime error monitor; a team whose pain is Flows that throw should look at a dedicated observability product. A team managing NetSuite, Zendesk, Jira or Okta alongside Salesforce may prefer Salto, whose home page lists those apps and promises "drift detection on every change", read 1 Oct 2026. Gearset's pricing page, read 1 Oct 2026, offers a longer trial: 30 days against 14.

Which failures this design survives

Salesforce Flow drift detection survives the failure above: a hand-edited, activated version that differs from the repo. It does not survive a reviewed Flow that is wrong, or an unchanged Flow meeting a new input: that is a contract problem. Salto's Salesforce page describes a "catch-all change log" that tracks changes "no matter how they were done", read 1 Oct 2026: another way to catch the same hand-edit case.

The upstream fix: document every field a Flow branches on in the sync contract, next to the idempotency key.

The alert that would have surfaced this: a daily Salesforce Flow drift check at 06:00 Europe/Berlin, routed to the RevOps automation owner role, firing when an active Flow version in production has no matching commit. One alert, one owner role, one decision: keep, fix or delete.