Flow Spaghetti: When Nobody Knows What Fires on What

Part 3 of 10 in the series: What Your Salesforce Org Says About Your Company

Your Salesforce Flows are spaghetti. I don't mean that as an insult. I mean it as a diagnosis.

I traced a single record update at a client's org last quarter. One user changed the Stage on an Opportunity from "Prospecting" to "Qualification." That single field change triggered 14 automations across 6 objects. The record saved correctly. It also created 3 duplicate tasks, sent 2 emails to the same person, and updated a field on the related Account that a different Flow immediately overwrote with a different value.

Total time to diagnose what happened: 4 hours at $250/hour. The client had been seeing these duplicate tasks for 6 months. They assumed it was a "Salesforce bug." It wasn't. It was 6 different admins over 5 years building automations without checking what already existed.

The cost of the diagnosis was $1,000. The cost of the remediation (consolidating 14 automations into 4) was $3,500. The cost of leaving it alone for 6 months before calling me was approximately 1,800 duplicate tasks, 900 duplicate emails, and an operations team that had stopped trusting the task list entirely.

Why Flow Spaghetti Happens

Salesforce made Flows easy to build and almost impossible to govern. That combination is the root of the problem.

The "One More Flow" Pattern. A stakeholder asks for a new automation. The admin builds a new Flow. Neither the admin nor the stakeholder checks whether an existing Flow already does something similar, or fires on the same object with overlapping trigger conditions. This happens because there's no central inventory, no naming convention, and no requirement to review existing automations before building new ones.

The Cloning Problem. An admin needs a Flow that does something similar to an existing Flow. They clone it, change three things, and deploy it. Now there are two Flows doing nearly identical work on the same object. The clone inherits the original's trigger conditions, which may conflict with other Flows. The cloned Flow's name starts with "Copy of," which tells anyone auditing the org exactly how it was built and how little thought went into it.

The Legacy Migration Gap. Salesforce deprecated Workflow Rules and Process Builder in favor of Flows. Many orgs migrated their legacy automations using the "Migrate to Flow" tool, which converts each Workflow Rule or Process Builder into a separate Flow. An org that had 30 Workflow Rules and 15 Process Builders now has 45 new Flows on top of whatever Flows already existed. Nobody consolidates after migration because migration itself feels like enough work.

No Order of Execution Awareness. When multiple Record-Triggered Flows fire on the same object, they execute in a specific order that Salesforce determines at runtime. Most admins don't know this order and can't predict it. Two Flows that each update the same field on the same object will produce different results depending on which one fires last. This creates intermittent bugs that are nearly impossible to reproduce consistently.

No Error Handling. Most Flows are built without fault paths. When something goes wrong, the Flow fails silently or throws a generic error message that tells the user nothing useful. Without fault connectors and error logging, diagnosing a failed Flow requires manually tracing the logic step by step. Multiply that by 200 Flows and you understand why most admins give up and build a new one instead of fixing the broken one.

How to Diagnose Flow Spaghetti

The audit below takes 2-4 hours for a typical org. The goal is to build a complete map of every automation, organized by the object it fires on.

Step 1: Build the Flow Inventory

Navigate to: Setup → Process Automation → Flows

Create a spreadsheet with these columns: Flow Name, Flow Type (Record-Triggered, Screen, Scheduled, Autolaunched, Platform Event), Object (if Record-Triggered), Trigger Condition (Before Save, After Save, Before Delete), Description (from the Flow's description field), Created By, Created Date, Last Modified Date.

Export the full list. If your org has more than 50 Flows, use Salesforce Inspector or the Tooling API to pull the metadata programmatically.

Step 2: Identify Red Flags

Scan the inventory for these specific patterns:

Flows starting with "Copy of." This means someone cloned a Flow without renaming it. The clone likely duplicates logic that already exists elsewhere. Count these. If more than 10% of your Flows start with "Copy of," your automation layer was built through cloning, not design.

Flows with no description. An undocumented Flow is a ticking time bomb. When it breaks (and it will), nobody will know what it was supposed to do without reading the entire canvas step by step. Count undocumented Flows as a percentage of total. Above 30% means your automation layer has no governance.

Multiple Record-Triggered Flows on the same object. Navigate to: Setup → Object Manager → [Object] → Record-Triggered Flows. This view shows all Record-Triggered Flows for a specific object. If you see more than 3 on a single object, there's consolidation work to do.

Flows that update the same field. This is the root cause of most "mysterious" data issues. If Flow A updates the Account Rating field and Flow B also updates Account Rating, the final value depends on execution order. These conflicts produce bugs that only appear intermittently, making them extremely difficult to troubleshoot.

Step 3: Map Automations by Object

Create a second tab in your spreadsheet: one row per object, with columns for the number of Record-Triggered Flows, whether any Flows conflict (updating the same fields), and whether legacy automations (Process Builders, Workflow Rules) still exist on that object.

This map shows you where the spaghetti is thickest. An object with 8 Record-Triggered Flows, 2 active Process Builders, and 1 Workflow Rule has 11 automations that fire in an unpredictable sequence. That object is your highest-risk asset.

Step 4: Trace a Test Record

Pick the object with the most automations. Create or update a test record in your sandbox. Then check:

How many tasks were created? How many emails were sent? Did any fields update to unexpected values? Were any records created on related objects?

Compare the results to what you expected. If the number of side effects surprises you, the automation layer on that object needs consolidation.

How to Fix Flow Spaghetti

Consolidate, don't delete. The goal is not to eliminate Flows. It's to reduce the number of Flows per object to a manageable count: ideally 1-3 Record-Triggered Flows per object, each handling a distinct category of logic (data updates, notifications, record creation).

Use one Flow per trigger type per object. Instead of 5 separate "After Save" Flows on the Account object, build one master "After Save" Flow with decision elements that route to different paths based on the criteria. This is more complex to build initially but dramatically simpler to maintain and troubleshoot.

Add fault paths to every Flow. When you consolidate, add fault connectors to every action element. Route failures to a custom object that logs the error: Flow Name, Error Message, Record ID, Timestamp. This log replaces the "it just broke and nobody knows why" experience with a queryable error history.

Migrate all legacy automations. If you still have active Workflow Rules or Process Builders, migrate them to Flows and deactivate the originals. Do not run legacy and modern automations in parallel on the same object. The interaction between them creates unpredictable behavior.

How to Prevent Future Spaghetti

Naming Convention. Every Flow must follow a naming standard: [Object][Action][TriggerType]. For example: Account_UpdateIndustryRating_AfterSave. The name tells you what it does and when it fires without opening it.

Description Requirement. Every Flow must have a description that includes: what it does in plain English, who requested it, when it was built, and what business process it supports. This takes 60 seconds to fill in during development. It saves hours during troubleshooting.

Pre-Build Review. Before creating any new Flow, check the existing Flows on that object. If a Flow already fires on the same trigger and could be extended, extend it. Don't build a new one.

Quarterly Flow Audit. Every 90 days, review the Flow inventory. Deactivate anything unused. Update descriptions. Flag Flows that need consolidation. This is the single most effective governance practice for the automation layer. It takes 2-3 hours per quarter and prevents the spaghetti from re-forming.

Download the Flow Audit Checklist

The companion checklist walks through every step of the audit described above. It includes the red flag checklist, the object mapping template, and the governance rules you should implement after the cleanup.

Your undocumented Flow count is your governance gap. Your "Copy of" count is your cloning debt. Your multi-Flow object count is your consolidation backlog. Those three numbers tell you exactly how much work is ahead.

Download the Flow Audit Checklist below. It's free.

Part 3 of 10 in the series: What Your Salesforce Org Says About Your Company.