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.
Types of Bot Failures
Standard Failures
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.
Anticipated Failures
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.
Silent Failures
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.
How to Address Bot Failures
Now that you understand the three types of RPA bot failures, what can be done about them?
Solving for Standard Failures
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:
- Notification: The RPA developer or team is notified of the problem.
- Corrections: A developer reviews the log file, identifies the problem, and makes the necessary code changes.
- Resets: The requisite inputs or other files are reset to prepare the bot to be rerun.
- Rerun: The automation is rerun to ensure it works as expected.
- Recode (if needed): If the failure happens frequently enough, its cause may become anticipatory, and the developers update the bot’s code accordingly.
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.
Solving for Anticipated Failures
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.
Solving for Silent Failures
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:
- Discovery: The error is identified and reported by the user(s).
- Root Cause: The RPA developer(s) quickly determine the root cause of the failure.
- Add Positive Check: A developer creates a positive feedback check for the bot. Referring to the Google Sheets scenario, for example, an RPA developer might add a step to the bot’s programming to check the number of records after pasting the data, confirming the paste function did, in fact, work.
- Modify: If there are more opportunities for silent failures, the developer revisits and updates the bot’s code to ensure future reliability.
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.
