Why Is My Salesforce Flow Not Triggering? The Full Diagnostic Guide

You built the Flow, activated it, and saved a test record — then nothing happens. No debug log entry. No field update. No email. If you’ve spent an afternoon staring at Setup asking why is my Salesforce Flow not triggering, you’re in familiar company. Almost every “silent” Flow failure traces back to one of ten specific causes, and each one has a two-minute check that either confirms or rules it out. Work through this list in order.

1. The Flow Is Inactive (or the Wrong Version Is Active)

Start here. Every Flow has a version history, and only one version can be active at a time. If you edited a Flow yesterday and hit Save without activating the new version, the old version is still running — or worse, no version is active.

Fix: Setup → Flows → open the Flow → check the version list on the right. Look for the “Active” badge. If the newest version isn’t the active one, activate it explicitly.

2. The Trigger Event Doesn’t Match the Record Change

Record-triggered Flows fire on one of three events: A record is created, A record is updated, or A record is created or updated. If your Flow is set to fire only on Create and you’re testing by editing an existing record, no amount of matching entry criteria will help — the Flow will never enter its evaluation stage.

Fix: Open the Flow, click Start element → Configure Trigger. Confirm the “Trigger the Flow When” option matches your test scenario. This is the single most common oversight when consolidating logic per our guide on consolidating multiple Process Builders into one Flow — a Process Builder set to “created or updated” migrated to a Flow that only handles “created” silently loses half its coverage.

3. Entry Conditions Aren’t Met by the Test Record

Entry conditions are AND-based by default. If your Flow requires Amount > 10000 AND StageName = 'Qualification' and your test Opportunity is at $12,000 in Prospecting, the Flow will not fire — one condition failed the AND.

Fix: Open the Flow → Start element → Set Entry Conditions. Read the criteria out loud against your test record’s actual field values. Also confirm the “Optimize the Flow for” setting matches your intent — “Only when a record is updated to meet the condition requirements” is much narrower than “Every time a record is updated” and often surprises people.

4. The Running User Lacks Object or Field Access

Flows run in one of two contexts: System Context (bypasses profile/permission checks) or User or System Context, Depends on How Flow Is Launched. If the Flow is running in user context and the triggering user’s profile lacks Read access on a related object the Flow tries to query, the Flow can silently exit without an error visible to the admin.

Fix: Open the Flow → Show Advanced on the Start element → check “How to Run the Flow.” For record-triggered Flows that operate on system-wide logic, set this to System Context With Sharing — Enforces Record-Level Access. For Screen Flows launched by users, evaluate profile-level access on every object the Flow touches.

5. Salesforce Auto-Disabled the Flow After Repeated Failures

If a Flow throws errors on enough consecutive runs, Salesforce may pause or deactivate it and email the last saved-by user. That email often lands nowhere useful, especially when the “saved by” user left the company and IT deactivated their account.

Fix: Setup → Process Automation → Paused Flow Interviews. Also check Setup → Email Log for recent “Flow Error Occurred” emails. Reactivate the Flow and address the underlying error before it re-fails.

6. A Bulk Load or API Insert Bypassed the Flow

Data Import Wizard, Data Loader, and Bulk API 2.0 calls all execute Flows by default — but individual apps and integrations sometimes use the API in a way that disables triggers and Flows for performance. This is common with ETL tools, migration scripts, and legacy data-sync integrations.

Fix: If the “trigger” was a bulk load, insert one test record manually through the UI. If the Flow fires on the manual insert but not the bulk load, the load is bypassing automation. Check the integration’s configuration for a “disable triggers” or “run without workflows” flag.

7. A Required Field the Flow Depends On Is Null

If your Flow references a field that is null on the triggering record — especially inside a formula, a decision element, or an Assignment — the Flow may hit a null-pointer error and silently exit. Debug logs will show the fault; the UI just shows nothing happening.

Fix: Add Debug on the Start element (or use “Debug on Canvas”) with a record ID from your test scenario. Salesforce highlights exactly which step in the Flow the null value causes to fail.

8. Another Automation Fires First and Changes the Qualifying Data

Order of execution matters. If a Before-Save Flow, an Apex trigger, or a Validation Rule modifies the field your record-triggered Flow uses in its entry criteria before your Flow evaluates it, your Flow legitimately does not meet its conditions anymore — even though the original save should have qualified.

Fix: Use the Debug Log with your Flow’s user and re-run the scenario. Look for other automations that fire between the record save and your Flow’s evaluation. The fix is usually to move the entry condition to a decision element inside the Flow, so it checks the value at the Flow’s execution moment instead of at the trigger evaluation moment.

9. Recursion Prevention Blocked the Second Run

If your Flow updates the triggering record and that update qualifies for the same Flow again, Salesforce blocks the second invocation to prevent infinite recursion. This is a feature, not a bug — but it looks like “the Flow ran once and then stopped triggering” from the admin’s perspective.

Fix: Restructure the Flow so it only updates fields that don’t re-qualify the record, or split the automation into two Flows with narrower entry conditions on the second one. Never disable recursion prevention.

10. The Debug Log Filter Is Hiding the Real Answer

This is the last-mile issue. You add a Debug Log to the running user, save the test record — and still see nothing. Debug logs default to filtering out Flow-level detail unless you explicitly bump the Workflow log category to Fine or Finer.

Fix: Setup → Debug Logs → New for your user → Debug Level = SFDC_DevConsole (or create a custom level). Set Workflow to Finer. Reproduce the scenario. The log now shows every Flow entry point evaluation, including the exact reason your Flow didn’t fire.

Frequently Asked Questions

Do Screen Flows have the same trigger issues as record-triggered Flows?

No — Screen Flows are user-invoked, so they either open when clicked or they don’t. The overlap is around permissions (Reason #4) and null values (Reason #7). If you’re troubleshooting a Screen Flow for use cases like the one in our guide on how to track billable hours in Salesforce, focus on those two categories first.

My Flow used to fire and now it doesn’t. What changed?

Check Setup Audit Trail for the last 30 days on your target object. New Validation Rules, changed Field-Level Security, a new Before-Save Flow, or a profile-permission change are the four most common “something changed” causes.

Can two Flows on the same object cause each other to not trigger?

Yes — when multiple record-triggered Flows exist on the same object with overlapping conditions, Salesforce leaves the execution order undefined. Consolidating them into one Flow eliminates that class of failure entirely.

Should I look at Flow Interviews or Paused Flows when troubleshooting?

Both. Paused Flow Interviews list Flows that hit an error and are waiting for admin intervention. The Flow Interview log (Setup → Flow Interview) shows every Flow that recently completed or failed — a first stop when a Flow ran but did the wrong thing.