Transaction Sub-Process
A sub-process with all-or-nothing semantics: either every step completes and the transaction confirms, or it is cancelled and completed steps are compensated. Drawn with a double border.
The Transaction Sub-Process wraps steps that must succeed as a unit — the classic trip booking: flight + hotel + payment. Its protocol has three outcomes: success (exit through the normal flow), cancellation (a Cancel End fires inside → compensation handlers undo completed steps → exit via the Cancel Boundary), and hazard (something broke mid-protocol; exit via an error boundary).
When to use and avoid
When to use
For all-or-nothing business units: multi-item bookings, coordinated postings, bundle orders.
When completed steps have declared compensation handlers to make the undo automatic on cancel.
When the business explicitly distinguishes confirm / cancel / hazard outcomes.
When NOT to use
For ordinary grouping without transactional semantics — embedded sub-process.
When steps can't be compensated — the protocol has nothing to undo with.
For technical ACID databases transactions — this is a *business* protocol, much longer-lived.
Business example
Booking a trip as a transaction
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- The Transaction (highlighted, double border) reserves flight and hotel as a unit.
- If the customer aborts, the internal Cancel End fires: completed reservations are compensated automatically.
- The token exits through the Cancel Boundary to the refund path — never leaving half a trip booked.
Differences
Transaction vs Embedded Sub-Process
Both contain flow; only the transaction carries the cancel-and-compensate protocol (double border, Cancel End/Boundary, automatic compensation). If nothing needs undoing, a plain embedded sub-process is enough.
FAQ
What triggers the compensation inside a transaction?
Reaching a Cancel End Event inside it (or an external cancel). The engine then runs completed activities' handlers in reverse order.
What is the 'hazard' outcome?
A failure of the transaction protocol itself (modeled with an error boundary) — neither clean success nor orderly cancellation.