RPA Exception Handling – Be in control

Companies in every major industry are turning to semiautonomous computers (better known as BOTs) to automate large- and small-scale business processes. This technology replaces human intervention in back-office operations, improving operational efficiency, reducing costs and increasing margins. However, organizations cannot employ this technology effectively unless the BOTs are engineered properly. And one of the most important component of this BOT engineering is Exception handling or in simple words right categorization of the errors and then developing solutions around the same to deal with those errors to meet the expectations of the RPA owner.

Occasionally, in the course of its work, an RPA BOT definitely encounter a situation it was not programmed to handle – and, in those cases, it will stall. Those cases 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 automations that can gracefully recover from an error and save the error details for analysis or predict when exceptions might occur. The most common 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 $5,000. But when it comes across an invoice for $5,282, 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 Aadhar Number or 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 BOT logs the exception and moves on to the next transaction.

RPA BOTs should be programmed to notify process / workflow managers, 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.

An application exception occurs when a BOT 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 BOT 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 automations recognize where applications are likely to fail and are able to try again. Of course, a developer can build automations to account only for circumstances that are known. If a BOT encounters an unexpected situation, like a new screen on a webpage, the BOT will continue to error, eventually reach its maximum number of retries and throw an application exception. The best automations 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.

Developers should plan for failure and build graceful recovery into RPA BOTs. When a BOT 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 BOT can begin the next transaction from the correct screen. Or if a BOT 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 automations 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 the bot should close any programs it opened, so it can guarantee every automation will begin with a clean desktop.

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 assess the efficiency of the automation.

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

------------------------
-----------------
-------