Briefly: almost always one of three things — the version you edited is not the version that is active, the entry conditions never evaluate true for your record, or the trigger type does not match the operation you performed. Check them in that order, and confirm with a debug log instead of re-reading the flow canvas.
“Not firing” is two different bugs wearing the same shirt. Either the interview never started, or it started and did nothing you can see. Those share almost no causes, so separate them first.
First, establish whether the interview ever started
Do this before forming a theory.
- Setup → Debug Logs → New, add a trace flag for the user making the change, with the Workflow category set to FINER.
- Reproduce the change exactly as the user does it — same object, same fields, same UI.
- Open the log and search for
FLOW_START_INTERVIEWS.
| What the log shows | What it means | Go to |
|---|---|---|
No FLOW_START_INTERVIEWS at all |
The flow was never invoked | Causes 1 to 6 |
An interview starts, then FLOW_ELEMENT_BEGIN lines |
It ran — this is logic, or the result was overwritten later | Causes 7 and 8 |
| No log at all for the save | Your trace flag expired or covers the wrong user | Re-create the trace flag |
Also open Setup → Paused and Failed Flow Interviews. From the user’s side, a flow failing on every record looks identical to one that never fires.
Causes, in the order worth checking
1. The active version is not the version you edited
Only one version can be active at a time, and activating one deactivates the previous. Open Setup → Flows → your flow and look at the Versions list: find the version carrying the Active status, open that version, and confirm your change is in it. Editing an active flow creates a draft, and the draft does nothing until you activate it.
The deployment case catches more people. Flows active in a sandbox deploy to production as inactive by default, so a change set that “went in fine” leaves you with a dormant flow and no error anywhere.
2. The entry conditions never match
Open the flow, click Debug, and run it against the record that should have triggered it. Debug tells you whether the start element passed, which confirms or kills this theory in a minute.
The usual culprits: comparing against a picklist label instead of the API value, a blank-versus-null mismatch, a formula condition returning null because one referenced field is empty, or a multi-select picklist compared with equals rather than contains. Note that ISCLONE() always evaluates to FALSE in debug mode, so a flow relying on it behaves differently there than in real use.
3. The trigger type does not match the operation
“A record is updated” does not include the insert. If a value arrives already set at creation (from an integration, a Data Loader file, a Quick Action with prefilled fields) an update-only flow never sees it. Switch to created-or-updated and re-test both paths. They often need different logic.
4. “Only when a record is updated to meet the condition requirements” excludes your case
This setting sits under the entry conditions and it is the most misread control in Flow Builder. With it on, the flow runs only when the record goes from failing at least one condition to meeting all of them. If the record already met the conditions before your update and still meets them after, the flow does not run — by design.
That is what you want for a status transition and exactly wrong when the flow must react to every change on a qualifying record. Turn it off for the second case and handle the extra executions deliberately, rather than letting one checkbox stand in for design.
5. The save never got as far as your flow
An after-save flow runs late — after both trigger phases and after workflow rules, per Triggers and Order of Execution. A validation rule, a required field, or a before trigger that throws ends the save before your flow gets a turn, and the user reports “the automation didn’t run” instead of “I got an error.” Ask whether the record actually saved. If the edit did not stick, the flow is innocent.
6. The change came from an operation that does not fire flows
Record-triggered flows follow the same exclusions as Apex triggers. Operations That Don’t Invoke Triggers lists them. The ones that bite in practice are cascade deletes (only the record you deleted fires anything), mass address updates, mass campaign status changes, mass division transfers, opportunity owner changes that follow an account owner change, and person-account record type conversions.
Add the changes that are not saves at all: roll-up summary recalculation and formula results. If your entry condition watches a roll-up field, the roll-up moving will never trigger it. Trigger on the child record instead. Bulk API and Data Loader, by contrast, fire flows normally, in batches.
7. Permissions. Rarely the cause, occasionally the whole cause
Record-triggered flows run in system context, so the triggering user’s object and field permissions do not stop the flow from running or writing. No “Run Flows” permission is involved either, that governs screen flows.
Where the running user still matters: an Apex action may enforce sharing, a subflow can be set to run in user context, and a lookup field the user cannot write stays null. Salesforce’s own example is a case created from an account detail page where Case.AccountId is read-only for that user: the field arrives empty, and a flow keyed off it has nothing to work with.
8. You are asking a before-save flow to do after-save work
Before-save flows support a short list of elements (Assignment, Decision, Get Records, Loop), and Flow Builder simply does not offer the rest. If you built the flow expecting it to create a task or call an action, that capability was never there to fail.
The subtler version: on create, a before-save flow has no record Id and no system field values yet, so a Get Records filtered on the record’s own Id returns nothing and every downstream branch silently takes the empty path.
Confirming the fix, including at 200 records
Re-run the same trace and count FLOW_START_INTERVIEWS entries. One per user action, and the element trace ending where you expect.
Then load 200 records at once through Data Loader with the same trace on. A flow that works on one record and dies at volume produces the identical user report (“it doesn’t run”) because the batch failed and rolled back. Check Paused and Failed Flow Interviews afterwards, and run Salesforce Code Analyzer’s flow rules while you are there: MissingFaultHandler and DbInLoop flag the patterns that become “it stopped working” reports later.
Frequently asked
Why did the flow work in the sandbox and not in production?
Check whether it is active. Flows that were active in the sandbox deploy as inactive by default, and nothing in the deployment result tells you the automation is now dormant. Data differences in entry conditions are the second suspect.
My flow fires for me but not for other users. Why?
Because their save is failing before the flow runs, or because a field your flow depends on is read-only for them and arrives null. The flow itself runs in system context, so it is not being blocked by their profile.
Does a record-triggered flow fire when an Apex trigger updates the record?
Yes. DML from Apex is a normal save and goes through the save order, flows included. This is also how recursion loops get built between a trigger and a flow on the same object.
Will a flow fire on records changed by another flow?
An after-save flow’s update to a different record fires that object’s flows. Flow’s recursion control stops a flow re-firing itself on the same record, but it does not stop flow A and flow B from triggering each other.
Can I see which flows exist on an object?
Setup → Flows, then filter the list view by triggering object. Do this before debugging anything. An inherited org usually has more automation on the object than anyone remembers, including the flow quietly undoing your field update.
References: Triggers and Order of Execution and Operations That Don’t Invoke Triggers, Apex Developer Guide. Plus the Salesforce Help documents “Record-Triggered Flow Considerations”, “How Entry Conditions Work in Record-Triggered Flows”, “Activate or Deactivate a Flow”, and “Deploy Processes and Flows as Active”.
