The run succeeded because the difficult case was skipped
An automation classifies an incoming request, cannot identify the customer and sends the record to a generic error folder. The dashboard marks the run complete. The customer still has no answer. This is a reporting success and an operational failure.
We would count a case as finished only when its business outcome is known. Moving it out of the main path can be the correct decision, but that movement creates work for somebody else. An exception queue is the part of the product that makes this work visible, assignable and recoverable. It should be designed alongside the happy path, not after launch.
Different failures need different destinations
A temporary service outage may justify retrying. A missing purchase order needs evidence. A disputed cancellation needs a business decision. Putting all of them into a retry loop wastes resources and hides the reason the workflow stopped. The model cannot invent the missing authority by trying again.
A technical dead-letter queue serves a narrower purpose. Amazon SQS documents moving messages there after unsuccessful processing attempts, using a redrive policy. The SQS guidance describes that mechanism. It does not supply an operational owner or a decision process.
Give each exception a reason that a person can act on. Unknown customer is useful when accompanied by the candidate records and the evidence used to compare them. Something went wrong only announces that the designer has transferred the diagnosis to the operator.
Design a case, not a pile of logs
The case view should show the intended outcome, the relevant source material, completed actions and the exact point where progress stopped. Distinguish a model suggestion from verified data. Include the policy or workflow version where it affects interpretation, and avoid exposing unrelated customer information merely because it was present in a payload.
Assignment needs an explicit owner and a visible age. Priority should reflect the consequence of delay, such as a customer waiting for access, rather than whichever system emitted the loudest error. A shared queue without ownership encourages each team to assume another team is looking.
Resolution choices should correspond to real work: request evidence, correct a reference, approve a permitted exception, decline the request or escalate. A free-text note is valuable context, but it should not be the only record of what was decided. Structured outcomes make recurring problems discoverable.
Returning to the workflow is another controlled operation
Resuming from the beginning can repeat side effects that already happened. An illustrative onboarding case may have created an account before failing to assign access. Repair should not create another account. Preserve checkpoints and identify which actions are safe to repeat.
Recheck the current business state and permissions before resuming. An operator's correction may arrive after the customer has cancelled or another colleague has completed the request manually. The queue must notice that the original plan is no longer appropriate.
The uncomfortable question is capacity. Automation can make routine work faster while concentrating the hardest cases in a smaller team's inbox. If nobody has time or authority to resolve those cases, the system has moved the bottleneck rather than removed it. Track unresolved age and repeated reasons alongside automation completion.
Build the exception path this week
Take a recent unresolved case, or construct a representative test case if the workflow is new. Write the missing evidence, decision owner and allowed outcomes. Give an operator enough context to resolve it without consulting the developer who built the workflow.
Then rehearse resumption after the business record has changed. Confirm that completed actions are not repeated and that the resolution is recorded. A useful first release can have a modest automated scope. It cannot have an undefined destination for everything it does not understand.