One pink element can take down an org
Flow made automation available to people who do not write Apex. It did not remove the limits that Apex has to respect. Every Flow runs inside the same transaction, against the same governor limits, as the code it replaced — and the builder will happily let you drag a Update Records element inside a loop without a single warning.
On one record it works. On 200 it consumes 200 DML statements against a limit of 150, and every save on that object starts failing org-wide. The Flow did not change. The volume did.
The loop problems, and why they are invisible
Two anti-patterns cause the majority of Flow-related outages: a DML element inside a loop, and a Get Records inside a loop. Both are invisible in testing because a single-record test never crosses the limit. Both are trivially fixable — collect records into a collection variable inside the loop, then perform one DML after it — and both keep appearing because the builder does not flag them.
The audit walks each one with the specific limit it breaches and the exact restructure that fixes it.
Fault paths are not optional
Every DML element in a Flow can fail. Without a fault path, that failure surfaces to the user as an unhandled exception — a wall of technical text on a screen flow, or a silent failure and an error email on a record-triggered one. Neither is acceptable in production.
The audit covers where fault paths are mandatory, what to do on that path, and why an error that is caught and logged is a completely different operational problem from one that is not.
Architecture problems that only show up later
Several entries are not about limits at all. One mega-flow per object becomes unmaintainable and untestable within a year. Missing entry conditions mean the Flow runs on every single save, burning CPU on records it will immediately ignore. Hardcoded IDs work until you deploy to another org.
And one entry argues the opposite of the rest: sometimes the correct answer is a validation rule, not a Flow at all. Knowing when not to build automation is part of building it well. The audit closes with a printable checklist to run before every deploy.
What’s inside
- DML and Get Records inside a loop — the two that cause most outages
- After-save flow updating its own trigger record
- Missing fault paths on every DML element
- Unguarded recursion and re-triggering
- One mega-flow per object versus properly scoped entry conditions
- Hardcoded IDs, unbatched scheduled flows, hand-built collections
- When a validation rule is the right answer and a Flow is not
- A printable self-audit checklist to run before every deploy
