Boundary Event
An event attached to the edge of an activity that interrupts it or spawns a parallel reaction when something happens during the work.
What a boundary event does
A boundary event sits on the edge of an activity (a task or sub-process) and fires only while that activity is running. It is BPMN’s way of modelling "what if something happens during this step": a customer cancels mid-call, a timer expires, a downstream system throws an error, an escalation is raised.
Boundary events come in two flavours. An *interrupting* boundary event (solid circle) stops the host activity the moment it fires and routes the token out through its outgoing sequence flow. A *non-interrupting* boundary event (dashed circle) lets the original activity continue while also spawning a parallel path, useful for "send a nudge after ten minutes but let the user keep working".
The boundary events you will actually use
- `Timer`: "if this task runs longer than X, cancel/escalate". The single most common boundary event in real processes.
- `Error`: catch an error thrown inside the activity and route it to a handler (retry, compensate, notify).
- `Message`: react to an external signal while the activity is running ("customer emailed to cancel mid-shipment").
- `Escalation`: notify a manager without cancelling the work ("this approval has been pending three days").
- `Cancel` and `Compensate`: reserved for transactions, rarely used in simple BPMN.
Boundary events in LucidFlow
LucidFlow recognises boundary events when the source document describes timeouts, error handling, or escalations ("if the manager does not respond within 48 hours, escalate to their director"). In the target BPMN (the AI-transformed process), boundary events are often where AI agents get attached: a non-interrupting timer that fires a Copilot assistant to nudge the owner, or an interrupting error event that routes to a retry-automation.
Frequently asked questions
What is the difference between an interrupting and non-interrupting boundary event?
An interrupting boundary event (solid circle) cancels the host activity when it fires. A non-interrupting one (dashed circle) leaves the activity running and spawns a parallel path. Use non-interrupting for nudges and reminders; use interrupting for timeouts and real errors.
Can a boundary event have its own boundary event?
No. Boundary events attach to activities only. If you need nested "what-ifs", model the outer handling as its own sub-process and attach new boundary events to that sub-process.
Where does the token go after a boundary event fires?
Out through its own outgoing sequence flow, which is drawn from the boundary event, not from the host activity. The outgoing flow of the host activity only fires if the activity completes normally.