BPMN for the Path Where Things Go Wrong

Every place a case waits needs an event that can move it. Six waits in a returns case, drawn in BPMN, and four answers the notation forced.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece stands on the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built only from public sources - a published returns policy, help centre articles, ten public complaint threads I selected myself, consumer law and a walk through the published customer journey. No client, no interviews and no team. The case draws its process in plain text boxes. What follows is my redrawing of those boxes in BPMN terms, and every verdict in the tables is mine [MINE], read from the case, the OMG's BPMN specification page and the Camunda documentation of how BPMN events behave.

An exception path in BPMN is any route by which a case leaves the expected sequence: a gateway branch, an event on the boundary of a task, or an end event nobody wanted. Modelling it well comes down to one question asked wherever a case waits: which event may move it, who throws that event, and what happens if it never comes.

In short

• A boxes diagram lets an arrow end in "case parked" with nothing after it. In BPMN a waiting case has to wait for a named timer, message or signal, and that is where the notation earns its keep.
• Drawn that way, the as-is of the case has two waits, and both can be ended only by an event from the customer's lane.
• The to-be has four more. At each the notation asks something the case has not answered: does the timer stop the first agent, what fires when the escalated deadline passes, which calendar counts the days, and where the case actually ends.
• The filled card below takes one wait, the escalated case, through every field. The blank card is for your own process.

Why does the notation matter on this path and nowhere else?

On the happy path it barely does. The as-is piece on this site says so: "BPMN if you know it, labelled boxes if you do not." Request, check, decide, pay reads the same in any notation.

The exception path is mostly waiting, and BPMN, which the OMG calls "the de-facto standard for business processes diagrams", is strict about waiting. The Camunda documentation of the event-based gateway: "the process instance waits at the gateway until one of the events is triggered", and "Each sequence flow must be connected to an intermediate catch event of type timer, message or signal." Then: "When the first event is triggered, the outgoing sequence flow of this event is taken."

A wait in BPMN is a race between named events, and you have to name the runners. A box labelled "case parked" names none.

The waiting test: every place a case stops

Six points where a case waits or reaches a branch that decides its fate. Lines in quotes are from the case.

W1 and W2 are the whole as-is, and both are ended only by the customer. W3 to W6 are the to-be, and each produced a question the case's text does not answer. Three of the four appear nowhere in the review log. The fourth, the calendar, grows out of the clock-hours question RL-02 exposed.

What does the as-is look like when it has to name its events?

Section 3.2 of the case describes the parked state in prose: "No alert fires, because nothing is late. Nothing is late because no clock was ever started." In BPMN that paragraph becomes one shape.

AS-IS, STEP 6b, REDRAWN AS BPMN

  Agent lane:     [Judge the evidence] --(cannot decide)--> (event-based gateway)
                                                                  |
                                          one outgoing flow only  |
                                                                  v
  Customer lane:                                   (message: customer calls again)
                                                                  |
                                                                  v
  Agent lane:     [Open the case again] - new agent, evidence requested again

An event-based gateway with one branch collapses into a plain message catch event, and that collapse is what makes the drawing useful. A reader who knows the notation sees at a glance that no timer is attached and that the only event ending the wait starts in the customer's lane. The boxes version says "case parked" and lets the reader imagine somebody is looking after it.

W1 is the same shape, smaller. Both as-is waits are races with one runner, and change 2 of the to-be, seen in notation, is the second runner: a timer on the company's side.

Interrupting or non-interrupting: which timer is the 48 hours?

BPMN attaches a timer to the edge of a task in two ways that mean opposite things. The Camunda page on timer events: for an interrupting timer, "When the corresponding timer is triggered, the activity is terminated", typically a timeout. A non-interrupting timer leaves the activity running and is typically a notification.

The case supports both drawings. REQ-014 criterion 2: if no decision is recorded within 48 hours, "the case is assigned under REQ-015". REQ-015 criterion 1 sends it "to a named individual on the duty rota". Neither says what happens to the first agent. Interrupting, their task is cancelled and only the duty owner decides. Non-interrupting, two people can decide the same case, and the second decision has to be blocked somewhere else.

I would draw it interrupting [MINE], because criterion 1 forbids shared ownership ("Assignment to a shared mailbox, a group or a queue does not satisfy this criterion"), and two live decision-makers on one case is shared ownership in another form. The answer belongs to the Head of Customer Care, who holds the decision window in the stakeholder map. The notation did not make the decision. It made it visible, which an arrow labelled "escalate" never does.

What fires when the escalated deadline passes?

Nothing. This is the largest finding here.

REQ-015 criterion 2 writes a due date to the escalated case: "the earlier of five working days from submission (BR-07) or 24 hours from assignment." In BPMN that is a timer, or two boundary timers where the first to fire wins. Either way a timer needs an outgoing sequence flow.

The case gives it none. Section 3.3 ends the escalated branch with "Still an exception path. It just has a name and a deadline on it." The deadline is written to the case and told to the customer, and no requirement, rule or open question says what happens when the named owner misses it. BR-12 covers a case that misses its decision window, not one that misses the second.

A box can carry the label "due date" with nothing leaving it. An empty boundary event on the edge of a task asks the question on its own. The answer belongs to whoever owns BR-07, still open as OQ-02, and the likely shapes are a second escalation upward or a message telling the customer the date was missed and what happens next.

Which calendar does the timer count in?

The Camunda timer page defines three kinds: a date, a duration and a cycle. A duration is written in ISO 8601, and nothing on the page counts one in working days. "PT48H" is 48 clock hours. "Five working days" depends on a calendar that lives outside the diagram.

The case met this from the other side. Section 3.5: "A form submitted at 23:50 on Friday is due at 23:50 on Sunday." OQ-04's fallback is that "the window becomes two working days". Through the notation, that fallback adds a business calendar to the timer, and someone has to own it: which days count, which holidays, which time zone the form timestamp is read in.

Where does the case actually end?

The to-be in section 3.3 stops at "Refund issued, same working day". In BPMN that is an end event, and the Camunda page on end events says: "When a none end event is entered, the current execution path ends. If the process instance or subprocess has no more active execution paths, it is completed."

Then REQ-017 lets the goods-in lead "reopen the case within five working days of receipt". A completed instance cannot be reopened, so the case has to pick one of two shapes.

The data model piece reached the same gap as U5, "What closes a case?", because REQ-016 deletes photographs "90 days after the case closes" and nothing names the closing event. In BPMN the end event has to be drawn somewhere, and wherever it lands decides when that retention clock starts.

Which check runs on the drawing alone?

REQ-018, criterion 2: "It cannot refuse. Anything it does not approve is passed to a person, together with the reason it stopped."

Put the pre-check in its own System lane and follow every sequence flow out of it. Each must end in the payout or in a human task in the Customer Care lane. A path from the System lane to an end event labelled "refused" that passes no human task breaks REQ-018, and anyone can see it without reading the register. A day 15 claim under BR-04 is the obvious test case: the pre-check cannot approve it, so it must leave through the same human task.

The exception path card, filled in

One card per wait. This is W4, filled from the case's own lines.

The "what happens if nothing fires" row does the work. Every other row restates the register. That one is empty in the register, and the card will not let it stay empty silently.

The exception path card, blank

Where does this method stop?

It tells you what can move a case, not how often a case waits or for how long, which the case logs as OQ-06 and no drawing answers from outside. It also stops at judgement: the agent deciding whether evidence is "enough" (3.1, row 5) and the inspection at the goods-in dock (OBS-08) are tasks with no written test, and a BPMN box hides that as well as a plain one.

Timer behaviour is quoted from one engine's documentation. Check your own tool before writing interrupting or non-interrupting into a requirement.

The steps of both models are checked against each other in gap analysis between two process models. The full case is at /case, the process template with its exception blocks at /templates/process-as-is-to-be, and the tags on the method page. Checks 03, 09 and 12 of the scorecard are the ones an exception path card leans on.

All field notes · The portfolio guide · More in The Case File