# Automation exception register

Give cases that leave the standard flow a defined path. The register should help restore work with a verifiable outcome, rather than merely collect error messages.

Revision: 2026-09-24

## When to use it

During pilots and ongoing operation, when work gets paused, records are incomplete or outcomes between systems are uncertain.

## Expected output

An exception queue with status, priority, ownership and closure evidence; repeated issues become inputs to workflow improvements.

## 1. Identify the case

Capture enough context to find the operation without unnecessarily copying confidential data. One exception should not create several disconnected records.

### Reference, time and step

Record case identifier, workflow version and the last step known to have completed.

________________

### Observed issue and evidence

Describe the visible symptom, link accessible logs and distinguish facts from suspected causes.

________________

### State in connected systems

Check which writes happened and which remain uncertain before another attempt.

________________

> Illustrative example, replace with your own: Illustrative example: ORD-042 is paused after an ERP timeout. Its email was read, but it is not yet clear whether the order draft was created.

## 2. Assign priority and action

Priority follows the effect on operations, not the length of a technical error. Distinguish an isolated case from a failure affecting the whole queue.

### Impact and urgency

Record affected cases, operational deadlines and possible effects on customers or records.

________________

### Owner and next update

Assign a person or staffed role, a backup and the time of the next update.

________________

### Containment and fallback

Describe what stops, which cases may continue and how work can temporarily proceed manually.

________________

> Illustrative example, replace with your own: Illustrative example: pause ORD-042, search for its reference in the ERP and let other cases continue if no related failures appear.

## 3. Verify before closing

A successful retry is insufficient if duplicates or partial effects remain. Connect the fix to the business outcome and to lasting prevention.

### Recovery action

Record checks performed, manual changes and the exact point from which work resumes.

________________

### Closure evidence

Confirm the correct outcome, absence of duplicates and notification of the case owner.

________________

### Cause and preventive change

Record category, similar cases, proposed change and a test to add before the next release.

________________

> Illustrative example, replace with your own: Illustrative example: the draft already existed. Link it to the case, avoid creating another and add a reference lookup after timeouts to the workflow.

## Pitfalls to avoid

- Closing the technical issue while leaving the business case incomplete.

- Repeating the whole process manually after some effects already occurred.

- Leaving the exception queue without an owner or regular review.

Stolen Orbit — https://stolenorbit.com/en/templates/exception-register/