Salesforce Flow Governance: Finding Flows That Fight Each Other

Start with Salesforce's own Flow Trigger Explorer on your highest-traffic objects (Lead, Opportunity, Account), which lists every record-triggered flow on that object and its run order. Look specifically for two or more flows updating the same field from different trigger conditions, since that's the most common source of a value that "randomly" reverts. A flow built eighteen months ago to backfill a field during a one-time migration, still active and still firing, is a frequent culprit that nobody remembers to deactivate once its original job is done.

The symptom is almost never an error message. It's a rep insisting they set a field correctly, a manager not believing them, and neither one realizing a second flow quietly reverted it thirty seconds later.

Before-save flows run earlier and faster than after-save flows, and mixing update logic for the same field across both types is a common cause of unpredictable ordering. If two flows both set a status field but one runs before-save and the other after-save, whichever one runs last wins, and which one runs last isn't obvious just from looking at either flow individually. Consolidating same-field logic into a single flow, or at minimum documenting the intended order explicitly, removes the guesswork.

This matters most on fields that other automation or reporting depends on downstream: a stage field feeding a forecast rollup, or a status field triggering a notification. Silent reordering on a cosmetic field is an annoyance; on one of these, it's a data-quality problem that spreads to every report built on top of it.

A one-page rule that every new flow needs, before it gets built, solves most of this at the source: which fields it may write to, which existing flows on that object it might collide with, and who approves it going live. This doesn't need heavy process. It needs one named owner (usually a Salesforce admin or RevOps lead) whose job is specifically to check for collisions before deployment, not after a rep reports something broke.

Write the rule down somewhere every future flow builder will actually see it, ideally linked from wherever your team already tracks work, not buried in a wiki page nobody remembers exists after the person who wrote it moves on.

For each of your top three highest-traffic objects, list every active flow touching it, the fields each one writes, and its trigger order.

• Flag any field written by more than one flow
• Flag any flow whose original purpose (a migration, a one-time cleanup, a since-retired process) no longer applies
• Flag any flow with no documented owner or last-reviewed date

This alone usually surfaces two or three real conflicts most teams didn't know existed, without needing a bigger platform audit.

When you find a stale flow, deactivate it rather than deleting it immediately, and hold it for a defined window before removing it entirely. A flow that looks unused can still be doing one quiet job nobody documented, and deactivating first gives you a safe rollback if a field starts behaving unexpectedly a week later. Deleting outright the moment you find it is how a cleanup project accidentally becomes its own incident.

For example, an admin auditing the Opportunity object finds a flow built for a one-time migration that still sets the stage field whenever a record is edited. Instead of deleting it, they deactivate it, note the date and owner in the audit list, and watch the stage field and forecast rollup for a defined window. If nothing changes, they delete it. If a report shifts unexpectedly, they reactivate it, learn what the flow was quietly doing, and document that job properly before retiring it. The rollback path is what makes the cleanup safe.