Ask About Exceptions Before Designing a Workflow
Build missing, conflicting and revoked-input exception cards with owners, hold states and release evidence before claiming a standard workflow is complete.
10/24/20263 min read
A standard workflow is easiest to describe when every input is present, every owner is available and every permission remains valid. Real work includes missing information, conflicting evidence and changed instructions. Ask about those exceptions before deciding that a clean main path is ready to automate or sell as a complete solution.
The aim is not to imagine every possible failure. It is to identify a small set of exceptions that would change the next safe action. A useful exception has an observable trigger, an owner and a defined hold, repair or escalation path.
Start with three kinds of uncertainty
Missing means a required input or responsible role is unavailable. Conflicting means credible inputs disagree. Revoked means a permission or previously valid instruction no longer applies. These categories often expose different control needs, so do not send all of them into a generic error state.
Ask the buyer for a representative example of each, using synthetic or minimized information where practical. Keep the discussion focused on process behavior. There is no need to collect a large archive of real customer incidents merely to discover whether the workflow has a hold state.
Worked example: an account-review queue
Fictional buyer Cedar Services wants a routine process that passes researched accounts to a salesperson. The happy path is simple: verify the account, assign an owner and prepare a review task. Three exception cards reveal what the description omits.
Card M contains an account with no confirmed operating entity. Expected behavior: hold for identity clarification, with a named research owner. Card C contains two reliable sources showing different current owners of a business location. Expected behavior: preserve both sources, block claims depending on ownership and request resolution. Card R contains a valid account with a new stop request from the contact. Expected behavior: prevent affected contact actions and update the authoritative restriction process.
The completed exception map assigns different outcomes to each card. Missing information is not a reason to invent a value. Conflict is not resolved by choosing the convenient source. Revocation is not treated as a temporary technical error that will disappear after another retry.
Ask about recovery, not only detection
How will the responsible person know an exception exists? What evidence is needed to resolve it? Who may release the hold? Does the original action need fresh approval after the facts change? These questions turn a warning into an operational process.
Consider the risk of partial completion. An internal task may already exist before a later step fails. The team should inspect actual state before repeating the process. A generic restart button can create duplicates or revive an action that is no longer appropriate.
Keep exception work visible in the scope
A proposal should not describe a workflow as fully automatic if people must resolve important cases. State the review role, expected inputs and limits without inventing a predictable exception rate. If the frequency is unknown, it is a measurement question for an approved pilot rather than a number to guess.
Likewise, do not promise that a tool will handle a case merely because the desired behavior has been written down. Verify supported capabilities and configuration through current documentation and authorized tests. A good design is not proof of an implemented control.
Test one exception at a time
Use a controlled synthetic fixture and record input, expected behavior, observed result and unresolved issue. First test the standard path so the baseline is clear. Then introduce one missing field, one conflict or one revoked instruction without changing unrelated conditions.
The final artifact is a small exception catalogue linked to owners and release criteria. Provenance and privacy principles help preserve evidence and limit unnecessary data use. A workflow that pauses clearly can be more useful than one that appears smooth because it guesses, ignores restrictions or hides unfinished work. Designing those pauses is part of the service, not an embarrassing detail to remove from the sales story.