Flows rarely fail with fireworks. They fail quietly—until someone notices a week later and you get the Slack message: “Hey… was this supposed to happen?”
So I add guardrails up front. Not because it’s elegant, but because it saves time, protects the business, and keeps you out of the blame game.
Here are the guardrails I reach for first.
Guardrail #1: don’t run on every update
If your flow exists to handle Status, it shouldn’t fire when someone edits a description at midnight.
Tight entry criteria. Use “is changed” checks. Make it boring.
Guardrail #2: recursion is not a feature
If an after-save flow updates the same record, assume it can loop.
Fixes that hold up:
- use before-save for same-record field updates
- only update when the value will actually change
- avoid the “update record” element as emotional support
Guardrail #3: errors should be loud
Fault paths exist for a reason. Use them.
Minimum setup:
Create an Automation_Error__c object and log:
- flow name
- record id
- error message
- running user
- timestamp
Now you can build a report called “Automation failures.” Wild concept: knowing what’s broken.
Guardrail #4: bypass should be permission-based
Avoid:
- bypass checkboxes on records
- “skip if username contains integration”
Prefer:
- Custom Permission:
Automation_Bypass - Entry condition:
NOT($Permission.Automation_Bypass)
Bypass becomes explicit, auditable, temporary.
Guardrail #5: name flows like you want to keep them
Bad: Flow 12
Better: Case - Set Priority (Before Save)
Future-you is a stakeholder too.
Quick checklist
- entry criteria tight
- recursion risk removed or guarded
- fault paths log
- bypass uses Custom Permission
- tested as normal + integration user