Fault Paths in Salesforce Flow

I’m always pulling up people who post images of their flows on LinkedIn and asking where are their fault paths. So much so that I’ve even been dubbed the “Fault-Path bot”.

What are fault paths in Salesforce Flow and why do we need them?

We will only discuss Screen Flows in this article because record-triggered flows have some additional complexity.

Why do we need Fault Paths?

If your flow encounters an error then your end users are presented with an error that looks like this:

Salesforce describes this error message as:

What you are looking at is what we call a GACK. A gack is our blue screen of death, our frowny Mac icon, our “the number you have reached is no longer in service”, our “Jedediah has died of dysentery”. A gack is what happens when an error got thrown within our application and we didn’t catch it and handle it.

That’s not very helpful for the end user and at that point, the flow just ends. Nasty!

Let’s create a simple screen flow to demonstrate how to use a Fault Path.

First, we get accounts that have an industry of Agriculture.

There are three possible results when we run this flow:

1. Some records are returned
2. No records are returned
3. An error occurs

Some records are returned

What do we do next? Perhaps we display them in a table so the user can select one or more records?

No records are returned

Should there be some records returned? This is not an error, it does not generate a GACK message. What do we want the Flow to do if this occurs? Perhaps just quit? Or display a message indicating no records found?

An Error Occurs

An error can occur for many reasons but a simple one could be the user who is running the flow does not have access to the Account object. We need to present them with a more helpful message than the GACK shown above.

Select the Get Record Element and you have the option here to Add Fault Path.

A new branch is added for the Fault Path:

Click the “+” icon to add a new element here and select the Screen element:

Give the Screen a Label and API Name:

Drag a Display Text element to the canvas, give it an API Name, and add the text of the message plus the $Flow.FaultMessage. This is a global variable containing a detailed description of the message. Although it can be quite a technical message, sometimes the user can understand the problem and fix it themselves.

Next, add a Decision element and we can handle results 1 & 2 (some records are returned or no records are returned):

The configuration of the Decision element is as follows. We test if the Accounts returned from the Get Accounts element earlier Is Empty. If this record collection is empty then we know that there are no accounts with the Industry value “Agriculture” in our organization. This decision now handles our first and second possible results when we run the flow.

If records are found, the YES branch has a Screen element to display them in a data table.

For the NO path, we can add a Screen element with a friendly message:

Final flow:

When we run this flow as a user who does not have access to the Account object, the more user-friendly message we configured earlier will be displayed (shown with the fault message highlighted below):

The system Admin receives the standard fault error email as follows:

I cover fault paths in more detail in my Intermediate Flow course at CertifyCRM.com, including using fault paths with record-triggered flows. We also learn how to create the fault path actions as subflows which we can call from any flow.