Why Isn't My Salesforce Flow Triggering?

A Salesforce administrator creates a Flow. Everything looks correct. The Flow is active. The record changes. Nothing happens. Or, in some ways more confusing, the Flow works correctly for some records and silently does not for others.

The immediate assumption is that Salesforce Flow itself is broken. In reality, the automation almost always behaved exactly as it was actually configured to behave. The real challenge is understanding why a specific record never qualified, why another piece of automation intervened first, or why the entire transaction failed before the Flow ever had a chance to finish. Salesforce automation on any single record can genuinely involve record-triggered Flows, scheduled paths, before-save Flows, after-save Flows, screen Flows, subflows, validation rules, duplicate rules, Apex triggers, approval processes, assignment rules, and external integrations, all potentially touching the same transaction. This guide explains how to identify exactly which one of these actually stopped your Flow from doing what you expected.

01First: Determine What Actually Failed

Before touching anything, determine which of these genuinely different situations you actually have. Did the Flow never start at all? Did it start and then exit immediately without completing? Did it follow a decision path you did not expect? Did it reach a genuine error? Did it finish successfully but produce a result different from what you assumed it would? Did it update the wrong record entirely? Did it trigger a separate automation that then changed things further? Or did an entirely different process cause the whole transaction to roll back after the Flow itself had already run correctly? Each of these represents a completely different troubleshooting path, and conflating them is the single most common reason Flow troubleshooting takes far longer than it needs to.

02Understanding The Salesforce Transaction

A record update is never simply record updated, then Flow runs. Salesforce's actual order of execution, verified directly against current Salesforce documentation and platform behavior, looks considerably more like this: system validation runs first, for a standard UI edit this includes page layout rules, field definitions, and maximum field length. Before-save record-triggered Flows execute next. All before triggers, meaning Apex code configured to run before the save, execute after that. Custom validation rules, along with most system validation such as confirming required fields are actually populated, run again at this point, now checking the record as it stands after any before-save Flow or before trigger has already modified it. Duplicate rules run next, and if a duplicate rule is configured to block, the entire transaction stops here, with nothing further executing at all. The record then saves to the database, but is not yet committed. All after triggers execute. Assignment rules run. Auto-response rules run. Workflow rules run, and if a workflow rule performs a field update, Salesforce runs one additional, tightly scoped mini-cycle: system validation and both before and after triggers fire one more time, and only one more time, to account for that new value, but custom validation rules, Flows, duplicate rules, other processes, and escalation rules are deliberately not re-run during this extra pass. Escalation rules execute. After-save record-triggered Flows and any other process-based automation execute at this stage, in an order Salesforce does not actually guarantee among each other. Roll-up summary calculations run against parent records where relevant, which sends those parent records through their own save procedure. And only once all of this has completed synchronously does Salesforce actually commit the transaction, after which point emails, asynchronous Apex, and any genuinely asynchronous Flow paths finally execute. It is also worth knowing directly that when both an Apex before trigger and a before-save Flow exist on the same object, the Apex trigger executes later in that pre-save sequence and effectively wins if both modify the same field, and the reverse is true after the save: an after-save Flow runs later than an Apex after trigger and effectively wins there instead. Genuinely understanding this sequence, rather than assuming a flat two-step record-then-Flow model, is what makes the rest of this guide actually make sense.

03Common Reasons A Salesforce Flow Doesn't Trigger

1. The Flow Is Not Active

An inactive Flow version, a deployment that moved metadata without actually activating the intended version, or a Flow accidentally deactivated during unrelated cleanup will all silently prevent any execution at all, with no error surfaced anywhere for anyone to notice.

2. The Wrong Flow Version Is Active

Salesforce Flows are versioned, and it is entirely possible for an older version to remain the active one while a newer version, containing the actual fix or feature someone is expecting, was built and saved but never explicitly activated. Confirming which specific version is currently active, not just which version was most recently edited, is a fast and easy first check.

3. The Record Never Met Entry Conditions

Field values, the specific operator used in a condition, AND versus OR logic across multiple conditions, formula evaluation, genuinely null values, and checkbox fields defaulting to false rather than true are all common causes of a record that looks, to a person, like it obviously should have qualified, while genuinely failing to satisfy the Flow's actual entry criteria as literally configured.

4. The Wrong Object Is Being Updated

An update happening on Opportunity Product rather than the parent Opportunity, on Lead rather than the Contact it was converted into, on Account rather than a related Person Account, or on Case rather than a related Task can all mean the change a person is actually watching for is happening on a completely different object than the one the Flow is actually built against.

5. Before-Save vs After-Save Was Chosen Incorrectly

A before-save Flow can update fields on the record currently being saved without triggering another full save operation, which makes it considerably more efficient for same-record field updates, but it cannot reliably perform actions like creating related records or calling out to external systems in the same way an after-save Flow can. Choosing the wrong one for a given task either produces avoidable extra transaction overhead or, in the more confusing direction, causes the Flow to simply be unable to do what it was actually built to do.

6. The Record Was Updated Through An API

Integration users, the Bulk API, the standard REST API, Data Loader, mass imports, and external systems writing directly to Salesforce can all update records in ways that behave meaningfully differently from a person editing a record through the standard user interface, particularly around which layout-specific validations apply and how batching interacts with governor limits. A Flow built and tested entirely against manual UI edits can behave differently once real integration traffic starts hitting the same object.

7. Validation Rules Blocked The Save

A validation rule failure rolls back the entire save, which means any before-save Flow logic that already ran is effectively undone along with everything else, and no after-save automation, including any after-save Flow, ever gets the chance to run at all. This is a genuinely common and easy to overlook cause of a Flow appearing to silently fail when the actual failure happened at the validation stage, several steps before the Flow the person is investigating ever would have executed.

8. Duplicate Rules Prevented Record Creation

A duplicate rule configured with a block action stops the entire transaction at that specific stage in the order of execution, before the record is even saved, which means nothing configured to run afterward, including any after-save Flow, ever executes. This is particularly relevant around lead conversion and contact creation, where duplicate matching rules are common and easy to forget about when troubleshooting a Flow that touches those same objects.

9. Apex Trigger Overrode The Result

Apex code can change field values, prevent a save outright, deliberately roll back a transaction, or throw an exception that halts everything. Because an Apex before trigger runs later than a before-save Flow in the actual order of execution, and an Apex after trigger runs before an after-save Flow, Apex code on the same object can quietly override a value a Flow just set, or prevent the Flow's intended outcome from ever actually being visible in the final saved record.

10. Another Flow Changed The Record Again

Multiple Flows on the same object, the actual execution order among after-save Flows and processes, which Salesforce does not guarantee, and genuinely conflicting field updates across separate automations can all produce a final result that looks nothing like what any single Flow, viewed in isolation, was actually built to produce.

11. A Scheduled Path Never Ran

Time-based scheduled paths depend on the specific waiting criteria actually being met, on the record still existing at the scheduled time, and on the record not having been updated in a way that caused the Flow to recalculate or cancel the originally scheduled action. A record deleted or significantly changed before its scheduled path was due to fire will simply never trigger it.

12. The Decision Element Used Unexpected Data

Variables holding a value different from what was assumed, genuinely blank values, formula results that differ from what a person expects when reading the formula casually, and comparisons involving null specifically, which does not always behave the way a simple equality check intuitively suggests, are all common causes of a decision element routing a record down an unexpected path.

13. Required Fields Were Missing

A required field left empty will cause standard system validation to reject the save outright, whether the record was created through the UI or through an API call, and this happens as part of the core order of execution regardless of which specific automation was actually trying to act on the record.

14. A Permission Prevented The Action

Object-level create, read, update, and delete permissions, field-level security specifically, the running user's profile, any permission sets layered on top of that profile, and sharing rules governing record-level access can all silently prevent a Flow from actually completing an action it was otherwise correctly configured to perform, particularly when a Flow is set to run in the context of the user triggering it rather than in system context.

15. Integration User Permissions Differ

A dedicated integration or automation user frequently has a genuinely different permission set, and sometimes a different profile entirely, than the human users a Flow was originally built and tested against, and production and sandbox environments can also diverge in their specific user and permission configuration over time. A Flow that works correctly for a person editing a record manually can behave completely differently when the same update arrives through an integration running as a separate, more restricted user.

16. Fault Paths Were Never Configured

A Flow element that fails with no fault path connected simply stops, often without producing any obvious, visible error to the person who triggered the underlying record change in the first place. This is one of the most common causes of a Flow that appears to silently do nothing, when it actually started, ran partway, and failed quietly at a specific element nobody built any handling for.

17. The Record Was Rolled Back

A failure anywhere later in the same transaction, whether from a validation rule, an Apex exception, or another automation entirely, rolls back everything in that transaction, including any changes a Flow already successfully made earlier in the same sequence. From the outside, this looks identical to the Flow itself having failed, even though the Flow's own logic executed perfectly correctly before something else undid all of it.

18. The Flow Hit Governor Limits

SOQL query limits, DML statement limits, CPU time limits, and Flow-specific element limits can all be exceeded during a large batch operation or a Flow containing a loop that processes far more records than it was originally designed and tested against, producing a failure that only appears at real production volume rather than during small-scale manual testing.

19. A Subflow Failed

A parent Flow calling a subflow depends entirely on that subflow actually completing successfully, and a failure inside the subflow needs to be debugged specifically within that subflow's own execution, not just at the parent level, since the parent Flow's own debug output may only show that the subflow call itself did not complete, without necessarily explaining why.

20. The Flow Worked Exactly As Designed

Sometimes there is no actual failure anywhere in the chain. The Flow ran, executed its configured logic precisely, and produced exactly the result it was built to produce. The only real gap is between what the Flow was actually designed to do and what the person investigating it assumed it was designed to do. This is worth taking seriously as a genuine possibility before assuming any technical failure occurred at all.

04Before-Save vs After-Save Flows

A before-save Flow runs earlier in the order of execution, before the record is written to the database, which makes it the more efficient choice specifically for updating fields on the same record currently being saved, since it avoids triggering an entirely separate save operation the way an after-save update would. An after-save Flow runs later, after the record has already been saved, and is the appropriate choice for actions that need the record to already have an ID, for creating or updating related records, and for anything genuinely needing to happen only once the original save has actually succeeded. A common and avoidable mistake is using an after-save Flow purely to update fields on the same record that triggered it, when a before-save Flow would accomplish the same outcome with less overhead, or, in the other direction, attempting same-record-only logic inside a before-save Flow when the actual requirement genuinely needs the after-save context instead.

05Record-Triggered Flow Entry Conditions

When A Record Is Created, When A Record Is Updated, When A Record Is Created Or Updated, and the choice between only running when specified conditions are met versus running on every single update, are all genuinely distinct options that produce meaningfully different behavior. Choosing Created rather than Created Or Updated will simply never fire again once a record already exists, no matter how many times it is subsequently edited. Choosing to run only when conditions become newly true, rather than every time the record is saved, means the Flow will not re-fire for an update that does not actually change whether those specific conditions are met, even if other fields on the record changed. This specific distinction, more than almost anything else on this list, explains why a Flow that clearly worked once for a given record does not appear to work again for a later, seemingly similar update to that same record.

06Scheduled Paths

A scheduled path depends on the actual scheduling configuration, on whatever record data it references still being accurate at the moment it is meant to fire, on the record not having been deleted before that time, and on the record not having been updated in a way that caused Salesforce to reevaluate or cancel the previously scheduled action. Testing a scheduled path requires either genuinely waiting for its scheduled time or using Salesforce's own available tools for reviewing scheduled, paused Flow interviews directly, and monitoring scheduled paths on an ongoing basis matters specifically because their failures tend to be delayed and easy to miss compared to an immediate, synchronous Flow failure.

07Integrations And Salesforce Flows

HubSpot, Zapier, Make, MuleSoft, custom APIs, ERP systems, marketing platforms, and external webhooks can all write to Salesforce in ways that interact with Flow automation differently than a manual UI edit does. The specific integration or automation user's permissions, how authentication is actually configured, whether an update is a full record write or a genuinely partial field-level update, whether the operation is happening through the Bulk API at real volume rather than a single record at a time, the timing of when a given update actually reaches Salesforce relative to other automation, and which fields the integration is actually allowed, by explicit design, to own and write to, all deserve deliberate attention. A Flow built and tested entirely against a human editing a record in the UI can behave in a genuinely different, unexpected way once the exact same field is instead being updated by an external integration running under its own separate user and its own separate assumptions.

08Salesforce Flow And Validation Rules

Validation rules frequently appear to break a Flow when the actual cause is entirely upstream of the Flow itself: the validation rule rejects the save before the Flow, particularly an after-save Flow, ever gets the opportunity to run at all. Isolating this means checking specifically whether the record in question actually saved successfully in the first place, independent of whatever the Flow was supposed to do afterward, since a rejected save explains a missing Flow result far more directly than any problem inside the Flow's own logic would.

09Salesforce Flow And Apex

Execution order matters directly here: an Apex before trigger runs after a before-save Flow and can therefore override whatever that Flow just set, while an Apex after trigger runs before an after-save Flow, meaning the Flow can see and act on whatever the Apex trigger already did. An unhandled exception thrown anywhere in Apex rolls back the entire transaction, taking any Flow changes with it. Custom triggers and other custom code sitting on the same object as a Flow genuinely need to be reviewed together, not evaluated in isolation, and a developer investigating a suspected Apex interaction should pull actual debug logs for the specific failing transaction rather than reasoning about the code from memory alone.

10Duplicate Rules

Matching rules define what actually counts as a duplicate. Duplicate rules define what happens when a match is found, whether that is simply a warning or an outright block. Lead conversion and contact creation specifically are common places where duplicate rules quietly interact with Flow automation, since a blocked creation stops the transaction at that specific stage in the order of execution, before anything configured to run afterward, including an after-save Flow, ever has the chance to execute. It is also worth knowing that API-driven record creation can be configured to behave differently with respect to duplicate rules than standard UI-based creation, which is worth confirming directly for the specific object and integration involved.

11Permissions

Profiles, permission sets, object-level create, read, update, and delete access, field-level security specifically, record-level sharing rules, and whether a given Flow is configured to run in system context or in the context of the user who actually triggered it, all affect whether a Flow that is otherwise perfectly configured can actually complete the action it was built to perform. A Flow that works flawlessly for an administrator testing it can fail silently, or fail with a permission-related error, for a standard user with a more restricted profile acting on the exact same record.

12How To Debug A Salesforce Flow

Choose one specific record rather than troubleshooting the entire automation abstractly. Verify the update actually occurred on that record in the first place. Confirm the Flow's entry conditions directly against that record's actual current field values. Review which specific Flow version is currently active. Use Salesforce's own Flow Debug capability to step through the Flow's actual execution directly. Review paused or scheduled Flow interviews where the situation genuinely involves a wait element or a scheduled path. Review Debug Logs for the specific transaction in question, particularly when Apex is potentially involved. Check validation rules on the relevant object directly. Review duplicate rules if the object and operation involved are ones duplicate rules would plausibly apply to. Review any Apex triggers sitting on the same object. Review every other Flow that also touches the same object, since execution order among after-save automations is not guaranteed. Review any integration that might have been the actual source of the update. And retest deliberately, with a controlled record, before considering the issue actually resolved. Isolate one single transaction fully before moving on to test anything else; testing several different scenarios simultaneously is what makes this kind of troubleshooting take far longer than it needs to.

13Monitoring Salesforce Automation

Debug Logs, paused Flow interviews, Salesforce's own Flow error email notifications, Setup-level automation monitoring, API logs on both the Salesforce side and whatever external system is involved, integration-specific logs, fault path connectors deliberately built to capture and surface failures, targeted email alerts for genuinely critical automation, a dedicated logging custom object for recording automation outcomes over time, and an operational dashboard summarizing all of this are all worth building deliberately rather than assuming Salesforce's own default behavior will surface every failure clearly on its own.

14Testing Before Production

Deliberately test record creation, a standard update, a deletion, a genuine bulk update at realistic volume, an API-driven update specifically, any scheduled path involved, a scenario that would plausibly trigger duplicate rules, a scenario involving a more restricted user's permissions rather than only an administrator's, a validation rule failure on purpose, genuinely blank and null values, a record with different ownership than the one used during initial testing, and an update arriving through whatever integration will actually be writing to the object in production. Testing only clean, ideal data produces a Flow that looks reliable right up until real production data and real production volume inevitably differ from that one clean test case.

15Common Design Mistakes

Building far more Flows than a given object actually needs, allowing genuinely conflicting automation to accumulate across Flows, Apex, and legacy Process Builder without anyone coordinating them, no documentation anywhere explaining what a given Flow actually does or why, no consistent naming standard, no fault paths configured anywhere, poorly defined entry criteria that unintentionally include or exclude more records than intended, hardcoded values that break the moment anything around them changes, permissions never actually considered during design, testing performed only against clean, ideal data, and no ongoing monitoring at all are the recurring mistakes across Salesforce orgs of every size and maturity level.

16Best Practices

Give each Flow one clear responsibility rather than trying to accomplish several unrelated things inside a single automation. Use genuinely descriptive, consistent naming so a Flow's purpose is obvious without opening it. Build real fault paths on every element with a meaningful chance of failing. Document what each Flow actually does and depends on. Test deliberately, including genuine edge cases, not just the happy path. Monitor actively rather than waiting for someone to notice a downstream symptom. Keep entry criteria consistent and intentional across related Flows on the same object. And review existing automation on an object before adding yet another Flow to it, rather than assuming a new Flow will simply coexist cleanly with whatever already exists.

17The Bigger Problem: Most Salesforce Automation Problems Are Architecture Problems

Businesses often contact us because a specific Flow is not triggering. After actually reviewing the Salesforce org, we frequently discover multiple competing Flows on the same object, legacy Process Builder automation that was never fully migrated or retired, genuine Apex conflicts nobody had previously mapped out, validation rules nobody currently at the company actually documented, duplicate rules interacting with automation in ways nobody anticipated, integration issues layered on top of all of it, underlying data quality problems, no monitoring anywhere, genuinely unclear ownership over who is responsible for which piece of automation, and years of accumulated technical debt. The specific Flow someone asked us to look at is very rarely the actual root problem. The broader automation architecture underneath it usually is.

18Why Businesses Reach Out To Us About This

Our team helps businesses diagnose Salesforce Flow failures down to their actual root cause, review overall automation architecture rather than just the one Flow someone happened to notice, consolidate redundant or conflicting Flows, migrate legacy Process Builder automation onto a coherent, modern foundation, build genuinely scalable Flows designed with execution order and permissions in mind from the start, troubleshoot the integrations actually feeding data into Salesforce, configure APIs correctly, review permissions systematically rather than assuming they are fine, prevent duplicate records at the source, improve ongoing monitoring, document the resulting automation clearly, and train administrators to maintain it confidently going forward. Rather than fixing one broken Flow, we help businesses build Salesforce automation that remains genuinely reliable as the organization continues to grow.

19If Your Salesforce Flow Isn't Triggering

If your Salesforce Flow isn't triggering, don't immediately rebuild it from scratch. Start by identifying whether the record actually qualified against the Flow's real entry conditions, whether another piece of automation intervened somewhere in the transaction, whether a validation rule or a permission genuinely blocked the underlying save, or whether the Flow actually executed correctly and simply produced a different outcome than you assumed it would. Following a structured troubleshooting process like this one will reveal the real cause considerably faster than randomly editing Flow logic and hoping something changes. If you need help diagnosing or redesigning Salesforce automation, our team can help.

20Follow One Record Through One Transaction

Salesforce Flow problems are almost always traceable. The key is following one specific record through one specific transaction, rather than reasoning about the automation abstractly. Successful troubleshooting genuinely depends on understanding entry criteria precisely, the actual execution order of everything touching that object, validation rules, duplicate rules, permissions, Apex interactions, external integrations, scheduled paths, and having real monitoring in place to begin with.

The fastest way to fix a Salesforce Flow is not rewriting the automation. It is understanding exactly where one specific record stopped moving through Salesforce's actual automation chain, and why.