This is a ready-to-use log for every exception an RPA bot raises and the human action that follows. It exists to prove the control a validation package promises, that the bot stops and routes to a human rather than guessing, actually happened and was closed out. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows. This content is educational reference, not legal or regulatory advice.
Log control
| Field | Entry |
|---|---|
| Log title | RPA Exception and Human Intervention Log |
| Log number | <<FILL: LOG-ID>> |
| Bot(s) covered | <<FILL: single bot or fleet-wide>> |
| Owner | <<FILL: role>> |
| Review cadence | <<FILL: e.g. weekly trend review, each periodic review>> |
Why a separate log, distinct from the target system’s audit trail
An RPA bot’s platform execution log captures every run. This log is the subset that matters to a human reviewer: the runs that did not complete cleanly. The target system’s own audit trail still records what was written, or not written, to the GxP record. This log is where you prove a stopped bot actually reached a person and was closed out, which is the evidence behind the design commitment that the bot halts and routes to a human instead of guessing. See audit trail design and review for the companion control covering the target system’s own trail. Treat this log as the human-facing half of exception management and the change-and-version log as the system-facing half: a recurring exception that traces back to a system change belongs in both, cross-referenced, so a reviewer looking at either record sees the whole story.
Log (one row per exception event)
| Event ID | Date/time | Bot ID | Exception type | Record/item affected | Routed to | Human action taken | Time to resolution | Root cause (if recurring) | Closed by / date |
|---|---|---|---|---|---|---|---|---|---|
<<FILL: EXC-001>> | <<FILL>> | <<FILL>> | <<FILL: source blank / target locked / login expiry / unexpected pop-up / format fail / read-back mismatch>> | <<FILL: record ID>> | <<FILL: queue/role>> | <<FILL>> | <<FILL: hh:mm or days>> | <<FILL: n/a or cause>> | <<FILL>> |
<<FILL: EXC-002>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Field definitions and instructions
| Field | Instruction |
|---|---|
| Exception type | Use a controlled list that matches the test categories in the bot’s test protocol, so types can be trended instead of re-read as free text each time. |
| Human action taken | Describe what the person actually did: confirmed and manually entered the value, rejected the item, escalated it. Not just “resolved.” |
| Time to resolution | Measure from the exception timestamp to closure. A rising trend is itself a finding even before any single event looks like a problem. |
| Root cause (if recurring) | Mark an event recurring the second time the same underlying cause appears, and link it to a row in the bot’s change-and-version log if a fix is required. |
| Closed by / date | Closure requires a named person distinct from the bot; an exception the bot appears to have resolved on its own, with no human in the loop, is not a logged exception, it is a silent failure and a separate deviation. |
Retain this log for not less than <<FILL: retention period>>.
Acceptance criteria
- Every exception the bot’s platform execution log recorded has a matching row here, with no gaps.
- No row shows an open exception older than
<<FILL: target closure time>>without an escalation note. - Exception types are drawn from the controlled list used in the validation protocol, so a trend inside one category is visible.
- A root cause marked “recurring” links to a change-control record.
- Nothing in this log shows a bot resolving its own exception without routing to a human.
Trend review: what this log is actually for
A single exception is a data point. A rising exception rate on one bot, or a cluster of the same exception type across several bots that share a system, is the early signal that something underneath the automation is drifting: a browser update, a slower server response, a field that moved. Review the trend, not only the backlog of open items, at the cadence stated in the log control block, and feed a genuine pattern into the bot’s periodic review and, where a system is implicated, into the bot register’s change-impact process.
Filled specimen
| Event ID | Date/time | Bot ID | Exception type | Record affected | Routed to | Action taken | Time to resolution | Root cause | Closed by |
|---|---|---|---|---|---|---|---|---|---|
| EXC-041 | 2026-08-14 09:12 | RPA-STAB-01 | Source blank | Sample S-22841 | Analyst QC queue | Analyst confirmed the result was not yet entered in LIMS; held for completion, bot re-run after entry | 0d 2h 10m | n/a, upstream timing | A. Patel, 2026-08-14 |
| EXC-042 | 2026-08-19 14:03 | RPA-STAB-01 | Read-back mismatch | Sample S-22890 | Analyst QC queue | Analyst found a trailing-space formatting difference, confirmed the source value was correct, traced the cause to a LIMS export change | 0d 1h 40m | Recurring, third instance; linked to CHG-015 to normalize whitespace in the comparison | R. Gomez, 2026-08-19 |
EXC-042 is the log earning its keep. The same mismatch type showed up three times before anyone connected it to a LIMS export format change, and marking it recurring is what routed a fix into the change-and-version log instead of three separate analysts each quietly re-confirming the same false alarm.
Common inspection findings this log prevents
- A bot’s exception queue exists in the platform console, but nothing proves a human actually closed each item.
- Exceptions marked resolved with no record of what the human actually did or confirmed.
- A rising exception rate with no trend review, so a drifting bot runs for weeks before anyone looks.
- Recurring exceptions never traced to a root cause or linked to a fix.
- An exception the bot appears to have handled itself, with no human in the loop at all.
How to adapt this log
- Pull the exception type list directly from the bot’s test protocol, so the categories match what was actually tested.
- Set a target closure time appropriate to the bot’s risk level and escalate automatically when a row exceeds it.
- Wire a “recurring” tag to open a row in the bot’s change-and-version log rather than relying on memory.
- Review the trend, not only the open backlog, at each periodic review.
- If the platform already logs exceptions natively, use this log as the human-intervention layer on top of it rather than duplicating the raw execution log.