Intelligent Automation/RPA

RPA exception handling: Be in control or be controlled

This article serves as the definitive guide to writing exceptions in RPA development with graceful recovery and effective data logging.

banner image

Robotic process automation (RPA) software can automate specific tasks, replicating manual work keystroke by keystroke. Companies across industries are finding RPA can free up human workers from repetitive work, reduce costs and eliminate errors that are common in back-office processes like data entry or invoice processing. A manufacturing employee that spends three hours a day processing 100 shipment orders, for example, can use RPA to complete the same volume in about 30 minutes with improved accuracy. But maximizing the return on an RPA investment requires careful configuration.

How do business exception cases happen in relation to software bots?

Occasionally, in the course of its work, the RPA bot will encounter a situation it was not programmed to handle – and, in these cases, it will stall. This can be for foreseeable reasons – security or access constraints – or it can be for unforeseeable reasons – like missing or incorrect data. Increasingly, RPA developers are able to create automation that can gracefully recover from an error and save the error details for analysis or predict when errors might occur. The most common errors or exceptions for an RPA bot are either business exceptions or application exceptions.

A business exception happens when a software bot is unable to process a transaction due to its programmed instructions. In other words, the business exception is written into the automation’s code. For example, a robot processing invoices in a bookkeeping application may be programmed to process invoices up to $2,000. When it comes across an invoice for $4,000, the bot recognizes it is unable to process it and throws a business exception alert. If an RPA bot involved in onboarding new associates comes across an incomplete form that is missing the new associate’s social security number, the bot will recognize it must have this field to continue with the process and throw a business exception. In both cases, the robot logs the exception and moves on to the next transaction.

What is the best way to program RPA bots?

RPA bots should be programmed to notify human supervisors, most commonly via email, about incomplete transactions due to business exceptions. It is then the business owners’ responsibility to manually process these transactions or provide the necessary data for the robot to revisit and process them accurately. If the business owner pays attention to the business exceptions the robot flags, he or she can communicate that information back to the programmer to adjust the automation in case it can be configured to better handle typical business errors.

What is an application exception in relation to robots?

An application exception occurs when a robot encounters a technical issue, such as a server crash, a malfunction, or a change to the technology environment that requires interaction with a new application, program, or website. For example, a robot that must click a log-in button on a web application stalls when the webpage does not completely load. The best way to overcome application exceptions is for the bot to simply try again; sometimes these errors are incidental and can be resolved by repeating a certain scope of the process.

Successful automation recognizes where applications are likely to fail and are able to try again. Of course, a developer can build automation to account only for circumstances that are known. If a robot encounters an unexpected situation, like a new screen on a webpage, the robot will continue to error, eventually reach its maximum number of retries and throw an application exception. The best automation will notify a human operator with an email containing a screenshot of the error, important argument values, an error message, and the source of the error.

How can developers build graceful recovery into RPA bots?

Developers should plan for failure and build graceful recovery into RPA bots. When a robot throws a business exception while processing a transaction in an application, for instance, it should be programmed to clean up temporary files, undo partially completed records, and return to the starting point so the robot can begin the next transaction from the correct screen. Or if a robot throws an application error while trying to navigate to a URL, it should close the web application, then restart it and navigate to the URL. As a precaution, the automation main code should be in the “try” block of a “try-catch” statement – the code that tells the bot what to do in case of an exception – and should contain the automation’s clean-up code block. This will give it proper instructions for cleaning up errors when they occur. If an application exception occurs leaving applications like Excel and Chrome open on the desktop, the bot should close any programs it opened, so it can guarantee every automation will begin with a clean desktop.

How can data logging be improved?

A vital component to exception handling is logging. An exception log should contain data relevant to the transaction, including the time the error occurred, the error message string, and any unique identifiers. These logs can be used to help debug the automation and fine-tune business requirements. They also help create analytics that assesses the efficiency of automation.

When a RPA bot is sufficiently programmed to handle exceptions, recover gracefully and log the related data; the business is well on the way to maximizing a return on RPA investment.

Let's talk!

Interested in learning more? We'd love to connect and discuss the impact CAI could have on your organization.

All fields marked with * are required.

Please correct all errors below.
Please agree to our terms and conditions to continue.

For information about our collection and use of your personal information, our privacy and security practices and your data protection rights, please see our privacy policy and corresponding cookie policy.