#End a process
Reaching any end event finishes the whole instance at once, and every kind of end event behaves like a plain one.
#What an end event does
flowchart LR
S(("Start")) --> G{{"Inclusive gateway"}}
G --> A["Send invoice"] --> E1(("End"))
G --> B["Review by finance<br/>(still open)"] --> E2(("End"))
E1 -. "reached first" .-> C["Instance finished<br/>'Review by finance' stays in My tasks,<br/>but can no longer continue"]
The first time any path reaches an end event, the instance is finished. It does not wait for other paths that are still running.
⚠️ Steps still open on other paths are not withdrawn. A user task on such a path stays in its assignee's My tasks, but completing it does not bring the instance back — it is over. No gateway waits for paths to come back together, so work that has to finish before the process ends is better modelled as one multi-instance activity than as paths side by side.
Inside a sub-process or a process started by a call activity, an end event finishes only that inner part. The parent process then continues with the next step.
An end event produces no data.
#The kinds of end event
| End event | Status | What happens |
|---|---|---|
| Plain end event | ✅ | Finishes the instance |
| Terminate end event | ⚠️ | Finishes the instance — exactly like a plain one. Open steps on other paths are not withdrawn |
| Error end event | ⚠️ | Finishes normally. No error is thrown: an error boundary event on the calling step does not fire |
| Message end event | ⚠️ | Finishes normally. No message is sent |
| Signal end event | ⚠️ | Finishes normally. No signal is broadcast |
| Escalation, cancel and compensation end events | ⚠️ | Finish normally, and do nothing else |
To send a message or a signal at the end of a process, put a message throw event or a signal throw event before a plain end event. See Process elements.
⚠️ When you change an end event's type, the menu describes the variants as they are meant in BPMN — "Terminates the whole process", "Ends with an error", "Ends and sends a message". Chester does not do any of that; the table above is what happens.
#Configure an end event
An end event has only General — its name and id — and Documentation. Error, message, signal, escalation and compensation end events also show a group for their reference or code. Nothing entered there is used when the process runs.
#What validation checks
- A process without an end event gets a warning.
- An end event with an outgoing flow gets a warning.
- A path that never reaches an end event gets a warning.
- An element other than an end event that has no outgoing flow is an error — at runtime the instance would fail there.
The messages are shown in German. See Check that a process can run.