Recording exceptions alongside the normal path

Record an exception where a case leaves the normal path. Show the condition that caused departure, who owns it, the decision or repair needed, and how the case returns or closes. Keep the main map readable; do not let an exception branch end at an unexplained box.

For this mapping exercise, treat an exception as a case the routine route cannot finish as drawn. Missing information, a disputed decision and a failed handoff may need different responses. If a legitimate alternative route follows an agreed rule, label it as a variation; it need not be treated as a fault.

Exception vs Variation: Key Differences

Mark the departure point

First draw the usual route for a defined case type. At each decision or handoff, ask what can prevent the next step. Use plain conditions rather than a general label such as ‘issue’. For example, required detail missing tells the reader why a request returns; owner unavailable tells them why it needs reassignment.

Name the case state while the issue is unresolved. ‘Pending customer information’ differs from ‘awaiting internal decision’. Record who can move it on and when to check again. If a case may continue while one question remains open, show which actions are allowed and which result must wait.

Keep a compact exception record

A small register can carry details that would overcrowd the diagram. Use a shared case reference where possible so someone can move from the map to the relevant record.

Record why the final decision was made, especially when someone accepts an incomplete input or overrides a routine rule. An exception marked only ‘resolved’ does not tell the next worker what changed.

Show the route back, or a valid end

Draw where the case returns to a named step, takes an authorised alternative path or closes with a recorded result. If the original input is corrected, say whether earlier checks must be repeated.

If the case is declined, show how the requester learns the result. Do not count a referral to another team as completion unless that referral is the agreed business outcome.

For example, a request that lacks a required document might return to the requester, remain pending with the intake team and receive a fresh completeness check when the document arrives.

Check what the map still misses

Walk through a returned case, a case needing an authorised decision and a case that never returned to the main route. Ask whether each can be traced from its original trigger to a final or still-open state. If the same condition repeatedly appears, investigate whether the intake rule, information source or normal route needs to change.

Frequency alone does not decide whether to redesign an exception. Consider its consequence and whether the route is legitimate. The map should make the unusual case visible, owned and traceable.

Exception Handling Best Practices