An automation exception should enter a visible queue with a reason, owner, deadline and safe resolution path. Separate a technical retry from a business decision. The system should not repeat a high-impact action simply because it cannot determine whether the previous attempt completed.
Let’s plan your automation exception process.
Bring your workflow, constraints and open questions. We’ll help you define the scope and work through the next decision.
Classify the reason work stopped
A missing invoice reference, an unavailable supplier API and a disputed approval are different problems. Treating them all as failed jobs leaves operators without a useful next step and encourages repeated retries.
Define categories with the process owner. Include invalid input, permission failure, temporary outage, conflicting records, policy review and unknown external outcome. Give each category a permitted action and a route to someone who can resolve it.
Specify the queue as part of the product
| Queue field | Why the reviewer needs it | Control to include |
|---|---|---|
| Business reference | Identifies the affected request | Link respects record permissions |
| Failure reason | Explains why work stopped | Useful detail without exposed secrets |
| Current state | Distinguishes pending from uncertain completion | Freshness and last check visible |
| Owner and deadline | Makes responsibility explicit | Escalation when unassigned or overdue |
| Available actions | Shows the permitted next steps | Role and state validation on the server |
| Resolution history | Explains previous attempts and decisions | Actor, time, reason and result retained |
Keep the queue searchable by business reference. A support person responding to a user should not need to know the internal worker identifier before finding the affected case.
Design human decisions with limits
For a hypothetical expense workflow, a reviewer might correct a missing cost centre, return the request for clarification or approve an allowed exception. Those actions should have distinct meanings. Correcting an input must not silently grant spending authority.
Show what will change before a consequential action. Require the relevant permission, and prevent a reviewer from approving an item that another user has already cancelled. If duties must be separated, enforce that rule in the action handler rather than relying on a written instruction beside the button.
Make retry safe and bounded
A transient technical failure can enter a retry policy with limits. A business rejection generally needs corrected input or a new decision. An uncertain external outcome needs verification before another action is attempted.
Track queue age and repeated failure reasons. If reviewers repeatedly fix the same field, improving the form or upstream validation may remove more effort than adding another automation step. Revisit the workflow selection baseline when deciding what to improve next.
Questions about human review
Can an exception queue become the new bottleneck?
Yes. Include reviewer capacity, absence cover and escalation in the operating plan. Measure active review effort as well as queue length.
Should reviewers have a force-complete button?
Only if its meaning and authority are explicit. A manual completion claim should not invent a confirmed external transaction or bypass required evidence.
Discuss the exception categories and permitted actions with Drema's automation team before treating the happy path as the complete scope.
