Handling the “Unhandled Fault” in Flow

When you start doing a little work in Visual Workflow aka “Flow”, you are going to run into the dreaded “Unhandled Fault” sooner or later.

(na17) Contact Form Sample000280

This unhelpful message means your flow caused an error somewhere, usually due to a data manipulation like a record create or record update. The reason it’s “Unhandled” is because you, the Flow Developer*, didn’t “trap” or “handle” the error.  Maybe you tried putting 40 characters into a 30 character field? Maybe the user doesn’t have permissions to update a field.? It sure would be nice to know what’s going on and where the error is occurring, wouldn’t it?

Let’s start by handling the error using the Fault Connector. While a normal connector (arrow) connects one element to another, a second arrow, the Fault Connector can be drawn from an element to a different element in case of an error or fault.  Below is an example of a Fault connector directing errors caused by the record create to a user screen.

You can use a fault connector on these elements:

  • Apex Plug-in
  • Record Create
  • Record Update
  • Record Lookup
  • Record Delete
  • Fast Create
  • Fast Update
  • Fast Lookup
  • Fast Delete

See this article for more information: Fault Connector Overview

Flow Designer_ Contact Form Sample000281

So for a really simple error handler we could just use a User Screen and put the system variable $Flow.FaultMessage on the screen to see what’s happening like this:

Flow Designer_ Contact Form Sample000285

Which would give us a this error screen instead of the “Unhandled Fault” screen.

(na17) Contact Form Sample000279

This is way better than the generic error as we now have some troubleshooting information. This is fine for debugging while the flow is in development but what are we going to do when we put the Flow into production? We need a way to track these errors, where they happened, and who caused them. Let’s use Cases and a Subflow!

Salesforce Cases are custom built for tracking information. Let’s use them to track our Flow errors. What kind of information do we need? At minimum we need the error and the name of the flow where the error occurred. What about something to describe what we’re doing when the error occurs? Maybe it’d be helpful to know exactly where in the flow the error occurred?

Here’s my Error Handling flow:

Flow Designer_ FlowError000289

Not much to look at, but sometimes good things come in small packages. The flow has variables defined for FlowName, FaultLocation, FaultError ($Flow.FaultMessage ), FaultDetails (for any details you want to add), and FaultObjectID (for passing in the Objectid you were updating/looking up or the primary object of the flow). All of these variables are set to “Input” so we can pass information to them from the main flow and write to a case.

In this example I created a separate record type on cases just for flow called ‘Flow’. It’s a good practice to avoid hard-coding record Id’s in your flows so I do a quick lookup on RecordType  to get the case record type id..

Flow Designer_ FlowError000295

Here we’re creating the case using the variables containing information from the main flow.

Flow Designer_ FlowError000296

I’m using a couple of Text Templates to format the Subject and Description of the case.

Flow Designer_ FlowError000297

Flow Designer_ FlowError000298

After the case is created I lookup the id from the record create to get the case number and then I display an error message to the user.

Flow Designer_ FlowError000299

That’s it for the error subflow. Now we get to start using it in our flows. In our original example Flow I’ve removed the error screen and replaced it with our subflow “FlowError”.

Flow Designer_ Contact Form Sample000287

Here we are passing in the information from our flow into the subflow. Note that I called this screen “Fault1” and the varFaultLocation is being set to “Fault1”. If you get a fault you can easily search the flow for “Fault1” – no more messing around wondering where in the flow the error occurred.

Flow Designer_ Contact Form Sample000286

Now if the flow faults on this step we’ll get a case that looks like this:

(na17) Case_ 00001037 ~ salesforce.com - Developer Edition000301

We know who the Flow running user was because they are the case creator. We have the Flow that caused the error, the system error message and the location of the error in the Flow. Having the location of the error is key – when your flows get bigger and have 10+ record updates, tracking them down can be time consuming. Here’s part of a flow that has a lot of record manipulation. For each element that I can get an error I’ve got a Fault connector calling the Error subflow.  Since each one is labeled Faultxxx and I’m putting that Fault label in the case, finding where in the flow the error happened is simple.

Flow Designer_ SMB SOF FAST Line000288

Our end user’s get a friendly error message to let them know something has gone wrong and that their Super System Admin is on the job and will track it down.

(na17) Contact Form Sample000284

My fellow Flow Developers* (yes, if you create flows you are a developer, you’re just using declarative tools) there’s lots of ways to expand on this to fit your own situation. Add a custom field to case for the Flow Name – that way you could report on which Flows have the most errors per month or look for trends. Maybe create a text template with all your flow variables and send that to the subflow using the FaultDetails? What about creating another error handling flow without the user screen so you can use with “AutoLaunched Flows” (I haven’t tried this yet but will shortly)?  Lot’s of possibilities. I’d love to hear your ideas so leave me a comment.

This entry was posted in Flow. Bookmark the permalink.

11 Responses to Handling the “Unhandled Fault” in Flow

  1. Chris says:

    Fantastc stuff. Thanks for all this.
    And yes, although I am not a developer, I agree people who manage FLOWS are developers!)


  2. Thank-you! This is exactly what I’ve been trying to sort out for my Flows. This will save me a lot of head-scratching.


  3. debforce says:

    Fantastic stuff! I have a flow on OpportunityProduct which hits errors on save because a validation rule on the Opportunity fails. It’s a terrible user experience. But I’m thinking if I can catch the errors with this and display the validation error to the user or — better yet — prompt them for the info needed to save correctly…. Awesome!


  4. Here’s one thing I changed about this blog post about error handling. In the post there are different subflows for each error. Instead of that I’d suggest replacing those with Assignment elements and having only ONE Error handling Flow. Why? It’s easier to adjust the Assignments than a Flow AND, very importantly, if you at some point create a new error handling Flow and need to replace this, you only need to replace ONE per Flow vs multiple.


  5. Justin says:

    What if it’s an autolaunched flow (aka workflow -> flow trigger -> flow)?? You aren’t able to use the screen element. I have an autolaunched flow that creates a lead when a user makes a change on a case. Unfortunately, validation rules that cause the flow to fail don’t show the their error messaging. The message is simply “A flow trigger failed to execute the flow with version…” Ideally I’d be able to show the validation rule error or even a custom error message created in the flow.


    • sfdcdude says:

      Create a second error handler for autolaunched flows. It’s exactly the same except you remove the user screen and save it as an autolaunched flow.


      • Judy says:

        I have an autolaunched flow that I need to customize the error message. How can I display the error message without a screen element, is it possible? Thanks!


      • Judy says:

        I have an autolaunched flow that I need to output a customized error message. I think I am trying to do what Justin is asking but I’m not sure what to do exactly. Can you please clarify? How can I display a different message to the user without a screen element? Thanks!


      • sfdcdude says:

        For an autolaunched flow, you can’t display an error message to the user because screen elements are not allowed. You can still trap the errors but you can’t display to the user. You can either a) write the errors to a log (I used cases as an example) or b) use send email element to send yourself the error.


Leave a Reply to sfdcdude Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s