Designing the exception path

Describe the ordinary case and the cases that interrupt it

A process description usually begins with the expected sequence: a request arrives, information is prepared, someone makes a decision and the result is recorded. The less convenient cases deserve the same attention. An attachment may be missing. Two records may disagree. A connected system may time out after receiving an update.

Start with recent examples from the people who do the work. Ask what they checked, what they could not establish and how they continued. Include the email, spreadsheet or telephone call that kept the process moving. These steps help reveal the operating requirements that an idealised diagram can omit.

Give each exception a defined next state. The important question is whether the system and the person responsible can establish what has happened and what should happen next.

Different interruptions need different responses

A missing input, a business decision and a technical failure are different situations. Treating them all as a generic error creates an inbox that someone must investigate from the beginning.

Separate the reason the work stopped from the proposed response. A model can help classify or summarise the issue, but the application should preserve the source, the actual operation attempted and the evidence available.

Information required

Explain which detail is missing and who can provide it. Keep the item associated with the original request.

Decision required

Identify the person authorised to decide, the options available and the consequences of each action.

Temporary technical failure

Define whether another attempt is safe, how many attempts are allowed and when the item should be escalated.

Outcome uncertain

Check the destination before repeating a change. A timeout alone does not establish that an update failed.

Give the reviewer a case they can act on

A useful exception queue contains the information needed for the next decision. At minimum, consider the request, its current state, the reason for the interruption, the source material and the responsible person. The exact record depends on the work and its sensitivity.

For AI-assisted preparation, keep the proposed information distinguishable from the verified information. A reviewer should be able to inspect the supporting material and correct a field without reconstructing the process across several systems.

Decide what happens after review. Approving a proposal, correcting a value, requesting more information and closing the item are distinct actions. Record the decision and resume from the appropriate point. Avoid rerunning earlier actions that have already taken effect.

Design recovery before adding automatic retries

A failed read and an uncertain write have different consequences. Repeating a lookup may be harmless; repeating a payment instruction, a message or a record creation can produce a second effect. Retry behaviour must follow the operation and the destination’s actual guarantees.

For an operation that creates a business record, the design may use a stable request identifier, a destination-supported idempotency mechanism or a reconciliation check. The implementation must also define what happens if the same identifier arrives with different contents.

Set timeouts, retry limits and escalation rules together. An item that cannot safely continue should remain visible with enough context for an authorised person to resolve it. The workflow also needs an agreed way to continue work during a service interruption.

Test the complete exception journey

Use representative material that includes incomplete inputs, conflicting values, denied access and interrupted connections. Check the destination as well as the screen: a reassuring message in the interface does not prove that the expected record exists.

Assess whether the right person sees the item, understands it and can move it into a valid next state. Measure time waiting for a decision separately from time spent processing. Include safe retries and resumed work in the acceptance examples.

An exception path is part of the service being delivered. Its ownership, operating instructions and evidence of testing belong in the scope and handover.