What happens when a software robot encounters an error?
A portal may be unavailable, an invoice may arrive in a new format, and sign-in credentials may change. Situations like these are part of normal operations. A robot’s reliability is therefore determined not only by a successful run, but above all by how safely it recognises, records, and hands off a failure.
What is the problem?
The worst possible response is nothing. The robot continues as if nothing had happened and writes incorrect data into the system.
Imagine that the amount could not be read from an invoice and the robot enters zero in its place. Or that the portal displayed a maintenance notice after sign-in, the robot did not recognise it, and the monthly report was assembled from empty data. Nobody sees anything. The robot finishes, no email arrives, and everything looks fine. The error appears a week later when payments are matched, or a month later when someone notices that the figures do not add up. By then, it is no longer possible to tell how many records are wrong.
A stopped robot causes a visible delay. A silent incorrect entry can damage confidence in the entire solution and extend the search for the affected records.
How we approach it
We build robots with the habits of testers. Testing has taught us for years to examine exactly what happens when something fails, and we bring the same approach to process automation.
Exception handling. For every risky step, we define what should happen on failure. The robot must not continue blindly or guess a missing value. If it cannot read a value reliably, it hands the item over for review.
Controlled retries. A temporary network outage or slow response may be resolved by trying again. We retry only safe steps and impose a limit; an ill-considered retry during a payment or write operation could create a duplicate.
Diagnostic records. On an error, we store technical context and, depending on sensitivity, a screenshot. Records must mask passwords, personal data, and other sensitive content.
Notification. For an agreed type of error, the robot sends an alert through the selected channel. The team does not have to wait until someone happens to notice missing data.
An item for manual processing. For an unknown format, missing amount, or corrupted PDF, the robot sets the item aside and, depending on the configuration, continues with the others. A person receives a list of exceptions together with the reason and the required step.
Every run leaves a record of what was processed, what was not, and why. It is not a black box.
What you gain
You get a robot whose failure is visible and traceable. The team knows which data was processed, what is waiting for review, and whether it is safe to repeat the run.
This is the difference between automation that reduces routine checking and a solution where a person has to verify every result after every run. In the latter case, the expected saving falls significantly.
We apply the same approach to automated testing of web applications: a failure must be visible, explainable, and traceable. Process automation is simply another use of the same habits.
Next step
Choose the three most common exceptions and decide for each one whether to stop the entire run, continue with the next item, or safely retry the step. If you would like to review the design, use a no-obligation consultation.