Lesson 2 of 3
What is the happy path?
The happy path is what happens when everything works correctly — no errors, no missing information, no escalations, no SLA breaches. It is the primary flow through the process and the most common sequence of events.
An exception path is what happens when something deviates from the happy path — a decision routes differently, a piece of information is missing, a system fails, a time limit is breached, or a request is rejected.
Why model the happy path first?
Beginners attempt to model everything simultaneously — the main flow, the exceptions, the edge cases — and produce unreadable diagrams with intersecting arrows and unclear logic. Drawing the happy path first gives you a clean structural spine to attach exceptions to.
Practical build sequence
1. Draw the happy path from trigger to primary outcome. Get it clean and readable. 2. Identify each point where something could go differently. 3. Add one exception at a time, using a Gateway to branch off the main flow. 4. Bring each exception branch either back to the main flow or to its own End Event. 5. Only when all exceptions are added, review overall readability.
Invoice approval: happy path first
| Stage | What to build | What to add next |
|---|---|---|
| Step 1 | Invoice received → Review Invoice → Approve Invoice → Process Payment → Invoice Paid | Nothing yet — get the happy path right first |
| Step 2 | Add first exception | Gateway after 'Review Invoice': does it match the PO? No → 'Resolve Discrepancy' branch |
| Step 3 | Add second exception | Gateway: does amount exceed limit? Yes → 'Escalate to Finance Manager' branch |
| Step 4 | Add rejection path | Finance Manager rejects → 'Notify Supplier' → Invoice Rejected End Event |
Common mistake
Modelling the rejection path before the approval path. This leads to diagrams that are technically accurate but feel backwards to read, because the primary outcome — approval and payment — is buried at the end or in a branch that feels secondary.
The structural benefit
A diagram built happy-path-first has a clear horizontal spine that stakeholders can follow from left to right. Exceptions hang off the spine as branches. This layout is significantly easier to review in stakeholder workshops because participants can track the main flow and then discuss each branch in isolation.
✓ When to use
- Every new diagram — always start with the happy path
- Stakeholder walkthroughs — 'let me show you what happens when everything goes smoothly first'
- As a readability test — if the happy path is not obvious in the finished diagram, the layout needs work
✗ When not to use
- ✕Don't delay modelling exceptions indefinitely — they are where most requirements live
- ✕Don't collapse exceptions into single tasks like 'Handle Errors' — each deserves its own branch