Two healthy Flows can still create an unhealthy process

Too many Flows on one object, and nobody can say which owns which business rule. Multiple Flows update the same field, so the final value depends on an execution order Salesforce doesn’t guarantee between them. Old Flows nobody dares deactivate — the last person who did broke renewals. Business logic duplicated between Flow and Apex because two teams didn’t know about each other’s work. Save transactions that crawl because every write re-triggers the stack. And underneath it all, Workflow Rules and Process Builder still firing — two retired engines carrying production logic with a migration deadline attached.

Select a Flow and Horus explains its apparent business purpose (inferred, and labelled as such), maps its save path, analyzes which fields it reads and writes and who else writes them, draws the dependency graph — and then searches the org for behavioral overlap: other automation on the same object whose entry conditions and writers materially intersect. Each candidate is classified — duplicate, superset, complementary — with the shared fields and conditions that caused the classification, and a recommendation: merge, split, extract a shared subflow, refactor, retain separately, or retire.

Automation consolidation is mostly guided — and this page won’t pretend otherwise. Horus proposes the consolidation order, names the Flows and the option per pair, and the re-scan proves the result: the same-timing finding clears, the field-writer map shows one writer. What is executable executes: validation-rule deactivation and inactive-user flow ownership cleanup run as sanctioned, reversible, per-step-approved operations. The Flow edits themselves are human work — yours, or ours: a clean automation estate is also the first prerequisite Agentforce depends on.

What do Salesforce Flow best practices say about multiple Flows per object?

Current guidance allows multiple record-triggered Flows per object — but managed deliberately: one orchestrator pattern per timing, entry criteria that don’t overlap, and never two Flows writing the same field on the same timing without a chosen order. The findings on this page are those best practices, executed as checks.

Why do I have so many Salesforce Flows?

Because creating a new Flow has always been safer-feeling than editing an existing one — under deadline, clone-and-modify wins, and retirements never finish. The count isn’t the problem; unknown interactions between them are.

How do I find duplicate Salesforce Flows?

Compare behavior: object, timing, entry conditions, fields written. Names lie; writers don’t. Horus Eye’s overlap analysis does exactly this comparison and shows the “because” behind every candidate.

How can I determine which Flow updates a field?

The field-writer map: every automation that writes or reads the field, across technologies. It is the single most-used diagram in Deep Read for a reason.

Can I consolidate Salesforce Flows?

Usually — but per pair the right move differs: merge, split, extract a subflow, refactor, retain, or retire. Decide with the overlap evidence and blast radius visible, then verify with a re-scan.

Why are record-triggered Flows conflicting?

Salesforce doesn’t guarantee execution order between same-timing Flows on one object. If two write the same field, the last writer wins — and which runs last is not a promise. That is the finding, verbatim.

What happens when Process Builder is retired?

Support has ended; processes keep running on borrowed time. Migrate per object — not per process — so the order between them survives the move. Horus groups the finding that way deliberately.