Cancel Boundary Event
Attached only to a Transaction Sub-Process; catches the transaction's cancellation and routes the undo path after compensation ran. Double circle with an X.
The Cancel Boundary Event completes BPMN's transaction protocol: when a Cancel End Event fires inside a transaction (or a cancel is signaled to it), the transaction stops, compensation handlers run automatically, and then the token leaves through this boundary to the post-cancellation path.
When to use and avoid
When to use
Always paired with a Transaction Sub-Process — it's the only place it can attach.
To define the business follow-up after a cancelled transaction (refund communication, release of holds).
In booking/ordering domains with all-or-nothing semantics.
When NOT to use
On ordinary activities or sub-processes — invalid outside transactions.
For failures — that is Error; cancel is a deliberate abort with compensation.
When there is nothing to do after cancellation — the transaction may simply end cancelled.
Business example
Trip booking transaction cancelled by the customer
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- The Book trip transaction reserves flight and hotel.
- The customer aborts: the Cancel End inside fires, compensation undoes the reservations.
- The Cancel Boundary (highlighted) then routes to Release reservations and refund, closing the case as cancelled.
Differences
Cancel vs Error on a transaction
Cancel is the protocolized abort: compensation runs first, then the cancel boundary path. An Error boundary on a transaction skips the compensation protocol — it's a failure, not an orderly cancellation.
FAQ
Is compensation automatic here?
Yes — that's the special semantics of transactions: on cancel, all completed inner activities with handlers are compensated before the boundary fires.
Can a cancel boundary be non-interrupting?
No. Cancellation by definition terminates the transaction; the boundary is always interrupting.