The happy path of a bot is the easy part. A developer can build it in a day from a process definition document. What takes the rest of the project, and what decides whether the bot is trusted a year later, is everything that happens when the input, the system or the world is not what the happy path expected. Exception handling is not a feature added at the end. It is the product.
Two kinds of exception, handled differently.
A business exception is a case the process rules say the bot should not complete: the invoice has no PO, the customer is on hold, the date is in the future. The data is wrong or the rules say stop. Retrying will not help. The item should be marked, the reason recorded, and a person told.
A system exception is a failure of the environment: the application did not respond, a selector was not found, the network dropped, a session expired. The data may be fine. Retrying often helps. The item should be retried under a policy, and if it still fails, parked and the support team told.
Confusing the two is the most common defect we find in bots built without a framework. A business exception that is retried three times wastes time and may post a duplicate. A system exception marked as a business exception sends a clean item to a reviewer who cannot see anything wrong with it.
Retry policies that do not make things worse.
- Retry only system exceptions, and only the ones known to be transient. A missing selector after a screen redesign is not transient.
- Use back-off between retries, so a struggling application is not hit three times in ten seconds.
- Cap the retries per item and per run. A bot that retries forever is a bot that never reports.
- Make every retried step idempotent. Check whether the record was already created before creating it. Use a reference number the target system will reject as a duplicate. Never assume the first attempt did nothing.
- Record the retry count on the item, so the operations team can see which steps are flaky.
Structure the bot so exceptions have a place to go.
A state-machine structure, of the kind the REFramework popularised, exists mainly to give exceptions a defined path: initialise, get an item, process it, and either complete, raise a business exception or raise a system exception, then decide whether to continue, retry or stop the run. Work queues make this concrete: each transaction item has a status, an exception type and a reason, and the orchestrator reports on them. Build on this structure even for small bots. The discipline is cheap and the alternative is a bot where the only exception handler is the one at the top that writes to a log nobody reads.
Escalation: who finds out, and how.
| Event | Who is told | How | Expected action |
|---|---|---|---|
| Business exception on an item | Process owner's team | Queue, dashboard, daily digest | Resolve the data, resubmit or close |
| System exception on an item, retries exhausted | Automation support | Ticket with the item reference and screenshot | Investigate, fix, rerun |
| Run did not start or did not finish | Automation support, on call if business-critical | Alert from the orchestrator | Restart, then root-cause |
| Exception rate above threshold | Automation lead and process owner | Alert plus review meeting | Find the systemic cause |
Note the first row. Business exceptions belong to the business, with a queue and a service level, not to the bot team. If the automation team ends up resolving data problems, the process owner has outsourced their job to the wrong people and the queue will grow without limit.
Logging that answers the question.
The question, when something goes wrong, is always the same: what did the bot see, what did it do, and what happened next. Log the state at each transition with the item reference. Log a screenshot on system exceptions. Log the values the bot read, masked where they are sensitive. Keep logs long enough to cover the audit horizon. And structure them, so a support engineer can filter by item, by step, by exception code, rather than reading a text file at three in the morning.
The review loop.
Exception handling is not finished at go-live. Every fortnight, look at the exceptions by code. The top three business exception codes are usually process or data problems that can be fixed at source. The top system exception codes point at fragile steps that should be rebuilt against an API or a more stable selector. Each fix should move the straight-through rate. This loop is the difference between a bot whose exception queue grows and one whose queue shrinks.
A bot is judged on the cases it got wrong. Design those first.