Before automating a task, document what should happen when the normal path breaks. List missing information, duplicates, unavailable systems and uncertain outcomes, then give each exception a safe next step and a human owner. A workflow is incomplete if it can start work but cannot explain what happened when a step fails.
Choose one recurring task for the exercise. Avoid mapping the entire business at once. The aim is to create a reviewable rule for each decision, including where the automation must pause.
Write the normal path in plain language
Our fictional example is a service enquiry that should create an internal follow-up task. The normal path is: receive the request, validate the required information, check for an existing related request, create one task, and record the task reference.
Name the source record and destination record. Decide which system owns the customer request and which owns task completion. Then ask the person who normally does the work to identify occasions when these steps do not apply.
A useful rule includes an observable condition and outcome: “If the customer reference is missing, hold the request for intake review.” “Handle bad data” leaves too much unspecified.
Use an exception worksheet
| Condition | Expected path | Owner and evidence |
|---|---|---|
| Complete, new request | Create one follow-up task | Coordinator; destination task reference |
| Missing required information | Hold for review without inventing a value | Intake owner; missing-item explanation |
| Possible duplicate | Compare with existing request before creating another | Intake owner; linked record and decision |
| Destination unavailable | Use agreed bounded recovery route | Operations owner; failure record |
| Outcome unknown after timeout | Check whether the task exists before repeating | Operations owner; reconciliation result |
Add detection method, notification route and completion evidence to your working copy. The person receiving an alert needs enough context to investigate, but routine alerts should not expose unnecessary customer information.
Story one: the same request arrives twice
In the fictional workflow, a visitor submits an enquiry and then sends the same request by another route. Two submissions do not necessarily represent two jobs. The process needs a way to identify a possible match and send ambiguous cases to a person.
Define what counts as strong matching evidence. A shared name alone may be insufficient. Preserve the source references and record the merge or linking decision so staff can explain what happened later.
Do not quietly discard a record simply because it looks similar. A repeat customer may have a genuinely separate request. Exception handling should preserve that possibility.
Story two: the destination stops responding
A temporary outage may justify a controlled retry. Incorrect data generally needs correction instead. Microsoft's retry-pattern guidance distinguishes temporary failures from other faults and warns that repeating an operation can cause duplicate effects when the original outcome is uncertain.
For the business brief, specify the maximum recovery window, who receives unresolved cases and how staff can continue safely. Let the implementation team choose and test the technical mechanism appropriate to the connected systems.
An endless loop of retries is not a useful operational plan. Nor is a failure message that disappears before the responsible person sees it. Decide how unresolved work remains visible until somebody records an outcome.
Story three: nobody knows whether it succeeded
Suppose the task system creates a task but its response never reaches the automation. The source record shows no destination reference. Repeating the creation immediately could produce two tasks.
Write an “unknown outcome” state into the requirements. The recovery process checks the destination using an agreed reference or other supported method, then records whether the task exists. If it cannot determine the outcome safely, a person investigates before the workflow repeats a consequential action.
This is different from a confirmed failure. Naming the difference prevents the team from treating every missing acknowledgement as permission to start again.
Rehearse recovery before launch
Use synthetic requests to test every worksheet row. Ask the operational owner to recover a failed item using only the documented instructions. Check that the item returns to a clear state and that the history shows what was changed.
Agree who can pause the workflow, how outstanding items are reviewed and who approves changes to the rules. Keep a manual route for the defined task where feasible. Share this worksheet when scoping business automation with Tralionex so failure handling is part of the conversation from the beginning.
Classify failures by the decision they require
A missing field, a rejected request and an unavailable destination need different responses. Group exceptions around the next useful decision: correct information, resolve a possible duplicate, restore a dependency or establish whether an action already happened. This is more helpful to an operator than a long list of technical codes without context.
In your worksheet, keep the system's diagnostic detail available for the technical team while giving the operational owner a plain-language task. “Review the missing customer reference before continuing” identifies an action. “Integration failed” does not explain whether the person should wait, correct a record or stop further processing.
Define who may resume the workflow
Pausing is only half of recovery. Specify which role can correct the source, which role can authorise continuation and what evidence shows the prerequisite has been satisfied. For a low-risk task, one person may perform these steps. More consequential actions may require a separate review under your organisation's process.
In the fictional follow-up-task example, an intake colleague supplies the missing reference and records where it came from. The workflow then rechecks the required information before proceeding. It should not skip validation simply because a human touched the record. Keep the source correction visible so another colleague can understand why the paused item moved forward.
Plan for a partial result
A workflow may complete its first step and fail on the next. Suppose it creates the internal task but fails to attach the enquiry summary. Treat that as a task needing repair rather than starting the whole process again. The record should identify which step completed and which remains outstanding.
Ask the team whether the partial result is safe to use. A task without enough context might need a visible warning or temporary hold so its owner does not contact the customer with incomplete information. Define the business response first, then ask the implementation team how the systems can support it.
If staff need a shared view of these cases, scope an exception queue through web portals and dashboards. The important requirement is the ability to find unresolved items, their owners and their next actions. The existence of a dashboard alone does not establish that recovery is happening.
Keep alerts proportionate and actionable
Sending every temporary failure to the entire team can make important problems difficult to notice. Decide which conditions need immediate attention, which belong in a routine review and which can be recorded without interrupting anyone. Base this on the task's consequence and operating hours, not on a generic rule that more alerts mean better control.
An actionable alert identifies the affected reference, current state, responsible role and route to the recovery instructions. If the owner is unavailable, the escalation path should still reach someone who can act. Avoid repeatedly notifying people about the same unresolved item without showing its existing investigation status.
Close the learning loop after recovery
After an exception is resolved, record the cause only as far as the evidence supports it. Separate a confirmed cause from an initial suspicion. Review recurring patterns and decide whether to change validation, clarify the process or improve the dependency. Test any revised rule against the original exception and the normal path before expanding its use.
Frequently asked questions
Should every error be retried automatically?
No. The recovery rule depends on the failure and the consequences of repeating the action. Missing or incorrect information often needs review.
Who should own exceptions?
Choose an operational role that can investigate the task, with technical escalation available when needed. An alert without an owner is unfinished work.
Can we add exception handling later?
You can improve it over time, but the first release still needs a safe response to foreseeable failures and unknown outcomes.
How do we measure a pilot?
Track completed tasks, unresolved exceptions and manual corrections against an observed baseline. Do not promise time savings before testing the actual workflow.
Plan your next project with Tralionex
Bring the normal workflow and its exception worksheet, including uncertain outcomes and recovery owners. Discuss a bounded automation project with Tralionex that includes how your team will identify, investigate and resolve unfinished work.
