End Event
The circle with a bold border that marks where a process (or one of its paths) finishes.
What an end event means
An end event is a circle with a bold single-line border that marks a conclusion of a process path. When a token reaches an end event, it is consumed and the path finishes. A process instance as a whole finishes when all its active tokens have reached end events (or when a `terminate` end event fires, which stops everything immediately).
BPMN 2.0 allows several end-event types, chosen by the marker inside the circle. A *plain* end event finishes the path. A *message* end event sends a message as it finishes. A *signal* end event broadcasts a signal that other parts of the process (or other processes) can catch. A *terminate* end event ends every active token in the process, not just its own. Use it for abort semantics. An *error* end event throws an error that a surrounding sub-process can catch with a boundary event.
Why a process often has more than one end event
- Different outcomes deserve different labels: "Order shipped" vs "Order rejected" vs "Customer cancelled". Three end events read clearly.
- Different outcomes have different downstream effects: one sends a message, one broadcasts a signal, one just quietly finishes.
- Modelling a single end event and routing everything into it forces you to invent a generic label ("Process ended") that hides the very information a reader needs.
End events in LucidFlow
LucidFlow emits one end event per outcome it detects in the source document. "Approved and shipped" and "Rejected, customer notified" become two separate end events, each with a clear label. The bottleneck heatmap colours the sequence flows leading to each end event by cumulative cost and duration, so you can see at a glance which outcomes are expensive to reach and which are quick.
Frequently asked questions
Can a process have zero end events?
Not legally. A valid BPMN 2.0 process must have at least one end event. A diagram with dangling activities and no end events is syntactically invalid.
What happens if two tokens reach different end events in parallel paths?
Each token is consumed at its end event. The process instance as a whole ends when all tokens are gone, whether they all reached the same end event or different ones.
Does the end event have to be on the right side of the diagram?
No. Left-to-right is convention, not spec. The important thing is that the reader can follow the flow. For processes with multiple outcomes it is often clearer to fan the end events downward or upward, not squeeze them all to the right margin.