luvv to helpDiscover the Best Free Online Tools
Topic 6 of 12

Happy Path And Exceptions

Learn Happy Path And Exceptions for free with explanations, exercises, and a quick test (for Business Analyst).

Published: December 20, 2025 | Updated: December 20, 2025

Table of Contents

Why this matters

As a Business Analyst, you must show how a process works when everything goes right (the happy path) and what happens when it doesn’t (exceptions). Stakeholders use this to estimate effort, design controls, plan SLAs, and prevent costly rework. Developers and QA rely on your exception flows to build validation, retries, and alerts.

  • Clarify scope: What the process guarantees vs what it handles as errors.
  • Align expectations: Who acts when things fail, and within what time.
  • Reduce incidents: Known exceptions get clear handling paths.

Note on progress: The quick test is available to everyone. Only logged-in users will have their progress saved.

Concept explained simply

Happy path = the most common, successful sequence from Start to desired End without any detours.
Exception = a deviation caused by an error, missing/invalid data, timeouts, rejections, or system failures that needs a different handling path.

Mental model

Picture a river flowing downstream (happy path). Rocks and dams represent issues. Some rocks divert the water briefly before returning to the river (alternate paths). Some dams route water into a safety channel (exceptions) to prevent flooding the main course.

Cheat sheet β€” When to use what
  • Exclusive Gateway (XOR): Data-based decision (Approved? yes/no).
  • Event-Based Gateway: Waiting for one of several events (receive message vs timer fires).
  • Boundary Event on a Task: The task may fail or be interrupted (error, timer, message). Solid border = interrupting. Dashed = non-interrupting.
  • Error Event: Something failed; often thrown by a called activity and caught by an error boundary on the caller.
  • Escalation Event: Raise attention without treating it as a full failure; can be handled elsewhere.
  • Timer Event: Deadlines, SLAs, reminders, timeouts.
  • Event Sub-Process: A process-wide interrupt (e.g., cancellation) that can start from an event within a subprocess or pool.
  • Default Flow: Mark the normal branch when conditions are mutually exclusive.

BPMN specifics you’ll use

  • Name your happy path clearly; label gateways with question-style names and flows with short conditions (e.g., Yes/No).
  • Place exception handling close to where it can occur: attach boundary events to the risky task.
  • Use non-interrupting boundary events for alerts or side-actions that shouldn’t stop the task.
  • Use interrupting boundary events when the task must stop (e.g., timeout that cancels work).
  • Prefer data-based gateways for business rules; prefer event-based gateways when truly waiting on external events.
  • For cross-team notifications, show pools/lanes and message flows (conceptually). If you cannot draw pools, annotate the sending/receiving tasks.

Worked examples

1) Online Refund Request

Happy path:

  • Start β†’ Receive request β†’ Validate receipt β†’ Approve refund β†’ Issue refund β†’ Send confirmation β†’ End

Exceptions:

  • Missing receipt: After Validate receipt, XOR gateway: valid? No β†’ Request documents β†’ Wait for upload (event-based gateway: message or 7-day timer). If message first β†’ re-validate; if timer first β†’ Auto-cancel β†’ End.
  • Fraud signal: On Approve refund task, attach interrupting error boundary β†’ Escalate to Risk Review β†’ Decision (Approve? yes β†’ Issue refund; no β†’ Reject and notify).
  • Email failure: On Send confirmation, attach non-interrupting message/error boundary β†’ Log issue and trigger retry workflow without blocking refund completion.

2) New Employee Onboarding

Happy path:

  • Start β†’ Collect documents β†’ Create accounts β†’ Schedule orientation β†’ Complete onboarding β†’ End

Exceptions:

  • Background check fail: After Collect documents, XOR: Pass? No β†’ Notify candidate β†’ End.
  • Document timeout: On Collect documents, interrupting timer boundary after 5 business days β†’ Auto-close request β†’ End.
  • Orientation date change: On Schedule orientation, non-interrupting message boundary for reschedule request β†’ Start reschedule sub-process β†’ Return to Schedule orientation without canceling current task.

3) Payment Processing

Happy path:

  • Start β†’ Authorize card β†’ Capture payment β†’ Send receipt β†’ End

Exceptions:

  • Card declined: After Authorize card, XOR: Approved? No β†’ Notify customer β†’ Offer new card path.
  • Gateway timeout: On Authorize card, interrupting timer boundary β†’ Retry up to 2 times β†’ If still failing β†’ Fail payment β†’ Notify.
  • Post-shipment refund: After Capture payment and Ship order (in a transaction), model compensation to reverse charges when a return is processed.
Why these patterns?
  • We use XOR for business rule decisions (e.g., valid/invalid).
  • We use boundary events when an activity can be interrupted by timeouts or errors.
  • We keep happy path visually straight; exceptions branch off and rejoin when possible.

How to model happy path and exceptions (step-by-step)

  1. Write the outcome: What is the successful end state?
  2. List the minimum successful steps: Only what’s essential to reach the outcome.
  3. Identify risk points: Where can data be invalid, approvals fail, or timeouts occur?
  4. Pick exception handlers: Boundary event vs gateway; interrupting vs non-interrupting; event sub-process if global.
  5. Label clearly: Gateways as questions; flows with short conditions; events with meaningful names.
  6. Rejoin if possible: After handling, return to the happy path to avoid duplication.
  7. Test with scenarios: Walk through normal and edge cases; confirm owners and SLAs.
Event choice helper
  • Business rule outcome β†’ XOR gateway.
  • Waiting for one of many external triggers β†’ Event-based gateway.
  • Task may time out or fail β†’ Boundary event on that task.
  • Whole process interruption (e.g., customer cancels) β†’ Event sub-process.

Exercises you can do now

Do these in your notes or a whiteboard. Compare with the solutions below.

Exercise 1 β€” Mark the happy path and exceptions

Narrative: A customer submits a warranty claim. The agent validates the serial number and proof of purchase. If both are valid, the agent approves and issues a replacement. If the serial number is invalid, the agent rejects. If proof of purchase is missing, the customer has 10 days to upload. If nothing arrives in time, the claim auto-closes. If the system that checks serial numbers is down, the agent should log the incident and retry later without losing the claim.

  • Identify the happy path steps.
  • List each exception, and propose the BPMN element to handle it.
Show solution for Exercise 1

Happy path: Start β†’ Receive claim β†’ Validate serial number β†’ Validate proof of purchase β†’ Approve β†’ Issue replacement β†’ End

Exceptions:

  • Invalid serial β†’ XOR after Validate serial: valid? No β†’ Reject β†’ End.
  • Missing proof β†’ XOR after Validate proof: present? No β†’ Request upload β†’ Event-based gateway (Message from customer vs 10-day Timer). Message β†’ back to Validate proof; Timer β†’ Auto-close β†’ End.
  • Serial system down β†’ non-interrupting error/message boundary on Validate serial β†’ Log incident and create retry sub-process while keeping the claim active. If you truly must stop the task, use an interrupting boundary and a Retry loop.

Exercise 2 β€” Draft a text BPMN

Write a text-based model for a simple leave request:

  • Employee submits request β†’ Manager reviews β†’ If approved, HR records leave β†’ Notify employee β†’ End.
  • Exceptions: Manager doesn’t respond in 3 days (auto-escalate to Manager’s manager). Employee cancels request at any time before decision.
Show solution for Exercise 2

Start β†’ Submit request β†’ Review by Manager (task with two boundary events):

  • Interrupting timer boundary (3 days) β†’ Escalate to Manager’s manager β†’ Review (decision).
  • Interrupting message boundary (Employee cancel) β†’ Cancel request β†’ Notify employee β†’ End.

On normal flow: XOR after Review: Approved? Yes β†’ HR records leave β†’ Notify employee β†’ End; No β†’ Notify employee β†’ End.

Common mistakes and self-check

  • Mistake: Modeling business rule outcomes with event-based gateways. Fix: Use XOR for data decisions; event-based only when waiting on external triggers.
  • Mistake: Long spaghetti exception lines crossing the diagram. Fix: Place boundary events close to tasks, use subprocesses for complexity, and rejoin where possible.
  • Mistake: Unlabeled flows. Fix: Always label conditions (Yes/No, Valid/Invalid).
  • Mistake: Using interrupting events for notifications. Fix: Use non-interrupting boundary events when the main work should continue.
  • Mistake: Handling the same exception in multiple places. Fix: Centralize via an event sub-process if it’s global.
Self-check mini list
  • Is the happy path a straight, readable line from Start to End?
  • Does every exception name an owner and an outcome?
  • Are gateways questions and flows conditions?
  • Do timers reflect agreed SLAs?
  • Can you simulate two or three exception scenarios end-to-end without ambiguity?

Practical projects

  • Audit one real process in your team. Produce a one-page BPMN: straight happy path, max three exception handlers.
  • Create an exception catalog: For each exception, record trigger, handler, owner, SLA, and outcome.
  • Run a tabletop simulation: Read sample inputs aloud and walk the model until an End event, noting any unclear steps.

Who this is for

  • Aspiring and practicing Business Analysts who need clear, testable process models.
  • Product owners and QA who translate flows into acceptance criteria and test scenarios.

Prerequisites

  • Basic BPMN familiarity (tasks, gateways, start/end events).
  • Understanding of your domain’s key data fields and common failure modes.

Learning path

  1. Map the happy path only for one process.
  2. Add top 2–3 exceptions using boundary events and XOR gateways.
  3. Introduce timers and event-based gateways where external triggers matter.
  4. Refactor with subprocesses if the diagram gets crowded.
  5. Validate with stakeholders via scenario walkthroughs.

Next steps

  • Apply these patterns to another process with different exception types (timer, error, escalation).
  • Convert exceptions into user stories and test cases (Given-When-Then).
  • Take the quick test below to check your understanding.

Mini challenge

Process: Supplier invoice processing. Happy path: Receive invoice β†’ 3-way match β†’ Approve β†’ Pay β†’ Send remittance. Add at least three exceptions with handlers: missing PO, mismatch in quantities, duplicate invoice, and payment run cutoff time.

Tip to start
  • Use XOR after 3-way match (Match? Yes/No).
  • Attach timer boundary to Pay for cutoff time handling.
  • For duplicates, use error boundary on Receive invoice β†’ route to investigation.

Practice Exercises

2 exercises to complete

Instructions

Read the narrative and identify:

  • The minimal happy path steps.
  • Each exception, with a proposed BPMN element (gateway, boundary event type, interrupting vs non-interrupting).

Narrative: A customer submits a warranty claim. The agent validates the serial number and proof of purchase. If both are valid, the agent approves and issues a replacement. If the serial number is invalid, the agent rejects. If proof of purchase is missing, the customer has 10 days to upload. If nothing arrives in time, the claim auto-closes. If the system that checks serial numbers is down, the agent should log the incident and retry later without losing the claim.

Expected Output
A short list of happy path steps plus an exceptions table with BPMN element choices and whether each is interrupting or non-interrupting.

Happy Path And Exceptions β€” Quick Test

Test your knowledge with 8 questions. Pass with 70% or higher.

8 questions70% to pass
Swimlanes Pools And LanesIdentifying Bottlenecks

Have questions about Happy Path And Exceptions?

AI Assistant

Ask questions about this tool