This blog assumes that you have completed the basic training for RPA at Service Now (RPA Core Skills), also this collection of links is very helpful when working with RPA: Platform: Robotic Process Automation (RPA) || Know... - ServiceNow Community.
Error Handling - Basics
Now that you have built a a robot, how do you handle errors? Let's start by categorizing errors into two buckets:
- Procedural errors
A procedural error is when something doesn't work as expected. Maybe you tried to launch an application, but it didn't start, or a website you're trying to interact with won't load due to a network outage. Basically, things that are more or less out of your control. - Data-driven errors
This type of error would happen when you receive (or send) a specific data element and expect it to be numeric, but for some reason in this execution you got a string.
Both error types require some form of preparation to handle them and have your robot gracefully return control to the ServiceNow instance.
The Demo Setup
So let's see how this works when you don't add any extra error handling. To do this, I created a small robot automation that downloads a file from the ServiceNow instance. Now, this could run into a lot of trouble, right? Permissions in ServiceNow are not set correctly so the download fails, the directory to download to doesn't exist or is out of space,... you get the idea.
This is what this particular robot looks like to start with:
On the instance, all the setup has been done on the RPA Hub. A Bot Process, a Aueue and the Robot - all nicely lined up and ready to go. For testing purposes, I will use the 'Start Process' action on the bot process. This will trigger the Unattended robot to execute the package. The same could be done via Flow to fully automate it.
The happy path....
If all goes well and we do not generate any errors, a 'Start Process' on the the bot process will create a new entry in the Process Jobs related list. This entry will store some information about the execution, such as start and end time as well as a State. In the happy path scenario, this is what the record might look like:
As you can see, this is all good, we get a State of Success and some timestamps. It also tells us which robot machine performed the automation, just in case you had more than one robot available. It also reports that this was triggered by 'Manual' - yes, I clicked on Start Process as mentioned above.
The Unhappy Path...
Now let's start to introduce some problems and see what happens. I have modified the automation to fail to download the attachment by pointing to a non-existent download directory. This is what the process job entry looks like now:
We can see that the State has been set to 'Failed' and we do get the error message from the Unattended Robot saying 'The given path c:\temp does not exist'. This is great in terms of traceability. We have the information in ServiceNow and we can act on it if we need to.
However, when we map an end to end process, it is still not great. The work queue item that we sent to the robot is still in an 'In Progress' state because the bot has not returned proper state. To fix this, we need to look at the automation itself in RPA Desktop Design Studio.
The first option we can - and probably should - use in RPA Desktop Design Studio is a Try-Catch component. Try-Catch is common notion in programming languages everywhere, but it may be a new concept for RPA developers. The idea is that we tell the robot to try a set of actions, and if something fails, the robot should come back to this component and allow us to handle that error condition. And that is exactly what this Try Catch component will do.
The way we use this component is that we add the automation after it on the Control-Out port. In the case of an unhandled error in this branch of our flow, the automation will come back and use the On Error output to continue. In this situation, the Error Message will be populated with the error that occurred. So let's add it to the bot flow from above and see what happens:
Now, after running the automation from the RPA Hub using Start Process - just like before - the Process Job executed and ended up in a 'Success' state. This is great, but our work item is still In Progress because our Error branch doesn't take care of it yet. In fact, you could say that we made things worse because the error that occurred is now somehow gone and nowhere to be found. Running the automation from Desktop Design Studio reveals the reasons for this:
We can see that the DownloadAttachment component is the last to be executed in the regular flow, it has the error sign because that is where the exception happened. We can also see that the On Error branch was executed and produced the Console Log as expected - only nobody is looking at the console, right? So why not use this information to update our Work Item in the queue? Instead of a Console Log we can push the error message back to ServiceNow with a setup like this:
As you can see, I added the ResponseContent field to the UpdateWorkItem component to pass in the error message and I have set the State field to Failure.
After running the automation from the RPA Hub, this is what the Queue Item will look like:
Great, that means we do get the error back into the queue record and can use any kind of means within the platform to address it - like a flow that creates an incident to the appropriate support team for investigation.
My colleague Quentin created a short video on how you can use this technique to even trigger the incident from within the RPA Hub using a simple Subflow. Check it out on YouTube.
Advanced Error Handling in RAP Desktop Design Studio
With the Try Catch part we can already do a lot in Design Studio. You can even cascade them and an error will only propagate to the first available Catch component. This leads me to advanced techniques... what to do if something goes wrong inside your OnError branch?
Going back to my example above, we are now catch every error and update the work item with it - but what if we do not have a work item just yet? Maybe the instance had a problem (yeah.. unlikely but it could happen) or there was just no work item? The way this particular robot is implemented, doesn't really account for not having a work item in the queue. Let's see what happens when we run the bot in this scenario:
I guess you expected this result by now. The PickWorkItem was executed but did not return an item. Without an item, the GetAttachmentsMetadata part fails and brings our robot to the OnError path. Here, the attempt to update the work item it fails again because there is simply no work item. This second error is not caught anyway, so the robot aborts. This results in a Failed state on the process job table - sort of back to square one.
Instead of adding another try-catch in the OnError branch - which would actually be a perfectly valid option - I want to show you some other options.
First, let's take a look at how to control what a robot does when an error occurs. We have seen that it stops the execution and returns an error to the calling instance (process job state). This behaviour can be changed if you want or need to. To do so, select your activity in the Project Explorer - in my case, the main one - and use the context menu to launch the Error Handler popup:
This is available for every activity in your project, the one from the Startup routine (usually Main) will define the overall error handling process. By default, this is Stop, which means the robot will stop and report an error - exactly what we saw. Let's explore the options:
- Stop
Will stop the robot and exit with the error message as defined by the failing component - Inherit
Will inherit the error handling definition from the next level up in the call stack. I'll get to this in a moment. - Continue
Will ignore the error and continue processing as if nothing went wrong. Generally not a good idea but useful in some circumstances - Retry
With Retry you will get additional options to set how often the robot should retry, how long to wait between retries and what to do if all retries didn't help (Stop, Continue or Inherit).
As a best practice I would leave the Stop on your main activity to prevent the bot from doing unpleasant things.
Now that we know where to set the generic handling, there must be some setting for specific steps in your automation, right?
Let's go back to our example automation, which is currently failing in the OnError branch. Thinking about the logic, we might conclude that a problem updating the work item in this specific event is not critical to the bot as such. We could simply ignore it. To do this, we simply right-click on the UpdateWorkItem component and select Error Handler from its context menu. We get the same options as in the activity, but this time we specify them only for the selected component. Setting it here to Continue here will allow our automation to continue the OnError branch even if there was no WorkItem to begin with.
Doing this that will allow our robot to properly end with a Success state on the process job entry. But somehow we lose the information that something went wrong. We can fix this by not connecting our OnError branch to the regular END component. Instead, we can use the TERMINATE component from the toolbox and connect it accordingly:
The Terminate component provides inputs for a message and wether or not to mark this as an error or wether or not to take a screenshot. In my example, I set these options to False.
What you cannot see in the screenshot is that the UpdateWorkItem's Error Handler has been set to Continue. Trust me on this 😄
If I now run the robot from the Bot Process the process job will be created and will be set to 'Success' but will also contain the error message:
It is debatable whether this step should have been marked as Success or Failure - but at least you have the option from Desktop Design Studio and can build your automation around it.
Final thoughts
I hope this has helped you to understand the different options available. Using the powerful features within RPA Desktop Design Studio allows you to build a complex automation with robust and resilient logic, but it does take some extra time. Using the capabilities of the ServiceNow platform as backend allows for many more options on what/how to respond to errors - such as creating an incident for a support team to investigate.
Please comment if you find this helpful, what you are missing or maybe how you have already used these features in your automations.
