Black Box Pool
A Pool drawn empty: the participant exists and exchanges messages, but its internal process is hidden or unknown.
The Black-Box Pool models the outside world honestly: you know *what you exchange* with the customer, the bank, the carrier — not *how they work inside*. Message flows attach to the Pool's edge, and the interface (which messages, when) is the entire knowledge the diagram claims.
Best practice: keep external participants black-boxed unless their internals genuinely matter — modeling other people's processes is guesswork.
When to use and avoid
When to use
For external participants whose internals you don't control or know: customers, partners, authorities.
To focus the diagram on your process and the interface contract with others.
To avoid asserting knowledge you don't have.
When NOT to use
For your own organization's side — that's the process being modeled; show it.
When the counterparty's steps are the actual subject (e.g. joint process design) — white-box by agreement.
As a lazy shortcut when the internal process is known and relevant.
Business example
The customer as a black box
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- The Customer Pool (highlighted) is intentionally empty — a black box.
- We assert only its interface: it sends an order, it receives a confirmation.
- The Store's internals stay fully modeled; the collaboration remains honest about what is and isn't known.
Differences
Black-box Pool vs no Pool at all
Omitting the external party loses the message context (who sends what, when). The black box keeps the conversation visible at zero modeling cost — usually the right trade.
FAQ
Where do message flows connect on a black box?
To the Pool's boundary itself — there are no internal elements to target.
Can a black box become white-box later?
Yes — add a processRef and model it when its internals become known and relevant. The collaboration stays intact.