Alert the Right People With Custom Error Handling for Screen Flows in Winter ’20

Screen flows are a great way to guide users through a complex business workflow and save them time. But sometimes, in spite of our best efforts, something goes wrong with the flow. Maybe a record got deleted between when the flow was started and when it finished, or perhaps a form field should have been required but wasn’t, which caused a record update to fail. Until now, you’ve had two options when these types of errors occur: send an email to the user who last modified the process or flow, or send an email to the recipients configured for Apex exception emails. (These options are configured in the Process Automation Settings in Setup.)

But sometimes, neither of these options is the right one… You might not want to receive emails for Apex exceptions, or you might want to notify a different admin than the one who last modified the flow! As of Winter ‘20, you now have a third option for screen flows: You can build a Process Builder process that runs when a specific flow error occurs, and then post to a Chatter group or send emails or notifications to your entire admin team. However you want to handle errors, you can do it without code!

In Winter ‘20, we’ve added a new standard platform event called Flow Execution Error Event. If an error occurs during the execution of a screen flow, the system will raise this event. If you haven’t looked at platform events before, they’re a bit like Bingo. In Bingo, players listen for specific numbers, and when a number is called that a player cares about, they respond by marking off the number on their card. To compare that to platform events, a platform event is like a number being called, and the players are any processes or code listening for it. When a Flow Execution Error Event is announced, our process will respond and take the actions we’ve configured.

How to create a process for custom error handling for screen flows

In Process Builder, create a new process that starts when a platform event message is received.

In the process canvas, click Add Trigger. For the platform event, choose Flow Execution Error Event. The next part is a little tricky: For platform events, the starting criteria need to match exactly one object record. The Flow Execution Error Event might not even be related to any record, but it still has to match one. For this example, we’re going to use a Chatter group with the name “Awesome Admins”. (The matching record will be used later as the link if you use the process to send a custom notification, so it should be something that whoever you send notifications to can access.)

For the criteria, you can choose to always execute the actions, but you can also set more specific criteria. You can even use information from the Flow Execution Error Event to choose how to handle it; for example, you can have different handling for a certain Flow API Name, a specific Flow Error Id, the Username of the person who ran the flow, or some other criteria.

Let’s say you have a flow called Employee Onboarding that your hiring managers use to set up new employees with equipment and training and so on. When this flow has an error, you want to notify a specific group of admins and also the business manager for the HR group who is your main contact for that particular flow. Choose the Conditions are Met criteria option, and set the following:

• Source: Platform event
• Field: Flow API Name
• Value: Employee_Onboarding (the API name of the example flow)

Your process is now set up to listen for Flow Execution Error Events for the Employee Onboarding flow. Let’s talk about actions.

The same actions are available for processes triggered from a platform event as for any other process. You can send emails or notifications, post to Chatter, and even create a record if you’re tracking issues through cases or a custom object. For this example, you wanted to notify multiple admins and also a business user. You could add a separate action for each person, but that’s a lot of extra work. So instead, let’s send a notification to a public group that will send a notification to everyone in the group, and if you need to add or remove people from the group over time, you won’t have to change your process.

To do this, you’ll need two things:

• A public group containing all the users (and/or roles) you want to notify. You can configure this in Setup under Public Groups. For our example, the group is called “Onboarding Team”.
• A custom notification type, which defines the channels to send the notifications (Desktop and/or Mobile). You can configure this in Setup under Custom Notifications. For our example, the custom notification type is called “All Channels” and includes both the Desktop and Mobile channels, so people will be notified on their phone even when they’re not in Salesforce.

Once you’ve created your group and custom notification type, go back into your process. In the immediate actions for the Is Employee Onboarding criteria, click Add Action.

• Action Type: Send Custom Notification
• Action Name: Notify Onboarding Team
• Notification Type: Your custom notification type (in the example, All Channels)
• Notification Recipient: Group, and then the API name of the group (in the example, Onboarding_Team)

The Notification Title and Notification Body can include merge field values directly from the Flow Execution Error Event. For the title, let’s start by indicating which flow had the error, and then indicate who was running it and the time that the error occurred; for example, “FLOW ERROR: Employee Onboarding at time”.

To use a merge field from the platform event, open the Merge Field picker and choose the option to use a field from the FlowExecutionErrorEvent platform event message, then choose the appropriate field from the list. For the title, I included Event Date. For the body, I just included the Flow Error Message in this example.

Custom notifications also include a Target Object, which, for processes triggered by platform events, is always going to be the object record that meets the trigger matching criteria (remember, it has to match just one record).

Save the action, add any additional actions you want to execute (like posting to Chatter), and, when you’re ready, activate the flow. Now, when an error occurs in the Employee Onboarding flow, everyone in the Onboarding Team public group will get a message that looks something like this:

Now you’re ready to add your own custom error handling to screen flows in your org!