Events Tasks Gateways

Why this matters

As a Business Analyst, you turn real workflows into clear, shared understanding. BPMN is the language for that. The core building blocks—Events, Tasks, and Gateways—let you describe how a process starts, what work happens, and how decisions or parallel work unfold. Mastering these three unlocks accurate requirements, smoother stakeholder alignment, and fewer delivery reworks.

• Clarify who does what and when (handoffs, wait times, responsibilities).
• Reveal risks (missing approvals, race conditions, deadlocks).
• Align business and tech by using a standard that both sides understand.

Who this is for

• Business Analysts and Product Analysts modeling processes.
• Project Managers needing to communicate flows to teams.
• QA and Ops professionals validating edge cases.

Prerequisites

• Basic understanding of BPMN diagrams (pools/lanes, sequence vs. message flow).
• Familiarity with a BPMN-friendly tool (any diagram tool is fine).
• Access to a simple process to model (e.g., purchase request, onboarding).

Concept explained simply

Think of a process as a story with three kinds of sentences:

• Events: The punctuation. They start, interrupt, or end the story (e.g., timer starts, error stops).
• Tasks: The actions. Someone or something does work (user, system, manual).
• Gateways: The forks and joins. They split or merge paths (decision, parallel work, one-of-many waits).

Mental model

Use the WHAT → HOW → WHEN model:

• WHAT work is performed? Use Tasks (and Sub-Processes when work is grouped).
• HOW paths diverge or converge? Use Gateways to control the logic.
• WHEN something starts/stops/interrupts? Use Events (start, intermediate, end; catching vs. throwing).

Core elements you will use most

Events

• Start Events: Begin a process. Common types: None, Message, Timer.
• Intermediate Events: Happen during a process. Types: Message, Timer, Error, Escalation, Signal, Conditional. Can be catching (wait) or throwing (send/raise).
• Boundary Events: Attached to the boundary of a Task/Sub-Process to handle exceptions. Interrupting (solid) or Non-interrupting (dashed).
• End Events: Finish a path. Types: None, Message, Error, Escalation, Terminate.

Tasks

• User Task: Human in a system (e.g., approve in an app).
• Manual Task: Human outside a system (e.g., physical signature).
• Service/Script Task: Automated by a system/script.
• Send/Receive Task: Explicitly sends or waits for a message.
• Call Activity: Reuse another process; Sub-Process: group steps (expanded or collapsed).
• Loop/Multi-instance markers: Repeat work per item or until a condition.

Gateways

• Exclusive (XOR): Choose one path. Merge expects one incoming active path.
• Parallel (AND): Start paths simultaneously; merge waits for all active paths.
• Inclusive (OR): Start one or more paths based on conditions; merge waits for all active paths among those taken.
• Event-based: Next path is chosen by whichever event occurs first (e.g., customer replies vs. timeout).
• Complex: Rare; used for advanced synchronization rules.

Worked examples

How to choose the right gateway (quick checklist)

• Only one path should proceed → Exclusive (XOR).
• All paths must proceed → Parallel (AND).
• One or more paths may proceed based on conditions → Inclusive (OR).
• Path depends on whichever event arrives first → Event-based.
• Need special sync logic (rare) → Complex (document the rule clearly).

Self-check: Does your diagram make sense?

• Every path has a clear End Event (unless intentionally open-ended).
• Gateways are paired logically (split has a matching merge of the same kind where appropriate).
• Labels on flows are unambiguous and testable.
• Boundary events are attached to the correct task and type (error vs. escalation).
• No deadlocks (e.g., missing join after a parallel split).

Common mistakes and how to avoid them

• Using XOR when two checks should run in parallel → If both are required, use AND.
• Merging parallel paths with XOR → Can pass early and skip required work; use AND join.
• Forgetting default flow on XOR → Add default so the process doesn't stall.
• Using event-based gateway with tasks → It must follow intermediate catching events, not tasks.
• Missing boundary events for known errors/timeouts → Add them to the risky task.
• Unlabeled conditions → Label sequence flows with explicit conditions.

Mini tasks

• Label three flows with precise conditions (numbers or states, not adjectives).
• Convert one decision you modeled as XOR into Inclusive (OR) and note behavioral differences.
• Add a non-interrupting timer boundary to a User Task to send reminders without canceling the task.

Exercises

Do the exercise below, then compare with the solution. Use the checklist above to self-review.

• Checklist: Includes Start/End events; decision via correct gateway; non-interrupting timer boundary for reminder; error boundary for payment failure; clear labels.

Practical projects

• Customer onboarding: Map KYC checks (parallel), risk scoring (service), and conditional approvals (XOR/OR). Add timer reminders and error handling.
• Incident triage: Event-based gateway to accept whichever notification arrives first (monitor alert vs. user ticket), then parallel diagnostics and communication.
• Refunds process: Inclusive gateway for optional validations (receipt present, card present, fraud check), join correctly, then finalize or escalate error via boundary events.

Learning path

• Step 1: Sketch processes with just Tasks and sequence flows.
• Step 2: Add Events (start/end), then intermediate waits (timer/message).
• Step 3: Introduce Gateways (XOR/AND) and label conditions precisely.
• Step 4: Add boundary events for errors/timeouts; test edge cases.
• Step 5: Refactor into Sub-Processes/Call Activities for reuse.

Next steps

• Refine one of your diagrams by adding boundary events for known risks.
• Walk a stakeholder through the flow, asking "What could go wrong here?" and capture missing events.
• Take the Quick Test below to confirm understanding.

Quick Test

Available to everyone. If you are logged in, your progress is saved so you can resume later.