Short answer: a record-triggered flow on the object failed, and because it ran in the save transaction it took the whole DML down with it. Find the flow error email (it names the element that failed and its input values), and fix that element or give it a fault path. Setup → Flows, filter to the object, and check every active record-triggered flow, not just the one you were working on.
What the platform means by it
The SOAP API reference defines CANNOT_EXECUTE_FLOW_TRIGGER as “the flow trigger or the flow failed to execute. Try again. If the issue persists, debug the flow in Flow Builder.” The “try again” is misleading — a transient retry almost never helps. Treat it as “a flow blew up during the save.”
The important consequence is the blast radius. The flow ran inside the transaction that was saving your record, so its failure rolls the transaction back. Your insert did not partially succeed and then get a flow error. Nothing committed, including anything the flow itself had already written.
That is why this error shows up on API loads, on Apex DML, and on a user clicking Save, all with the same underlying cause. The flow does not care who started the save.
Read the flow error email first
Do this before you open Flow Builder. When a flow run fails, Salesforce sends an email containing the error message, details about each flow element the flow ran, and a link to view the failed flow in Flow Builder. It goes to the admin who last modified the flow, or to the Apex exception email recipients, depending on the org’s configuration.
The element-by-element trace is the valuable part. It shows you the path the flow actually took and the values it was working with, which is information you cannot reconstruct from the error message alone.
Two settings determine whether you get this email at all, and both are worth checking now rather than during an incident:
- Setup → Process Automation Settings controls who receives flow and process error emails. The default sends to the flow’s last modifier, which is often the wrong person once the builder has moved on. Point it at a monitored address.
- The email arrives after the transaction rolls back, so if the user retried and it succeeded on the second attempt, the email is still your only record of the first failure.
If the mail never arrives, the flow may be running in a context that suppresses it, or the recipient setting points somewhere nobody reads. Check the setting before concluding the flow did not fail.
Causes, most frequent first
1. An element failed and there is no fault path
This is the default outcome, not an edge case. An unhandled failure in a Create Records, Update Records, Delete Records, Get Records, or Action element stops the flow and fails the save.
The usual culprits: a Create Records element missing a required field, an Update Records element hitting a validation rule on the target object, an Apex action throwing, or a Get Records element returning nothing and a later element dereferencing the empty result.
The fix is a fault connector on every element that touches data. Salesforce Help documents this as a best practice in “Customize What Happens When a Flow Fails” and “Configure Every Fault Path to Send You an Email” — the recommendation is to configure fault connectors so you always receive an email when a flow fails, and to include the current values of the flow’s resources in that email.
A fault path does not make the failure go away. It gives you the choice of what happens next: log it and continue, show the user a readable message, or fail deliberately with an error you wrote. Choose consciously.
2. A validation rule on the record the flow is writing
Your flow updates a related record, that record has a validation rule, the rule rejects the update, and the original save fails with a flow error. The message in the email will be the validation rule’s own text.
This one is worth understanding structurally, because it means a validation rule on object B can block saves on object A through a flow neither team knew about. When it happens, decide which side is wrong: either the flow is writing a value that genuinely violates a business rule, or the rule needs to accommodate automated updates. Do not reflexively bypass the rule.
3. Permissions of the running user
A record-triggered flow runs in the context of the user who triggered it, unless it is configured otherwise. So a flow that works for you as an admin fails for a standard user, a community user, or an integration user without access to the objects the flow reads and writes.
Flow Builder lets you set how the flow runs — in the user’s context with permissions enforced, or in system context. Open the flow, click the canvas background, and check the version properties. Running in system context makes the error disappear and removes the security model from that path, so use it where the automation is genuinely a platform-level process, not as a fix for a permission gap you have not diagnosed.
Test as the actual user rather than reasoning about it. Salesforce Help’s flow troubleshooting guidance says the same: test the flow as different users to check for permission or access issues.
4. No active version, or the wrong active version
A flow with no active version does not run, which produces missing automation rather than this error. The version of the problem that does produce it: you activated a new version that has a bug the old one did not, and every save on the object now fails.
Check the version list in Setup → Flows → the flow. If the failures started at a deploy or an activation, deactivating and reactivating the previous version is the fastest rollback available. Do that first, then debug the new version in a sandbox.
5. A callout in a synchronous path
A record-triggered flow fails if it tries to access external data during its synchronous run path, because the platform does not allow callouts to external services while a record is saving. If your flow calls an external service, an Apex action that makes a callout, or reads external objects, that work has to move to the flow’s asynchronous path.
In Flow Builder, a record-triggered flow can add an asynchronous path that runs after the transaction commits. Callouts belong there. The tradeoff is that the asynchronous path cannot block the save, so you lose the ability to reject a record based on what the external system says, which is usually the right trade, because blocking a save on a third-party response is fragile anyway.
6. Governor limits shared with everything else in the transaction
The flow’s SOQL queries and DML statements count against the same transaction limits as triggers and Apex on the object. On a 200-record load, a flow doing a Get Records inside a loop will exhaust the query limit and fail. The flow works perfectly on a single record.
Two structural fixes, in order of payoff: move Get Records elements out of loops and query once with a collection, and consolidate multiple record-triggered flows on the same object into one. Ten flows on Account each doing their own Get Records is ten times the query count for the same work.
Diagnosing it
Reproduce in the Flow Builder debugger. Open the flow, click Debug, and supply a record that fails. For record-triggered flows you select an existing record as the trigger. The debugger runs the flow element by element and shows you where it stops and what the variable values were — the same information as the email, but interactive and re-runnable.
From the flow error email you can jump straight in: the email includes a link to debug the error in Flow Builder.
Verify the entry criteria actually matched. Salesforce Help’s troubleshooting guidance lists this first for record-triggered flows, and it is a real trap in the other direction too — a flow you thought could not have run on this record did, because the criteria are looser than you remember. Read the Start element’s condition requirements against the actual field values on the failing record.
Turn on a debug log and look at the whole transaction. Setup → Debug Logs → New, add the user, reproduce the save. Set the Workflow category high — the Salesforce Help documents “Debug Log Levels” and “Debug Log Details” cover which category captures which events. The log shows you the order things ran in, which matters when a flow and a trigger are both involved.
Check which flows exist on the object before assuming. This query lists them without clicking through Setup:
sf data query --use-tooling-api \
--query "SELECT DeveloperName, ProcessType, TriggerType, Status, VersionNumber FROM Flow WHERE Status = 'Active' AND ProcessType = 'AutoLaunchedFlow'"Orgs accumulate flows. I have opened orgs with six active record-triggered flows on Account, three of them built by people who had left, and the failing one was never the one anybody suspected.
Isolate by deactivation when you have several candidates. In a sandbox, deactivate all record-triggered flows on the object, confirm the save succeeds, then reactivate one at a time. Crude, but it is definitive and often faster than reading five flows carefully.
Naming things properly prevents more of this than anything else
The flow error email lists the elements the flow ran, by their labels. If those labels are “Get Records 0”, “Decision 1”, and “Assignment 2”, the email tells you nothing and you are back to reading the canvas. Salesforce Help’s own troubleshooting advice makes this point: add descriptive labels and API names to flow elements and resources to make error emails easier to interpret.
This costs seconds while building and saves an hour during an incident. “Get Active Contract for Account” in an error email is a diagnosis; “Get Records 0” is a scavenger hunt.
Beyond naming, three things that materially reduce how often you see this error:
Fault path on every data element. Not on the decisions and assignments — on anything that reads or writes records or calls an action. Route them all to a single fault handler that records what happened.
One record-triggered flow per object per timing. One before-save and one after-save, with decisions inside, rather than eight flows that each run independently. This bounds your query and DML consumption, makes the order of operations explicit rather than unspecified, and means there is exactly one place to look when a save fails.
Test at volume before activating. Load 200 records in a sandbox against the new version. A flow that passes single-record debugging and fails a 200-record load is the most common production surprise here, and it is entirely preventable in ten minutes.
Frequently asked
Does a failed flow roll back the record save?
Yes. A record-triggered flow in the synchronous path runs inside the save transaction, so an unhandled failure rolls the whole transaction back, including anything the flow itself had written.
Where does the flow error email go?
To the admin who last modified the flow, or to the Apex exception email recipients, depending on your org’s configuration. Setup → Process Automation Settings controls it. Point it at a monitored address rather than an individual.
Does adding a fault path stop the DML from failing?
It stops the unhandled failure. What happens next is whatever you route the fault connector to: you can log and let the save proceed, or you can fail deliberately with a message you wrote. The fault path gives you the choice. It does not make the underlying problem go away.
Why does it work for me and fail for my users?
The flow runs in the triggering user’s context unless configured otherwise, so it is subject to their object and field permissions and sharing. Test as an actual user with their profile and permission sets before assuming the flow logic is wrong.
Can I make a callout from a record-triggered flow?
Not in the synchronous path. The platform blocks callouts to external services while a record is saving. Move the callout to the flow’s asynchronous path, which runs after the transaction commits and therefore cannot block the save.
Reference: Core Data Types Used in API Calls (SOAP API Developer Guide), Triggers and Order of Execution and Debug Log (Apex Developer Guide). Flow behaviour per the Salesforce Help documents “Troubleshoot Flow Errors”, “Customize What Happens When a Flow Fails”, “Configure Every Fault Path to Send You an Email”, “Select Flow and Process Error Email Recipients”, “Record-Triggered Flow Considerations”, “Debug Log Levels”, and “Debug Log Details”.
