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.
