BPMN & Business Process Analysis

BPMN Events

18 min Lesson 3 of 10

BPMN Events

In any business process, things happen: a customer submits a form, a deadline passes, a payment fails, an approval arrives. BPMN captures all of these occurrences with a single construct called an event. Understanding events is the key to drawing process models that reflect reality rather than an idealised, exception-free fantasy.

This lesson covers the three positional categories — start, intermediate, and end events — and then digs into the two trigger types you will use most often in practice: message events and timer events. By the end you will be able to read and draw a realistic process flow that includes both normal and exception paths driven by external messages and time constraints.

The Three Positional Categories

BPMN events are represented as circles. Their border thickness immediately tells you where in the flow the event sits:

Start event — a single thin-bordered circle. It marks where a process or sub-process begins. Every process must have at least one.
Intermediate event — a circle with a double border (two concentric rings, both thin). It marks something that happens during the flow — either catching a trigger or throwing a signal to another part of the process.
End event — a single thick-bordered circle. It marks where the process or branch terminates. A process can have multiple end events for different outcome paths.

Inside each circle, a small icon (or no icon at all) indicates the event's trigger type. An empty circle means a none event — the process simply starts, reaches that point, or ends without a specific trigger. A filled envelope icon means a message; a clock icon means a timer; and so on for a dozen other types defined by the BPMN 2.0 specification.

BPMN event symbols. Border thickness identifies position (start / intermediate / end); the inner icon identifies the trigger type (none, message, timer, and more).

Message Events

A message event represents the receipt or sending of a communication between two participants — two pools, or a pool and an external entity. The icon is an envelope.

A message start event fires when the process receives an incoming message. Example: a customer submits an online insurance claim form — the submission arrives as a message that starts the claims-processing process.
A message intermediate catching event pauses the flow until an expected message arrives. Example: after forwarding an order to a supplier, the logistics team waits to receive a dispatch notification before updating the delivery schedule.
A message end event (filled envelope, thick border) sends a message as the process terminates. Example: when an approval process ends, a confirmation email is sent to the applicant.

Catching vs. throwing: In BPMN, catching means the event waits for something to arrive (hollow icon). Throwing means the event sends something out (filled icon). Start events are always catching; end events are always throwing; intermediate events can be either.

Timer Events

A timer event represents a time-based trigger. The icon is a clock face.

A timer start event fires at a specific date/time or on a recurring schedule. Example: a payroll process that runs every two weeks, or a report that generates at midnight on the last day of the month.
A timer intermediate catching event pauses the flow for a fixed duration or until a deadline. Example: after sending a payment reminder, the accounts-receivable process waits 7 days before escalating. If payment is received within those 7 days, the timer is cancelled and the process continues normally.
Timer events do not have an end-event variant — you cannot end by throwing a timer. They are purely catching events.

Intermediate timer on the boundary: When you place a timer intermediate event on the boundary of a task (attached to its edge rather than in the sequence flow), it becomes a boundary event. It interrupts or non-interruptingly handles a timeout. You will model this explicitly in Lesson 7 (As-Is modeling). For now, keep it on the sequence flow as a standalone catching event.

A Worked Example: Clinic Appointment Reminder Flow

Consider a clinic that confirms appointments by email and escalates to a phone call if the patient does not respond within 48 hours. The process has three actors: the system, the reception team, and the patient (modeled as an external message source). Here is how the events appear in the flow:

A timer start event fires 48 hours before the scheduled appointment.
The system sends a confirmation email. A message intermediate throwing event represents the outgoing email.
A timer intermediate catching event (24-hour wait) pauses the flow.
An exclusive gateway checks: has the patient confirmed?
- If yes: a message intermediate catching event captured the patient reply. The process ends with a none end event (appointment confirmed).
- If no: reception calls the patient. The call result is captured, and the process ends with either a confirmed or cancelled end event.

Clinic appointment reminder: a timer start event fires 48 hours before the appointment; a message intermediate event captures the patient reply; a timer intermediate event enforces a 24-hour wait; and escalation to a phone call uses a second lane with two outcome end events.

Reading the Flow — What Each Event Tells You

Walk through the diagram above with an analyst's eye:

The timer start event (clock icon, thin border) tells any reader: this process does not begin because a person presses a button — it fires automatically on a schedule.
The timer intermediate catching event after the email task means: the process literally pauses here. Nothing happens until either 24 hours elapse or the patient responds — whichever comes first (the gateway checks the result).
The message intermediate catching event on the "Yes" branch captures the inbound patient confirmation. It is on the sequence flow here, meaning the "Yes" path was taken because the message arrived before the 24-hour timer expired.
The two end events have different visual treatments: the green thick-border end is a "none" end (the process simply terminates with a confirmed appointment); the red thick-border end with an X mark could be drawn as an error or terminate end to signal an abnormal termination — in this simplified diagram it represents the cancellation outcome.

Common mistake — misplacing event position: A double-bordered intermediate event placed at the very start or very end of a flow is a modeling error. Start events always have a single thin border; end events always have a single thick border. If your intermediate event is at position zero or position last, you have the wrong event type.

Other Event Types You Will Encounter

The BPMN 2.0 specification defines additional event triggers you should be able to recognise, even if you do not model all of them from day one:

Error event — a lightning-bolt icon, always an end or boundary catch. Represents a fault condition that terminates a sub-process and routes to an exception handler.
Signal event — a triangle icon. Unlike a message (point-to-point between two specific pools), a signal is a broadcast — any process that is listening can catch it.
Conditional event — a lined-page icon. Fires when a business condition becomes true (e.g., stock falls below reorder level).
Escalation event — an upward arrow icon. Used inside sub-processes to escalate a case to a higher-level handler without terminating the sub-process.
Terminate end event — a filled thick-border circle. Immediately kills all active tokens in the process, not just one branch. Use sparingly and deliberately.

Scope for this tutorial: Lessons 3 through 8 focus on the core notation: none, message, and timer events. Error and terminate events appear in the worked examples later. You do not need to memorise every BPMN event type — you need to know the core set fluently and be able to look up the rest when a specific business rule demands them.

Practical Guidelines for Modeling Events

Start with the trigger. Before drawing anything, ask: what causes this process to begin? A human action? An incoming message? A schedule? Your answer determines whether the start event is none, message, or timer.
Name your events. A named event — "Order Received", "48-Hour Timer Expired", "Approval Email Arrives" — communicates far more than an unlabelled circle. Treat event labels as business-language statements of what happened.
Use intermediate events to model waiting. When a process genuinely pauses — waiting for an approval, waiting for a payment, waiting for a scheduled window — an intermediate catching event makes that pause visible and measurable. If you draw a task called "Wait for Payment", replace it with a message intermediate catching event; the event is semantically richer and formally correct.
Match end events to outcomes. Each distinct business outcome (confirmed, rejected, escalated, cancelled) deserves its own end event with a meaningful label. This makes the process readable as a set of possible outcomes, which is exactly what stakeholders and testers need to see.

Summary

BPMN events are the trigger layer of a business process — the points where the real world reaches into the model and says: start now, wait for this, or you are done. Mastering their three categories (start, intermediate, end) and the two most common trigger types (message, timer) gives you the vocabulary to model every realistic flow you will encounter as a business analyst: scheduled processes, message-driven workflows, waiting states, escalation paths, and multiple outcome endings. Everything you learned in this lesson feeds directly into the pool-and-lane collaboration diagrams coming in Lesson 6 and the As-Is / To-Be modeling projects in Lessons 7 and 8.