Who doesn’t know this problem: Your process requires an approval, an inbound email, a reply from the caller or even from a remote system and the update just won’t come. Over time, your instance may accumulate in-flight flow contexts, open tasks, and approvals left and right. This article will help you build the right error handling and time-out process for your use case.
Our Flow Designer product team is hearing your ask for better options to handle errors and we’re working to deliver thus in a future release, but here’s what you can do in the meantime.
-----
Edit start
Rome Update
With General Availability (GA) of the Rome release around the corner, Flow Error Handler will finally be available to everybody. Once you've updated your instance to Rome, you'll see new sections in the Action Designer and Flow Designer. This allows you access to improved action outputs (create your own action error handling logic), capture and push flow error information and automate the resolution of flow errors.
Check out the Live Coding Happy Hour (LCHH) episode on Flow Designer Error Handling with Brian Bimschleger to find out how to get started.
Edit end
-----
Error handling
When you expect or discover that a part of your flow times out, integration endpoints may not be available, or for other reasons you get an error, we recommend you put that section into a (reusable) subflow and continue your flow based on the subflow state.
In my example I have created a very minimalistic subflow (“Wait for me”) that waits for 1 hour (determined by my subflow input) and then logs a message.
Your subflow could be:
- Calling an external API and getting an error or no answer from the remote system
- Waiting for an inbound email that never comes
- Waiting for an update of a record to be done by an agent or caller
Step-by-step instructions:
- Add the subflow in your main flow (or parent subflow).
- Uncheck the box “Wait for Completion” for the subflow.
The checkbox “Wait for Completion” is a new feature. Previously the parent flow would by default wait for the subflow to finish (State = Complete, Error, or Cancelled) before continuing with the logic. Now we can let the subflow do its thing in the background and determine how long the parent flow should wait for a result. - Next, add a flow action “Wait For Condition” for the table Flow engine context [sys_flow_context] with these settings:
- State | is one of | Complete, Error, Cancelled
- Enable timeout | checked
- Duration | whatever your determined wait time is, a week or a couple of days
(in my example a few minutes, less time than the subflow takes)
- Add flow logic to determine how to proceed based on the subflow state. E.g.
- If State | is | Error
- Log a message/Send notification
- Flow Logic “End” to end flow execution
- Else if State | is not | Complete (all others except for Error and Complete)
- Log a message/Send notification
- Flow Logic “End” to end flow execution
- Proceed with your flow logic (you’ll only reach this point if the subflow was complete).
- If State | is | Error
Complete flow logic:
Optionally, if your use case requires a successful execution, you can wrap this whole part (subflow + if/else logic) in its own subflow and then add it in a “do the following until” in the parent (sub)flow until the execution was successful. However, for outbound calls I’ll recommend using the “Retry policy” within the action to define how often ServiceNow will retry to establish the connection.
Approval reminders
One common reason for open tasks and flows are missing approvals. Ashutosh Munot, who is one of our Developer MVPs this year and recurring Now Community MVP, wrote 2 great articles on how you can solve this in Flow Designer:
- Approval Reminder for Approval Records using flow designer (Video)
- Approval Reminder Notification for Change records using flow designer (Video)
I encourage you to go check them out and leave him a “Helpful” vote if his work made your job easier.
3 Comments
