Road Closed Signs, LA

 

The Flow Builder is a powerful tool for Admins; it allows us to build user journeys that look great and execute complex business logic at Lightning speed.

When you use flows in your org, the chances are there’s going to be bumps along the road and your flows are not always going to do what they were designed to do.

There are 100s of different ways you can make your flow throw an error, so you can get creative! From trying to create records without required fields, to breaking flow limits.

In this blog, we won’t cover how to avoid the errors in the first place. We are going to look at how we can handle those Flow errors in the best way possible.

 

Dear User – Computer Says No

Most users of flow will be familiar with this picture:

An Unhandled Fault Error Message

 

It isn’t a very pretty error message and it still makes my blood run cold. I used to imagine what the end-user must think when they see this message:

Have I broken something? Is Salesforce broken? Did any actions take place?

At best it’s inconvenient and at worst it makes you as an Admin look unprofessional and erodes confidence in the system.

 

The Fault Connector

If I expected most readers to have seen the ‘Unhandled Fault’ message, I wonder how many of you have seen ‘Fault Connectors’ which Salesforce provides to handle Flow errors?

Fault Connector

I work on many Salesforce Orgs and I rarely see these used. They are recommended as best practice and using them can make flows failing a lot less stressful.

You can use the fault connector from any of the ‘data’ elements (the pink ones), or the Action elements in the Flow toolbox.

To create a fault connector, simply create a second connection from your element after creating your first connection.

Creating a Fault Connector gif

 

 

Next Stop on the Fault Line

We now know how to create a fault connection, but what do we attach it to? Below is a simple screen flow which lets users create a Contact and Account at the same time. We will use this to demonstrate some of the best elements to use after things have gone wrong.

Full View of the Demo Flow

 

 

Where did the flow fail?

First things first – use an assignment element to record exactly where the flow went wrong. I usually assign a value to a text variable called ‘Error location’. Spoiler alert… we’ll be using this later.

Assigning a value to the ErrorLocation Variable

 

Nothing to see here

Never see that awful red ‘Unhandled Fault’ message in your screen flows again! Use a Screen element and Display Text to communicate with the user. You can even add images and merge fields such as {!$Flow.FaultMessage}. With this fault message, the user might even be able to see what is wrong themselves.

Note: This can only be done in screen flows. Flows which are auto-launched from a Process Builder, for example, will show an error message on the screen where you are triggering the flow.

Custom Error Message Screen Component

 

Better email notifications for Admins (and Users)

The standard error email received when a flow breaks can be quite difficult to decipher. So why don’t we make our own?

We can curate a personalised email alert to Admins of the org to let them know that the Flow has gone wrong, and we can even use the {!ErrorLocation} variable from before to tell them exactly where it’s fallen over.

I create a ‘Text Template’ resource and use that for the body of a ‘Send Email’ core action. You could even send an email to the running user to put their mind at rest too.

Text Template with Merge Fields for Email

 

Create a case

If your IT team uses Salesforce Cases to manage requests, then why not cut out the intermediaries and create it straight away with a Create Record element? You can use the merge fields we have seen along the way to populate the Subject, Description and other fields.

 

Time to Relax

Using fault connectors to handle errors in your flows will improve your users’ experience and help deliver the information that Admins need to understand problems with Flows quickly. That new screen flow error message looks so nice… I secretly hope I see it again soon!

 

Further Reading

Now you know how to handle Flow errors,  it might be worth bundling up the actions in a subflow so you can call them again and again. This free AppExchange product from Salesforce Labs gives you a big head start on doing this by giving you a subflow with some email actions which you can call with your fault connector.

For the full detail on Flow errors, see the Salesforce Documentation

Angus Brown June 1, 2020

3 thoughts on “Riding the Fault Line – How to Handle Flow Errors in Salesforce

  • Angus Hi,
    Thank you for the great article!
    When a standard exception email is sent, it also includes a full exception message (like the one we see in the debug log) that tells you how the flow started, who Initiated the flow, what records where involved, etc. According to Salesforce, this message cannot be captured since it’s not stored anywhere in Salesforce objects.
    For that reason, I also add the time/date stamp (NOW()) to the Screen Element error exception message displayed to the users. This will allow me to easily find the exception email that was sent to me, and then to better understand the cause of the failure.

    Thanks again,
    – Gidi

  • Hi Angus,

    This was very helpful and I was able to create an error email to send to my users. However, what I noticed is the following, which in my case isn’t desirable.
    Normally, when my flow (auto-triggered, not a screen flow) would error, the user would get that ugly error on their screen and all the changes they were trying to make are reverted.
    However, when I do have a fault line in my flow, the user gets no error message on the screen (it’s an auto-triggered flow), but not all of the changes are reverted. So, basically, half of the flow completed, the other half didn’t.
    Is there any way to ensure that all of the changes are reverted when adding fault lines?

Leave a Reply

Your email address will not be published. Required fields are marked *