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.
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
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:
Which would give us a this error screen instead of the “Unhandled Fault” screen.
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:
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..
Here we’re creating the case using the variables containing information from the main flow.
I’m using a couple of Text Templates to format the Subject and Description of the case.
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.
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”.
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.
Now if the flow faults on this step we’ll get a case that looks like this:
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.
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.
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.