5 Salesforce Flow Mistakes That Silently Break Your Automations

Flow is the most powerful automation tool Salesforce has ever shipped — and the easiest to get subtly wrong. These five mistakes won't throw errors. They'll just quietly do the wrong thing, sometimes for months, before anyone notices.

1. Running everything in one giant flow

The mega-flow with forty elements is tempting: one automation to rule them all. But a single record-triggered flow that handles create, update, five decision branches, and three subflows becomes untestable and terrifying to change.

Fix: split by trigger and concern — one flow per object per trigger context, kept small enough that you can explain it in one sentence. Small flows are debuggable flows.

2. Forgetting that "before-save" and "after-save" are different worlds

Before-save flows run fast and can update the triggering record without a DML element. After-save flows can do almost everything else — but they run later, cost more, and can't touch the triggering record directly. Mixing them up means either wasted DML operations or updates that silently never happen.

Fix: default to before-save for field updates on the same record; reserve after-save for creating related records, callouts, and anything that needs the record ID to exist.

3. No fault paths on anything that touches external data

Get Records, callouts, subflows — any of these can fail at runtime. A flow with no fault connector doesn't "handle" the failure; it just dies mid-run, sometimes after half the work is done. The user sees a generic error; you see nothing.

Fix: add fault paths to every element that can fail, and have them write something useful — a log record, a Chatter post to an admin group, an email. Silent failures are the ones that cost you weekends.

4. Hard-coding values that will change

Record type IDs, queue IDs, magic strings, email addresses baked into flow formulas — all of these break the day someone refreshes a sandbox, renames a queue, or changes a process. And because flows don't have compile-time checks against your data, you find out in production.

Fix: use custom metadata types or custom labels for anything that varies by environment or might change. Your future self, debugging at 11 PM, will thank you.

5. Treating screen flows like they're "just UI"

Screen flows are where users actually meet your automation — and sloppy screen flow UX is where adoption dies. Walls of required fields, no guidance text, error messages written for developers instead of humans. Users don't hate automation; they hate automation that wastes their time.

Fix: design screens like a product: one decision per screen, plain-language labels, sensible defaults, and styling that matches how people actually work. (Spring '26 made this much easier — custom styling for screen flows finally lets Flow builders control the look properly. I wrote a full guide on it here: Spring '26 Custom Styling for Screen Flows.)

The Pattern

Every one of these mistakes shares a root cause: building the flow that works in the demo instead of the flow that survives real users, real data, and real change. Build small, handle faults, never hard-code, and respect the screen.

Your automations will still break sometimes. But at least they'll break loudly — and loudly is fixable.

Rohan Mehta is a Salesforce writer at Way2Force — practical guides on Salesforce Flow, automation, and CRM.