How to find and fix a Salesforce Flow error

A failing Flow usually blocks a simple action: creating an opportunity, saving an account, closing a case. The user sees an unclear message, and the admin receives an email full of technical detail. The good news: in the vast majority of cases, you find the cause by following the same method every time.

Where Flow errors show up

A Flow error shows up in two places.

• On the user's screen. For a record-triggered Flow, the save fails and a message appears. For a screen Flow, the text "An unhandled fault has occurred in this flow" replaces the screen.
• In the admin's inbox. Salesforce sends an error email with the Flow name, the version, the failed element and the variable values at the time of the error. It is the most useful document for the diagnosis.

The 5-step diagnosis method

1. Read the error email to the end

The start of the email is often generic. The useful part is further down: the list of executed elements and, above all, the last one, the element that failed, with the exact error message. Note three things: the failed element, the message and the record concerned.

2. Identify the type of error

The error message almost always tells you which family the problem belongs to:

3. Reproduce the problem in a sandbox

Open the Flow in Flow Builder and use the Debug button with the same record, or an equivalent one. Debug shows the path taken, element by element, and the value of each variable. For a record-triggered Flow, choose whether the record is created or updated, as in the real case.

If the Flow works in debug but fails for the user, the problem often comes from the running context: the user's permissions, the record type, or a field value you did not reproduce.

4. Look at what runs around the Flow

A Flow never runs alone. On the same object there may be other Flows, validation rules, old workflow rules and Apex code. Flow Trigger Explorer shows every Flow triggered on an object and their order. Two Flows that update the same field in a different order produce surprising results.

5. Fix the cause, not the symptom

Working around the error (deactivating the validation rule, giving everyone more permissions) makes it disappear, but often creates another problem. Ask why the rule exists, or why the user lacks access, before changing anything.

The most common errors and how to fix them

A validation rule blocks the Flow

This is the most common case. A recently added rule rejects a change the Flow used to make without trouble. Two options: adapt the rule so it accounts for the case (with the business), or have the Flow fill in the expected field. Example: a rule requires an Industry on the account, and the Flow creates accounts without one. Either the Flow sets the industry, or the rule excludes accounts created automatically.

An empty variable

A Get Records element finds nothing, then a later element uses the result as if it existed. Add a Decision right after the lookup: "the result is not null". The empty path must do something planned: nothing, a notification or a clear message.

Queries or writes inside a loop

Putting a Get Records or Update Records element inside a loop breaks the limits as soon as the Flow processes many records, for example during an import. The fix: collect the records in a collection variable during the loop, then write once after it.

The wrong kind of record-triggered Flow

To update a field on the same record, a before-save Flow (fast field updates) is faster and avoids extra writes. To create related records or send emails, you need an after-save Flow. Mixing the two creates loops and errors.

Full example: an opportunity that no longer saves

Fictitious situation: since Monday, the sales team can no longer create opportunities on some accounts. The admin receives an error email at every attempt.

1. Reading the email. The failed element is "Account update" and the message is FIELD_CUSTOM_VALIDATION_EXCEPTION: a validation rule rejects the change. The Flow itself has not changed for months.
2. Finding the cause. In Object Manager, on the Account object, a validation rule created on Friday requires the Industry field as soon as an account's type becomes Customer. The Flow sets the account to Customer when its first opportunity is created, without filling in the industry.
3. Reproduction. In a sandbox, debugging the Flow with an account that has no industry fails at exactly the same element. The cause is confirmed.
4. Fix, decided with the business. The rule has a purpose: industry feeds management reports, so it stays. The Flow no longer changes the type of an account without an industry: it creates a "Complete the industry" task for the account owner. A fault path on the update element alerts the admin instead of blocking the sales rep.
5. Checks. Three tests before activation: an account with an industry, an account without one and an import of 50 opportunities. Then the new version is activated and error emails are watched over the following days.

Best practice to prevent future errors

• A fault path on every write. In Flow Builder, every element that writes data can have a Fault path. Use it to log the problem and alert the admin, without blocking the user when that is acceptable.
• Precise entry criteria. A record-triggered Flow should only run when needed, for example "when the stage changes".
• One Flow per object and per timing, where possible. Fewer Flows mean fewer ordering conflicts.
• Descriptions. Every Flow, version and important element should say what it does and why.
• No direct changes in production. Test in a sandbox, then deploy.

Test before you activate

Before activating a new version, test at least:

1. the case that was failing;
2. the normal case, which already worked;
3. an edge case: empty field, a user with few permissions, several records at once (import).

For record-triggered Flows, Flow Builder lets you save reusable Flow tests. They save you from repeating the same checks after every change.

When to call in an expert

You can fix a validation rule or an empty variable yourself. Call in an expert when:

• several automations on the same object contradict each other;
• the error involves platform limits or a bulk import;
• Apex code is part of the chain;
• you have no sandbox, or no time to test safely.

In these cases, an hour of diagnosis often saves several days of trial and error in production. If errors keep coming back every month, Salesforce maintenance includes a review of your automations. See also our Salesforce automation service: diagnosis, fix and testing, with a quote before any work, or check our pricing.

Official references

Salesforce documentation to go further:

• Troubleshooting Flow Run Time Errors (Salesforce Help) (new tab)
• Select Flow and Process Error Email Recipients (Salesforce Help) (new tab)
• Default Flow Error Handling (Salesforce Help) (new tab)
• Handle Flow Errors Effectively (Trailhead) (new tab)

Frequently asked questions