Every mature org has them: two record-triggered Flows on the same object, built by different people in different years, quietly implementing overlapping business rules. Each passes review on its own. Together they make the org’s behavior depend on execution order Salesforce does not guarantee between same-timing Flows — and the symptom shows up months later as a field that sometimes ends up with the “wrong” value nobody can reproduce.
Why name-based cleanup fails
The instinct is to scan the Flow list for suspicious names — “_v2”, “Copy of”, “OLD”. Names tell you about the org’s history, not its behavior. Overlap is behavioral: which object, which timing, which entry conditions, and above all which fields each Flow writes.
The four-question method
For any object that misbehaves, list its automation and ask, per pair: Do they trigger on the same object and timing? Do their entry conditions materially intersect (share the fields they test, with overlapping ranges)? Do they write any of the same fields? Does either read what the other writes? Two yeses is a review; three is a finding.
Then decide — per pair, not by policy
The right response differs: merge when they are one rule in two bodies; extract a shared subflow when they share a decision but diverge in action; split when one Flow secretly serves two processes; retain separately when the criteria are intentionally divergent — and retire when one is simply the older draft. Verify by re-checking the writers afterward: the field that had two writers should have one.
Doing this by hand for one object is an afternoon. Doing it for an estate is what Horus Eye’s Flow analysis automates: behavioral overlap search with the shared fields and conditions as evidence, classification per pair, and a field-writer map that shows the “after” picture — with the caveats stated where the scan cannot see intent.
The manual method, if you want to check today
In Setup’s Flow console, group record-triggered flows by object and trigger moment (before-save vs after-save), then read the entry conditions side by side: overlap means two flows on the same object and moment whose conditions can both be true for one record. Trigger order settings tell you which runs first — blank order values mean you are relying on an ordering nobody chose. For the suspicious pairs, a debug log on a single test save shows the actual sequence of FLOW_START events, which settles arguments faster than reading ever will.
When overlap is fine — and when it is not
Deliberate overlap is a pattern, not a problem: one flow per concern, orders explicitly set, entry conditions mutually understood. The dangerous kind is accidental — two authors, two eras, one field — where the second write wins silently. The test: can anyone on the team say, without opening the builder, which flow sets that field last? If not, the overlap owns you rather than the reverse, and consolidating by object — the same per-object discipline that governs engine migrations — is the way back.
