If your Salesforce org has automations that work inconsistently, records that update when they shouldn't, or errors that show up without warning — there's a good chance the root cause is a Flow problem.
Flow is Salesforce's primary automation tool. Process Builder is deprecated. Workflow Rules are on life support. If something is automated in your org, it's almost certainly a Flow now — or it should be. And while Flow is genuinely powerful, it's also easy to build in ways that cause real damage: slow save times, corrupt data, automation loops, and error emails that nobody reads.
This post covers the mistakes we see most often in orgs we inherit, why they cause problems, and how to fix them.
Mistake 1: Querying or Updating Records Inside a Loop
This is the single most common Flow architecture mistake, and it causes the most visible performance problems.
Here's what it looks like: you need to process a list of records, so you build a loop, and inside the loop you add a Get Records element to look something up, or an Update Records element to save changes. It works fine in development. In production, with 200 records triggering simultaneously, your users start hitting "Too many SOQL queries" errors or save times that take 10–15 seconds.
Why it breaks: Salesforce enforces governor limits — hard caps on how many database queries and updates can happen in a single transaction. Every Get Records inside a loop counts as a separate query. Hit the limit and the entire transaction fails.
How to fix it: Query before the loop, not inside it. Collect all your changes inside the loop into a collection variable, then perform a single bulk update after the loop ends. One query in, one update out — regardless of how many records you're processing.
Mistake 2: No Entry Criteria (Flows That Run on Everything)
A record-triggered Flow with no entry criteria runs every time any field on that record changes. For a busy opportunity record that gets updated dozens of times per deal, that means your automation fires constantly — most of the time doing nothing useful, but still consuming CPU and creating audit trail noise.
The more dangerous version: a Flow that checks a condition inside the Flow itself rather than in the entry criteria. The Flow still triggers and starts executing before it decides there's nothing to do. At scale, this looks like unexplained slowness and confusing debug logs.
Why it matters: Unnecessary Flow executions pile up. They slow save times, create automation loops where one Flow triggers another, and make debugging dramatically harder because you're sifting through irrelevant run history.
How to fix it: Define your entry criteria tightly. Use the "Only when a record is created or updated to meet the condition requirements" trigger option when you only want the Flow to run when something specifically relevant changes. The more precise your entry criteria, the less work the system does and the fewer surprises you get.
Mistake 3: No Fault Paths on Critical Elements
Every Flow element that touches the database — Get Records, Update Records, Create Records, Delete Records, callouts, Apex actions — can fail. When one fails with no fault path configured, Salesforce sends a generic error email to the running user (often a system admin who set up the Flow years ago and has since left the company), and the operation fails silently.
Most orgs have broken Flow automations they don't know about because the error emails go to an inactive user or a generic inbox nobody monitors.
Why it matters: Silent failures corrupt data, miss critical business processes, and are nearly impossible to debug after the fact because there's no record of what went wrong.
How to fix it: Add a fault path to every element that can fail. At minimum, that fault path should send a notification to a monitored inbox or Slack channel with the record ID, the Flow name and version, and the error message. Better: write errors to a custom Error Log object so you have a persistent record you can query and report on.
This isn't optional. If your Flow touches production data and has no fault handling, it has a silent failure mode you're not aware of.
Mistake 4: Hardcoded Record IDs and Values
It feels like a shortcut at the time: you need to assign records to a specific queue, or filter on a specific record type, so you copy the ID out of the URL and paste it directly into the Flow. Done.
Then someone deploys the Flow to a new sandbox. Or migrates to a new org. Or the record gets deleted and recreated. The ID no longer exists and the Flow breaks — usually in a way that's hard to trace because the error message references an ID, not a name.
Why it matters: Salesforce record IDs are environment-specific. The Queue ID in your production org is different from the one in your sandbox. Hardcoded IDs are deployment bombs.
How to fix it: Never hardcode record IDs. Instead, use Get Records to look up the record you need by a stable, human-readable field (like Name or Developer Name), then use that record's ID dynamically in the rest of the Flow. It adds one extra element and makes your Flow portable across environments.
The same applies to hardcoded picklist values, email addresses, and any other value that might change over time.
Mistake 5: Too Many Flows on the Same Object
Salesforce allows multiple record-triggered Flows on the same object. Teams often add Flows over time — one for notifications, one for field updates, one for creating related records — without ever looking at what's already there.
The result is an object with four or five separate Flows all triggering on the same conditions, executing in an unpredictable order, sometimes stepping on each other's updates, and collectively consuming far more resources than necessary.
Why it matters: Beyond the performance hit, multiple Flows on the same object make debugging extremely difficult. When something goes wrong, you have to trace through multiple Flow run histories to figure out which one caused the problem — and sometimes it's an interaction between two of them.
How to fix it: Consolidate. Salesforce's recommendation is one record-triggered Flow per object per trigger (before-save or after-save). If you need to do multiple things on the same trigger, do them in the same Flow using decision elements and parallel paths. This doesn't mean cramming everything into one tangled diagram — it means organizing related logic in one place where it can be seen and managed together.
Mistake 6: Building Flows That Only Work for the Running User's Permissions
Flows run in the context of a user's permissions by default. If a rep triggers a Flow that needs to update a field they don't have edit access to, or create a record on an object they can't see, the Flow fails — and the error message is confusing enough that the rep just tries again and gives up.
This surfaces constantly in orgs where the Flow was built and tested by an admin, who has access to everything, and then deployed to users who don't.
Why it matters: Permission-related Flow failures are the most common category of "it worked in testing" bugs. They're also the hardest to reproduce if you're debugging as an admin, because your permissions are different from the failing user's.
How to fix it: When building Flows that need elevated access, use the "Run in System Context" option for specific Flow types, or have an admin-level automation handle the privileged operations via invocable Apex while the user-level Flow handles the trigger and business logic. Test your Flows logged in as a representative user — not as an admin — before go-live.
Mistake 7: Flows That Have Never Been Reviewed After Go-Live
The most insidious Flow problem isn't a technical one. It's organizational.
Flows get built, tested, deployed — and then never looked at again. The business process changes. The team adds new fields. Someone fixes a related automation. And the original Flow keeps running against a reality it was never designed for, producing outputs that are subtly wrong and taking up to eighteen months to notice.
Why it matters: An automation that works incorrectly is often worse than no automation at all. Incorrect field updates corrupt historical data. Incorrect notifications create noise that users learn to ignore. Incorrect record creation creates cleanup debt that compounds over time.
How to fix it: Build a quarterly Flow review into your Salesforce maintenance process. Check which Flows are still active, which are still relevant, and whether they're still producing the right outputs. When you change a business process, update the Flows that support it at the same time — not as a follow-up item that never gets prioritized.
How to Audit Your Existing Flows
If you've inherited an org you didn't build, here's a quick triage process:
Go to Setup → Flows and sort by Last Modified. Flows that haven't been touched in two or more years are candidates for review.
Filter for Active flows and check the trigger type. Multiple record-triggered Flows on the same object are a red flag.
Open your error email inbox and search for "Salesforce Flow" errors from the past 90 days. Any Flow appearing repeatedly in errors needs immediate attention.
Check for fault paths by opening any Flow that touches DML operations. If there's no fault path on critical elements, add one before anything else.
Look for loops containing Get Records or DML elements. Those are your performance problems.
A basic Flow audit on an average org takes half a day. The findings almost always uncover something that's been silently failing for months.
The Bigger Picture
Flow problems don't usually announce themselves dramatically. They accumulate. A slow save time here, a missed notification there, a report that's off by a number nobody can explain. By the time someone decides to investigate, the issues have been compounding for months.
The best time to audit your Flows is before you add more automation. Building on top of a broken foundation doesn't make it more stable — it makes the eventual cleanup harder.
Sources
- 10 Salesforce Flow Mistakes That Break Automations — Cloud Vandana
- 10 Common Salesforce Flow Mistakes Admins Should Avoid — Lane Four
- Avoid Headaches With Error Management and Fault Paths in Salesforce Flow — Salesforce Ben
- Flow Best Practices — Salesforce Help
- Troubleshooting Flow Run Time Errors — Salesforce Help
- Salesforce Flow Best Practices for Efficient and Scalable Automation — Nick Frates