An unhandled fault has occurred in this flow
A Flow ran into an error somewhere mid-run and had nowhere to go. By default Salesforce sends the unhandled-fault email to the running user (or the flow owner) with a stack trace. The fix is almost always to add a Fault path on the failing element so the flow handles its own errors gracefully.
Also seen asAn unhandled fault has occurred in this flow·An unhandled fault has occurred·Flow Error: An unhandled fault has occurred
A Flow without explicit error handling treats every failure as fatal: the flow stops, the running user gets an email titled "An unhandled fault has occurred in this flow", and (depending on context) the user sees a generic error screen.
How to read the email
The email body shows:
- The flow name and the running user
- The element where the failure happened (often a Get Records, Update Records, or Action)
- The actual error message — this is the part that matters
Common patterns in the actual error:
| Inner error | What it means |
|---|---|
INVALID_CROSS_REFERENCE_KEY | A reference field references a record the running user can't see |
REQUIRED_FIELD_MISSING | An Update / Create Records assignment skipped a required field |
FIELD_CUSTOM_VALIDATION_EXCEPTION | A validation rule blocked the change |
Too many SOQL queries | The flow + downstream Apex blew through the 100-query budget |
INVALID_FIELD_FOR_INSERT_UPDATE | You're writing to a formula or read-only field |
The fix: Fault paths
Every "Get Records" / "Create Records" / "Update Records" / "Action" element in Flow Builder can have a dotted-line Fault connector. Drag it to a custom error handler:
- Add a Screen (for screen flows) or Email Alert action that says what went wrong.
- Use the global
{!$Flow.FaultMessage}variable to surface the actual message instead of the generic email. - End on a defined terminal element.
For a record-triggered flow that should silently continue when a non-critical step fails, route the fault path back into the main path after the optional step. The flow finishes successfully and you log the issue without bothering the user.
Stop the email
If you want to suppress the unhandled-fault email entirely while you're triaging:
- Process Builder / Flow → on the flow's properties, set "How to Run the Flow if a Fault Occurs" to use a custom email or send no email.
- Org default → Setup → Process Automation Settings → "Process Email Recipient" — change from the default running-user-or-default-workflow-user behaviour.
But don't ship a flow with no fault path. Silenced emails plus no fault handling means failures go invisible.
When the fault path can't reach the running user
For flows that run as System or in scheduled batches, there is no live user to message. Pattern:
- Custom object:
Flow_Error_Log__cwith fieldsFlow_Name__c,Element__c,Message__c,Record_Id__c. - The fault path inserts a row.
- A daily-schedule flow / dashboard surfaces them to admins.
This turns silent failures into something you can dashboard.
