How Do You Fix Salesforce Flow Errors?

A user clicks Save or Next, the screen says “An unhandled fault has occurred in this flow,” and the work is gone. To fix a Salesforce flow error, find the element that failed (the flow error email, Setup > Paused and Failed Flow Interviews, or the Debug button in Flow Builder), match its error text to a cause, fix that cause, then add a fault path so the next failure shows a readable message.

This page sets out where the real error lives, what each common message means, how to add a fault path, and how to get under the governor limits. Salesforce’s developer documentation blocked automated access on October 21, 2026, so every Salesforce statement below comes from Salesforce’s own Trailhead lessons, and the settings paths and error-code lists come from the vendor documentation named next to each claim.

What does “an unhandled fault has occurred in this flow” mean?

It means some element in the flow failed and the flow had no fault path to catch it. Salesforce’s Trailhead quotes the full message as “An unhandled fault has occurred while processing the flow. Please contact your system administrator for more information.” It says the message “doesn’t say what didn’t work,” shows it to the running user, and stops the flow so the user must start over. In a record-triggered flow, the same fault blocks the save that triggered it.

Trailhead’s fault path lesson lists the common causes:

• The flow creates a record with a field the running user cannot access.
• The flow edits a record the running user cannot access.
• The flow creates a record without setting a required field.
• The flow edits a record using an ID with the wrong number of characters.
• The flow sends an email to an invalid email address.
• The flow does something a validation rule blocks.

Governor limits get their own section below, and null values show up in the “0 recipients” row of the table further down.

Who receives the flow error email, and how do you change it?

The email goes to the user who last modified the flow, unless your org is set to send it to the Apex exception email recipients. Salesforce sends it in the default language of the user who ran the flow. Trailhead’s troubleshooting lesson says it includes the error message and details about each flow element the interview executed, and its example email has a “Flow error: click here to debug in Flow Builder” link that shows the path the flow followed.

To send it to a team inbox instead, following Gearset’s setup guide:

1. In Setup, type Apex Exception Email in Quick Find and open it.
2. Add Salesforce users, or put outside addresses in External Email Addresses, separated by semicolons. The same list receives Apex exception alerts, so add everyone who should get both.
3. In Quick Find, open Process Automation Settings (under Process Automation).
4. In the Send Process or Flow Error Email drop-down, change User Who Last Modified the Process or Flow to Apex Exception Email Recipients.
5. Click Save.

Gearset’s steps are written for a production org. It advises against monitoring sandboxes, because a refresh creates a new org ID.

How do you find which element failed?

Start with the email, because it already names the failing element. If nobody got one, or you need to see it live, use these in order.

1. Paused and Failed Flow Interviews. In Setup, type its name in Quick Find. The default view lists paused interviews only, so it can look empty. Switch the list view to All Failed Flow Interviews. Opening an interview shows the flow diagram with the failing element highlighted, according to MoveData’s troubleshooting guide. Interviews paused for a user who was later deactivated can error when resumed, so Salesforce Ben advises freezing users and finishing their interviews before deactivating them.
2. The Debug button. In Setup > Flows, open the flow and click Debug. Fill in the input values and read the Debug Details on the right. Debug writes real data in your org, and Trailhead recommends debugging in a sandbox.
3. Debug as the user who hit the error. A flow that works for you can fail for them, usually on field or object access. In Setup > Process Automation Settings, tick Let admins debug flows as other users and save. Then open the flow, click Debug, tick Run automation as another user, choose the user and click Run. Tick Run automation in rollback mode to keep the run from changing data.
4. Debug Logs. In Setup, search Debug Logs and add a trace flag for the user, then reproduce the error. MoveData’s guides suggest searching the log for FLOW_CREATE_INTERVIEW (each flow that ran), CODE_UNIT (each Apex trigger or class), LIMIT_USAGE_FOR_NS (query counts by namespace) and CUMULATIVE_LIMIT_USAGE (totals at the end of the transaction). This is the step for limit errors, where the flow itself looks fine.

What do the common Salesforce flow errors mean?

Most messages point at one of a handful of causes. This table pairs each message with what it means and the fix.

Symptom or error text	Cause	Fix
“An unhandled fault has occurred in this flow”	Any element failed and has no fault path	Find the element (email, Failed Interviews, Debug), fix its cause, add a fault path
REQUIRED_FIELD_MISSING	A Create or Update Records element leaves a required field blank. Trailhead’s example is an Opportunity with no Close Date.	Set the field in the element, and make it required on the screen that collects it
FIELD_CUSTOM_VALIDATION_EXCEPTION	A validation rule rejected what the flow tried to save	Compare the data the flow writes with the rule’s criteria, then change the flow or add an entry condition that skips those records
INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: insufficient access rights on object id	The running user cannot edit a related record. In Trailhead’s example, a Private sharing setting kept the user from editing tasks owned by someone else.	Give the user the access through a permission set, or change the flow’s run context to System Context Without Sharing only if its users need it
Too many SOQL queries: 101	The transaction ran past 100 queries. Usually a Get Records inside a loop, or several automations on one object	Move Get Records before the loop, add entry conditions, merge flows on the same object
Apex CPU time limit exceeded	The transaction used more than 10 seconds of CPU, shared across flows, triggers, Process Builder and packages	Trim automation on the object, add entry conditions, use a Wait element to start a new transaction
Failure at a Create, Update or Delete Records element inside a loop	More than 150 DML statements in one transaction	Collect records in a collection variable and write them once, after the loop
UNABLE_TO_LOCK_ROW with “Unable to obtain exclusive access to this record”	Another transaction held the record, often a parent record, and Salesforce waits 10 seconds before giving up	Sort collections by parent ID, retry in an asynchronous path, look for roll-ups and many children on one parent
“0 recipients” on a Send Email or Email Alert action	The email field was blank, for example an account owner lookup on a contact with no account	Add a condition so the email runs only when the field has a value

Source: Salesforce Trailhead (Flow Implementation I and II, Flow Troubleshooting), Gearset flow error documentation, MoveData troubleshooting guides and Xappex’s UNABLE_TO_LOCK_ROW guide, checked Oct 21, 2026. The error codes are quoted as those pages print them.

Gearset’s flow error monitoring article lists more codes that turn up in error emails, among them INSUFFICIENT_ACCESS_OR_READONLY, INVALID_FIELD, CANNOT_EXECUTE_FLOW_TRIGGER and Maximum trigger depth exceeded. The pattern for all of them is the same: read the element name in the email, open that element, and check what it was trying to write.

How do you add a fault path in Flow Builder?

A fault path is a second line out of an element that runs only when the element fails. Trailhead says you can add one to Get Records, Create Records, Update Records, Delete Records and Action elements. Here is how the lesson builds one for a screen flow:

1. Open the flow in Flow Builder (Setup > Flows, then the flow name).
2. Hover over the element that can fail, such as Create Records, and click the plus icon.
3. Select Add Fault Path.
4. On the fault path, click the plus icon and add an element. In a screen flow, a Screen with a Display Text component works.
5. In the Display Text, insert the FaultMessage global variable, written {!$Flow.FaultMessage}, and add the values the user entered, so you can see what was submitted.
6. Save the flow, then use Debug with bad input to confirm the fault path runs.

For flows with no screen, put something an admin will see on the fault path instead, such as a record that logs the error or an email. Salesforce Ben’s error guide suggests creating a Case so failures get followed up. If many screen flows need the same fault path, Trailhead suggests building it once as an autolaunched flow and calling it as a subflow.

A fault path also changes what happens to your data, and this catches people out. Per Trailhead’s rollback lesson, without a fault path a failure rolls back every database change in the transaction. With one, the transaction is not rolled back. In a record-triggered flow, the change that fired the flow is saved even though the flow failed. Two elements force a rollback on the fault path:

• Screen flows: Roll Back Records. Place it before the error screen, because a user who closes the screen or clicks Back stops the flow before later elements run.
• Record-triggered flows: Custom Error, which shows your message to the user and rolls the transaction back.

For other flow types there is no element that rolls back on a fault path, so decide per element whether a fault path is safe.

How do you fix “Too many SOQL queries: 101” and other limit errors?

Take the Get Records, Create, Update and Delete Records elements out of loops. Trailhead’s avoid flow limits lesson says each of these inside a loop runs once per record, so a loop over more than a few records can quickly reach 100 queries or 150 DML statements. The pattern:

1. Put Get Records before the loop, so it runs one query.
2. Inside the loop, use an Assignment element to change the current item and add it to a record collection variable (data type Record, allow multiple values).
3. After the loop, use one Create Records, Update Records or Delete Records element on the collection. In Trailhead’s example this turns one DML statement per product into a single statement.
4. Add filters to Get Records, to Update Records and to the Start element of a record-triggered flow, so the flow touches only the records it needs. Trailhead’s example of a daily flow that updated every contact fails once the org has more than 10,000 contacts.

These are the per-transaction limits Trailhead lists for flows:

Limit	Synchronous transaction	What uses it in a flow
SOQL queries	100	Each Get Records element, and the filter of each Update Records and Delete Records element
Records retrieved by SOQL	50,000	Rows returned by those queries
DML statements	150	Each Create, Update and Delete Records element
Records changed by DML	10,000	Records created, updated or deleted
CPU time	10 seconds	Everything in the transaction

Source: Salesforce Trailhead, “Avoid Flow Limits” (Flow Implementation I), checked Oct 21, 2026. MoveData’s documentation, checked the same day, gives the asynchronous limits as 200 SOQL queries and 60,000 ms (60 seconds) of CPU time.

Two points explain most limit errors that survive the loop fix. A limit counts the whole transaction, so a flow that runs from an Apex class, a trigger or another flow adds to what that automation already used. Trailhead’s example is an Apex class using 9 seconds of CPU calling a flow that needs 2, which fails both. And a Screen or Wait element ends the transaction and starts a new one, so a Wait element is the last resort when a flow genuinely needs more room.

If a record-triggered flow is only one of several automations on an object, MoveData’s advice applies: add entry conditions so each flow runs only when the relevant fields change, merge flows on the same object and event, use before-save fast field updates where possible, and migrate old Process Builder and workflow rules to flows. Its guidance for records that hit UNABLE_TO_LOCK_ROW comes from Xappex’s UNABLE_TO_LOCK_ROW guide: sort collections by parent ID, and add a fault path that waits and retries up to 3 times. The retry works in autolaunched flows and in the asynchronous path of a record-triggered flow, not in a synchronous record-triggered flow, and only lock errors are worth retrying.

How do you confirm the flow error is fixed?

Run the exact case that failed, as the user who hit it, and check three places.

1. In Flow Builder, Debug the flow with Run automation as another user and the same inputs. The Debug Details should show every element completing with no failure. Use rollback mode, or a sandbox, so the test does not write data.
2. For a limit error, repeat the action in production or a full sandbox with a trace flag on and read CUMULATIVE_LIMIT_USAGE in the debug log. The SOQL, DML and CPU counts should sit well under the limits above, with room for other automation on the same object.
3. Watch Paused and Failed Flow Interviews and the error email inbox for a few days. New failed interviews or a new email for the same flow mean the fix covered one case and missed another.

If you added a fault path, also trigger it on purpose once with bad input, so you know the message and any rollback work.

When should you call a Salesforce expert?

A single missing field or a permission set is an admin fix. Bring someone in when the error crosses automations: several record-triggered flows plus Apex triggers and managed packages on one object, UNABLE_TO_LOCK_ROW on records with thousands of children, or a flow called from Apex where both fail together. MoveData’s own guides say the same for limit errors, since the failing automation is usually outside the tool reporting it, and recommend involving a Salesforce partner.

It also pays to bring someone in before a migration or integration load, because that is when governor-limit and bulkification problems surface. Our Salesforce implementation service covers Flow, Apex and integration work, built bulk-safe from the start. If you are loading data when the errors appear, see how to install Salesforce Data Loader and how to find and prevent duplicate leads in Salesforce, and the Salesforce migration guide covers staging loads through a sandbox. Our implementation cost benchmark shows where flow and Apex work sits in a Salesforce budget, and our CRM API rate limits comparison shows how Salesforce’s limits compare with other CRMs, and the CRM integrations guide covers connecting the systems that write into Salesforce.

If you are still deciding whether Salesforce is the right system, the HubSpot vs Salesforce comparison and the Salesforce pricing calculator show what each option costs and where each one gets harder to run. To send us the error email and the flow, use the contact page.

Founder’s note, Alpit Patel. A flow that fails quietly is worse than one that fails loudly. I’d add a fault path to every flow that writes data, and send the error to a person who will read it. I founded aibrevo in San Francisco in 2021, and through autoesta I have overseen 320+ GoHighLevel implementation projects across med spas, real estate, healthcare, dental, home services, SaaS and professional-services clients in the US, UK and UAE. About Alpit

Sources

• Salesforce Trailhead, Handle Flow Errors with Fault Paths, checked Oct 21, 2026.
• Salesforce Trailhead, Roll Back Changes After an Error, checked Oct 21, 2026.
• Salesforce Trailhead, Debug Flows as Another User, checked Oct 21, 2026.
• Salesforce Trailhead, Avoid Flow Limits, checked Oct 21, 2026.
• Salesforce Trailhead, Fix Access Issues in a Flow and Fix Issues Caused by a Null Value in a Flow, checked Oct 21, 2026.
• Gearset, Manually configuring error monitoring for your Salesforce org and Flow error monitoring, checked Oct 21, 2026.
• MoveData, Too many SOQL queries: 101, Apex CPU time limit exceeded and Understanding unhandled flow faults, checked Oct 21, 2026.
• Xappex, Unable to Lock Row in Salesforce, checked Oct 21, 2026.
• Salesforce Ben, How to solve Salesforce flow errors, checked Oct 21, 2026.