Whether you’ve been working with Robotic Process Automation (RPA) for some time or are just exploring its usefulness for your business, you’ve likely experienced or considered RPA bot failures as a challenge to your program’s success. A bot failure – or any time a bot doesn’t complete the automation it was designed to do – can happen for any number of reasons from a failed network connection to an Internet or power outage.
The truth is that with appropriate guidance and oversight during development, bot failures are very rare, but they do still happen. As a business leader, it’s important for you to understand the types of failures that occur and the measures that should be implemented to telegraph and prevent future faults.
A standard failure occurs when a Robotic Process Automation bot stops executing for an unexpected but (normally) apparent reason. For example, imagine a bot designed to retrieve data from a webpage via a series of 200 steps (i.e., its programming). When it reaches step 148, the requisite information has been relocated to another position, so the bot is unable to continue until step 148 has been updated with the data’s new location on the page. Standard failures like this example are the most common and generally require maintenance to ensure ongoing accuracy and efficiency.
An anticipated failure is one that is – you guessed it – anticipated! This means the RPA developer is aware of its potential and can write code to accommodate it. For example, if login credentials for a given system expire every 90 days, the developer can write code to automatically send an email to the IT group requesting new login credentials when the current ones fail. The bot still doesn’t complete the automation, so it technically fails, but it does so gracefully and signals that the work has been stopped.
The final kind of failure is the most challenging; it doesn’t provide notification of a problem, and the runtime log indicates no errors. A silent failure is an invisible problem that you’re not aware you have to solve until someone recognizes that the automation has failed (and usually at the most inopportune time)! Fortunately, these errors are rare, occurring only about 1% of the time.
As an example, consider an automation designed to aggregate sales data, perform calculations, and then copy and paste the data into a Google Sheets report each night. The bot executes every step without issue, but when a user opens the file the next morning, the report is blank. The bot executed the command for paste, but for whatever reason, Google Sheets did not accept it or save it, resulting in no data, and there were no bot-reported errors. This is what makes silent failures the most challenging to address.
Now that you understand the three types of RPA bot failures, what can be done about them?
To address standard failures, a bot should be coded to flag an error via an email or similar notification and include a log file that details the reason it failed. This helps add context to what went wrong, and it quickly points automation developers to the necessary solution. When a standard bot failure occurs, the recommended order of operations to fix the issue is as follows:
The turnaround time to address standard failures is typically just 15 minutes. They don’t happen often, but when they do, they’re usually easy to fix.
Resolving anticipated failures is largely done during the planning stages of an automation. Proper planning, combined with experience, often illuminates potential exceptions and faults in a process flow. An RPA developer then writes rules or logic directly into the bot’s code in anticipation of each failure.
For example, imagine a bot needs to access a cloud network drive to complete its task. If the network hardware has a shaky connection and is inaccessible, the bot can be programmed to hold and retry ten minutes later for two or three or ten more times before completely stopping and flagging the error. In this case, assuming the retry yields a connection to the network drive, the built-in programming prevents the failure altogether.
As previously mentioned, standard failures that occur with any regularity might become anticipated failures. With these failures, the developer almost always knows when they happened and why, making it easy to implement a fix in the code. As such, solving anticipated failures of this nature takes only moments of the developer’s time.
Unfortunately, silent bot failures are usually discovered by the party most affected by the failure. In these cases, the recommended resolution process is as follows:
While they’re extremely rare, silent failures do happen, often due to an unanticipated variable in a new project. The good news is that usually once a silent failure is discovered, it can be quickly remediated.
They’re not perfect, but RPA bots are efficient tools that are always on the clock for you. If you’re interested in learning more about RPA and its many benefits, please feel free to subscribe to our blog or check out our other resources.