Straight answer: two parts of that email matter. The line at the top naming the element that failed and the error it threw, and the interview details block below it listing every element the flow ran with the values each one received. Read those two, ignore the rest, and you have the cause most of the time. By default the email goes to whoever last modified the flow, which is the main reason nobody reads them.
The anatomy, top to bottom
The layout varies a little by flow type and release, but the blocks are consistent.
| Block | What it gives you |
|---|---|
| Subject line | The flow name, and often the failing element. This is what you build inbox rules on. |
| The error line | “An error occurred at element” plus the element’s API name and its type — FlowRecordUpdate, FlowRecordLookup, FlowActionCall. The type alone narrows the cause. |
| The error text | The platform’s own message, usually a Salesforce error code and sometimes an error id you can quote to support. |
| Flow details | Flow API name, flow type, version number, status, org id. The version number is the part people skip and then debug the wrong canvas. |
| Interview details | The interview label, the running user and their Id, start time, duration, and how the interview started — including the record that triggered it. |
| Element trace | Each element the interview executed, in order, with its inputs and outputs. This is the debug log you did not have to enable. |
| Variable values | The state of the flow’s resources at failure, including record fields. |
One consequence of that last row: these emails contain live record data, including anything a user typed into a screen. That is worth knowing before you set up an inbox rule that forwards them to an external ticketing address.
If a whole batch of interviews fails, you get either one email per failure or one email carrying an error per failure. Both happen, and both mean the same thing — the problem is not record-specific, it is your flow at volume.
Who receives it, and how to change that
Setup → Process Automation Settings → Send Process or Flow Error Email to. Two options:
- User Who Last Modified the Process or Flow — the default. The person who most recently saved a version of that flow gets every failure it produces.
- Apex Exception Email Recipients — the addresses configured on the Apex Exception Email page in Setup.
The setting is org-wide. You cannot route one flow’s errors differently from another’s through this dropdown, which is the single biggest argument for building your own notification inside fault paths.
Two things follow from the default that catch teams out. Renaming an element or fixing a typo makes you the recipient for every future failure of that flow. And when the last editor leaves, the mail keeps being generated for a mailbox nobody opens. Switching to the Apex exception recipients and pointing them at a distribution list survives staff changes, which is why it is worth doing on day one rather than after an outage.
Getting from the email to the actual cause
Four moves, in order.
- Note the version number, then open that version. Setup → Flows → your flow → Versions. If a draft has been saved since, the canvas you would open by default is not the one that ran.
- Find the element by its API name. The trace gives you the API name, not the label, and in an inherited org those can differ enough to matter. The gap is smaller in a flow whose elements were named for what they do.
- Read that element’s input values in the trace. Most failures are visible here without reproducing anything: an Id that is blank, a collection with zero items, a text value that is longer than the field, a lookup pointing at a record from the wrong object.
- Match the error text to its class. The wording tells you which layer rejected the operation.
| Error text contains | What it means |
|---|---|
FIELD_CUSTOM_VALIDATION_EXCEPTION |
A validation rule on the target object rejected the flow’s write. The rule’s message follows the code. |
REQUIRED_FIELD_MISSING |
The flow created a record without a field the object requires, usually because a variable was empty. |
Attempt to de-reference a null object |
An element touched a field on a record variable that was never populated, nearly always the output of a Get Records that matched nothing. |
INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY |
The write is fine, but the running context cannot access a related record it points to. |
ENTITY_IS_DELETED |
The record existed when the flow started and does not now. Common in scheduled and asynchronous paths. |
UNABLE_TO_LOCK_ROW |
Contention. Something else held the row, or its master record, past the platform’s wait. Expect it under concurrent load, not in test. |
CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY |
An Apex trigger on the target object threw. The trigger’s own error is appended — that is your real message. |
Too many SOQL queries: 101 |
A Get Records inside a loop, yours or somebody else’s on the same object. |
Apex CPU time limit exceeded |
The whole transaction ran past 10,000 ms synchronous. Your flow may be the victim rather than the cause. |
MIXED_DML_OPERATION |
The flow wrote a setup object such as User and a standard object in one transaction. |
Where the email lets you down is the FlowActionCall failure with a generic message. Action errors are frequently unhelpful, and the fix is to stop relying on the default email for those elements and log the inputs yourself in a fault path.
Why these emails stop being read
They fail as monitoring for structural reasons, not because your team is lazy.
There is no severity — a permanent misconfiguration and a one-off lock contention arrive looking identical. There is no deduplication, so a bad Data Loader run generates hundreds of near-identical messages and an inbox rule gets written that afternoon. The recipient is whoever last edited the flow, not whoever owns the process. And they contain record data, so they cannot simply be forwarded into a shared tool.
What to route them to instead, in increasing order of effort:
- Change the recipient to the Apex exception email addresses and point those at a monitored distribution list. Ten minutes, and it fixes the “goes to a former employee” problem permanently.
- Triage from Setup → Paused and Failed Flow Interviews rather than from the inbox. Same information, sorted, and it does not depend on anyone’s mail rules.
- Add fault paths that write to a log object — flow name, element,
{!$Flow.FaultMessage}, record Id, user, timestamp. Now failures are records, so you can report on them, count them, and see the one that happens 400 times a day.
Be aware of the trade before you take step three. A handled fault means the flow did not fail, so the default email stops arriving — you have replaced Salesforce’s notification with your own. Build the log and confirm it works before you add fault paths across the org, or you will swap noisy monitoring for none.
Frequently asked
Can I turn flow error emails off?
Not with a switch. The supported ways to stop a specific flow’s emails are to fix the failure or to handle it in a fault path. You can redirect all of them to the Apex exception recipients, which is a different thing from disabling them.
Why did I get hundreds of these at once?
A bulk load hit a failure that applies to every record. A validation rule, a missing required field, a limit. The volume is telling you the cause is systematic, so read one email carefully rather than all of them.
Why is the error email going to someone who left?
Because they were the last person to save a version of that flow, and the default recipient setting is still “user who last modified.” Change it to the Apex exception recipients and use a distribution list.
Do screen flow errors send the same email?
Yes, and the user simultaneously sees the unhandled fault message on screen. Those are the flows to fix first, because the failure is visible to somebody outside your team.
Does the email tell me which record failed?
Usually: the interview details name the triggering record, and the element trace shows the Ids passed to each element. What it does not give you is a link you can click for records outside the triggering object, so search on the Id.
References: the Salesforce Help documents “Troubleshooting Flow Run Time Errors”, “Select Flow and Process Error Email Recipients”, “What Happens When a Flow Fails?”, and “Customize What Happens When a Flow Fails”.
