WORKED CASE

One workshop, three useful views

See how prose, a process view, and a decision table answer different questions.

The facts stay the same

  • The workshop has 12 places.
  • A registration is confirmed only if a place is available and an email address is supplied.
  • A duplicate submission for an existing confirmed registration does not consume another place.
  • When no place is available, a valid new registration goes to the waitlist.

One workshop, three useful views

ONE CASE · DIFFERENT QUESTIONS

Open case →

Follow the registration steps

First check whether this person already has a confirmed registration. If so, return the existing confirmation. Otherwise require an email address, then check remaining places. Confirm when a place is available; add to the waitlist when the workshop is full.

1. Check for an existing confirmation.
2. If it exists, return it without reserving a place.
3. For a new registration, require an email address.
4. If a place is available, confirm and reserve one place.
5. Otherwise, add the new registration to the waitlist.

Makes visible: Action order and conditions.
Leaves out: A paragraph makes overlapping cases harder to compare than a table.

Inspect the decision order

The duplicate check precedes validation and allocation for a new registration. This is an authored flow illustration, not a complete BPMN model.

Existing confirmation? to New: email supplied? to Place available?Existing confirmation?. No: evaluate new request: New: email supplied?. Yes: evaluate capacity: Place available?Existing confirmation?No: evaluate new requestNew: email supplied?Yes: evaluate capacityPlace available?

Existing confirmation? · No: evaluate new request → New: email supplied? · Yes: evaluate capacity → Place available?

Makes visible: The order in which questions are considered.
Leaves out: The flow does not define every possible validation failure or operational retry.

Compare the cases

Read from the first row down. This teaching table uses first-match behavior. A real DMN table needs its hit policy declared explicitly.

First matching conditionOutcomePlaces consumed
Existing confirmed registrationReturn existing confirmation0
New registration, no emailAsk for email0
New, email supplied, place availableConfirm1
New, email supplied, no placeWaitlist0

Makes visible: The interaction between duplicate, email, and capacity conditions.
Leaves out: A table does not show the user interface or message delivery.

Check your understanding

A confirmed participant submits the same registration again while the workshop is full. What should happen?

Open the explained answer

Keep the existing confirmation without consuming another place. Duplicate handling is checked before the capacity rule.

These are prepared representations of a bounded example. Changing views does not generate new facts or simulate unmodeled behavior.