BPMN events
Circles, and the two things about a circle that carry all the meaning: how heavy its border is, and what is drawn inside it. Once those two are separate ideas in your head, the whole event catalogue collapses to a grid.
8 min readBPMN 2.02 of 3
01Border weight, then glyph
Every BPMN event answers two questions independently, and reading them separately is the whole trick:
| Element | Notation | What it means |
|---|---|---|
| Start event | thin single border | Where a process instance begins. Nothing may flow into it. A process may have more than one, and each is a separate way in. |
| Intermediate event | double border | Something that happens during the process - either waited for, or raised. Sits in a sequence flow, or on the boundary of an activity. |
| End event | thick single border | Where this path finishes. Nothing may flow out of it. Reaching one ends that token, not necessarily the whole process. |
| Interior glyph | envelope, clock, bolt | Which kind of thing happened. Empty means "none" - unspecified, and perfectly respectable on a descriptive model. |
02The event types worth knowing
| Element | Notation | What it means |
|---|---|---|
| None | empty circle | Unspecified. The right choice on a descriptive model where "the process starts" is all anyone needs. |
| Message | envelope | Something arrived from, or is sent to, another participant. Always paired with a message flow crossing a pool boundary. |
| Timer | clock | A date, a duration, or a cycle. As a start event it is the schedule; on a boundary it is a deadline. |
| Error | lightning bolt | A named failure. Thrown by an end event inside a sub-process, caught by a boundary event on it. This is BPMN's try/catch. |
| Signal | triangle | A broadcast. Unlike a message it has no specific recipient - everybody listening reacts. |
| Conditional | lined page | Fires when a condition on the data becomes true, not when a step ends. |
| Escalation | upward arrow | Like an error, but the activity carries on. "Tell someone senior and keep going." |
| Terminate | filled circle | End event that kills every token in the process instance, not just its own. The one end event with teeth. |
Eight of thirteen. Compensation, cancel, link and multiple exist and are rare enough to look up when you meet them.
03Boundary events, or: everything that goes wrong
A boundary event is an intermediate event drawn on the edge of an activity, and it is the most useful construct in BPMN. It says: while this task is running, this other thing might happen, and if it does, leave here instead.
Timeouts, cancellations, errors, a customer phoning to change their order - all of them are a boundary event, and all of them would otherwise need a gateway and a second path that the reader has to mentally interleave with the first.
| Element | Notation | What it means |
|---|---|---|
| Interrupting | solid double border | The activity is cancelled and the token leaves by the boundary. A timeout, an error, a cancellation. |
| Non-interrupting | dashed double border | The activity carries on and a second token starts down the boundary path. An escalation, a status enquiry, a reminder. |
04Start and end events in practice
A process with several start events has several genuinely separate ways in - a claim arriving by post, by app, and by phone. That is usually clearer than one start event followed by a gateway asking how it arrived, because the gateway implies the channel is a decision the process makes, when it is a fact the process is handed.
End events are the reverse: several are usually right, because the name of the end event is the outcome. "Claim settled" and "Claim rejected" as two end events tell you more than one "End" with a gateway in front of it. Process reporting later counts exactly these, so naming them well pays twice.
Reach for it when
- Several start events when there are genuinely several triggers
- Several end events, each named for the outcome it represents
- A terminate end event when one path failing must stop everything
- Boundary events for every exception you can name
Reach for something else when
- An empty 'End' after a gateway that already decided the outcome
- An intermediate none event used as a milestone marker - use a text annotation
- A message start event with no message flow drawn into it
- Boundary events on a task that cannot plausibly be interrupted
05Common mistakes
- Sequence flow out of an end event. Nothing follows an end event. Ever. If something does, it was an intermediate event.
- A message event with no message flow. The glyph claims another participant exists; draw the pool and the flow, or use a none event.
- Throwing and catching confused. Hollow waits, filled sends. Getting it backwards inverts the direction of the whole conversation.
- Timer events used as delays that are really queues."Wait 2 days" usually means "this sits in somebody's inbox". Model the task and put the timer on its boundary.
- One end event for everything. The outcomes disappear, and so does the reporting.
Events pair naturally with gateways: an event-based gateway is precisely a race between several catching events, and it is the construct that makes "whichever comes first" expressible.
In one line each
- 01Border weight says when - thin starts, double happens during, thick ends.
- 02Interior glyph says what kind; empty is a legitimate answer.
- 03Hollow glyphs catch, filled glyphs throw.
- 04A boundary event is how BPMN says "and if this goes wrong".
- 05Interrupting cancels the activity; non-interrupting runs beside it.
- 06Name end events after outcomes - they become your process reporting.
Related reading