Declarative automation that never ran
Key Takeaway
When automation never ran, the cause is usually in how it was set to start. Check the trigger event and entry conditions first, then whether a scheduled path was queued and whether it ran.
Sometimes a flow or a scheduled action should have run but didn't. The cause is usually in how it was set to start: the trigger event, the entry conditions, the schedule, the running user, or a limit. Admins find the cause in four ways. They check pending items on the Time-Based Automations page, read error emails, read debug log events, and replay the automation with Flow Builder's testing and debugging tools.
Check the trigger and entry conditions
A record-triggered flow runs when someone creates, updates, or deletes a record, but only if the record passes the entry conditions in the flow's Start element. So when a flow never ran, check both the event the user caused and the conditions the record had to meet.
Entry conditions can use one of these options:
- "All Conditions Are Met (AND)"
- "Any Condition Is Met (OR)"
- "Custom Condition Logic"
- "Formula Evaluates to True"
For updated records, the "When to Run the Flow for Updated Records" setting also controls when the flow runs.
If the setting is "Every time a record is updated and meets the condition requirements"...
The flow runs every time the record is updated and meets the conditions.
If the setting is "Only when a record is updated to meet the condition requirements"...
The flow runs only when the old version of the record didn't meet the conditions and the new version does.
A record-triggered flow on Case has the entry condition Priority equals High. The flow is set to run only when a record is updated to meet the condition requirements. Dana edits the Subject on a case whose Priority is already High. The old version of the record already met the condition, so the flow doesn't run. Next, Dana changes another case's Priority from Medium to High. The old version didn't meet the condition and the new version does, so the flow runs.
Restoring a record from the Recycle Bin doesn't start a record-triggered flow, because record-triggered flows don't support the after-undelete context. Automation that must run when a record is restored needs an Apex trigger.
A flow can also be built to skip some users on purpose. Suppose an entry condition of Formula Evaluates to True checks a custom permission with $Permission. The flow then doesn't run for users who have that permission. Salesforce makes this check before it creates a flow interview.
Flow Trigger Explorer shows all flows on an object in one view, so admins can understand and troubleshoot an object's automation without reading code. Admins can also use Flow Trigger Explorer to set a relative run order for multiple flows on the same object.