Error Event

An error event is a circle with a lightning-bolt marker. It represents an exception — something that went wrong inside a process. Error events come in thrower and catcher variants: a *throwing* error event (solid fill) raises the error, and a *catching* error event (empty fill) handles it somewhere else in the diagram.

The most common placement is a catching error event on the boundary of a sub-process. The sub-process runs normally; if anything inside it throws an error, the token is interrupted, routed out through the boundary event, and continues along a dedicated error-handling path. This is BPMN’s equivalent of try/catch in code — the happy path stays clean, the error path is explicit and visible.

1. Catch on boundary: sub-process "Process payment" with an error boundary event labelled "Payment declined" → routes to "Notify customer".
2. Throw at end: inside a sub-process, an activity reaches an impossible state → error end event. The boundary event on the parent catches it.
3. Catch in an event sub-process: a dedicated invisible sub-process that activates only when a matching error fires anywhere in the parent. Use this when multiple activities can throw the same error.
4. Re-throw: catch an error, run a compensation step, then throw a higher-level error from the handler. This is how you escalate.

When the source document describes failure paths ("if the credit check fails", "if the vendor rejects the PO", "if the system times out"), LucidFlow emits error events rather than flattening the failure into a generic conditional branch. That difference matters for the cost dashboard: error paths are typically much rarer than happy paths, and their per-execution cost blows up when you divide by the low frequency. Modelling errors explicitly lets the heatmap show "this rare path costs us disproportionately" — which is often where the fastest automation wins live.