An automation demonstration passes a complete request, but the first incomplete request during real operation becomes stuck where nobody knows to look. The tool may not have failed: exception handling may never have been included in the implementation scope. Ask the supplier who receives a case when automation cannot complete it.
Do not request a promise that every case will be handled automatically. Request an agreement distinguishing technical retries, returns to the requester, and cases requiring human judgment or processing. It should identify where each case appears, its owner, and the evidence permitting resumption or closure.
Not every interruption is a technical failure
In a fictional office-supplies purchase-request workflow, a request reaches review before preparation of the next action. It may be rejected because the item is not approved, lack a description, or encounter an unavailable supplier system. All three interrupt the usual path but need different responses. The example illustrates design, not a customer system or an actual purchase.
Rejection is a meaningful process decision, so repeatedly retrying it until approval makes no sense. Missing information needs the requester, while service unavailability may justify another attempt within appropriate limits. Begin with “what should happen now?” rather than labeling everything an error in one list.
An exception matrix inside the proposal
| Example case | Response to discuss | Acceptance evidence |
|---|---|---|
| Required information is incomplete. | Return to the requester with a clear explanation and retained reference. | The user knows what to correct and how to resubmit. |
| An authorized reviewer rejects it. | End the workflow or open a revised request under policy. | A clear reason without unauthorized downstream execution. |
| A service is temporarily unavailable. | Bounded attempts with suitable count and delay, then escalation. | A result record and owner when attempts run out. |
| Manual verification is required. | A visible pause for an authorized employee before resumption. | A recorded decision and the subsequent resumed steps. |
This editorial matrix is not a ready-made configuration for every activity. Add process-specific cases and identify how the solution selects a response. If it cannot distinguish two cases, the proposal should state the limitation and review route instead of implying it can decide without the necessary data.
Human handover is a process with an owner
“A notification will arrive” leaves important questions open: where does the employee see the request, which information is necessary, and who substitutes during absence? Can the employee modify data or only retry? Define permitted actions, separate approvals and what the requester sees while waiting.
Request a view or register connecting the case to its original request, suspension reason, latest action and current owner. Limit sensitive details to authorized people rather than turning a notification into a complete copy of request files. The employee needs access to the information necessary for the permitted action.
Automatic retries do not solve everything
Microsoft guidance explains paths after failure or timeout and retry policies for temporary problems. Camunda's guide distinguishes technical responses from those changing the process route or handing it to a person. These concepts help assess proposals; their presence in a product does not prove an exception plan has been configured for your project.
Ask what happens when authorization expires, request data changes or retries end. An open-ended waiting loop is not an owner. If the result in another system is unknown, consult retry and reconciliation acceptance tests; that is a different question from simply retrying a failed step.
Let operational users test exceptions
Before activation, prepare an incomplete case, a rejected case and an arranged service failure in a test environment. Have the employee explain what appears and what action to take, then let the supervisor inspect the resulting state. A developer showing a green indicator is insufficient: demonstrate that the action did not disappear or bypass a necessary decision.
Discuss reviewing recurring suspension causes without assuming unmeasured savings percentages. Repeated missing information may suggest improving a form, while access failures indicate a different maintenance task. Record the rules version, change approver and support boundaries: introducing a new business case differs from correcting a fault in an agreed case.
The process preparation pack helps describe current operation. Then attach the exception matrix when requesting process automation from Nextwave, so discussion includes days when work does not follow the demonstration's happy path.
Sources and limits
Microsoft's error-handling guidance and Camunda's exception guidance were opened on 4 November 2026. The example and matrix are editorial material without product commitments or support-time promises. AI assisted preparation, with meaning and translation review.
