Diagram - BPMN Pools and Messages

#Usage

Use a selected Message Flow between participants.

Use a collaboration page when multiple participants exchange messages. Each pool owns a participant process; lanes divide its canvas but do not introduce nested BPMN scopes. This models process collaboration, without delivering messages.

Use the BPMN setup with the module installed in the store. Keep the matching semantic root and copied inspector under Diagram.Root. The examples below include their complete model and controls.

#Connect two participants

This example focuses on a message between participants. The two tasks intentionally have no incoming or outgoing sequence flows inside their pools, which produces completeness warnings. The message flow does not replace those process flows; the warnings do not indicate a broken collaboration demo.

Sales sends to Fulfillment through an initiating Message Flow. Select message and use the inspector to choose plain, initiating or non-initiating display. Try cross-pool sequence rejects: sequence belongs inside one process. Grow Sales lane changes its geometry through the ordinary swimlane action and Undo restores it. The complete source creates both participants with the typed editor before adding lane-local tasks and the message.

#Participant reference

The page envelope is bpmnEnvelope({ kind: 'collaboration' }). Use editor.createParticipant(id, pageId, layerId, x, y) rather than updateNode to turn a generic task into a pool. It creates a horizontal pool, initial length 700 and one Process lane of size 280. Participant processId/scopeId are its own ID. Child nodes use the participant identity; lane children have local geometry under the actual lane record. Inner subprocesses introduce their own scope.

Omitted laneMode represents explicit semantic lanes. laneMode: 'body' represents one layout-only body lane with no BPMN lane identity. Use a participant/pool structure consistent with that choice, especially when importing/exporting. A pool is not an ordinary activity and cannot be a sequence endpoint. A process page is not a participant and does not imply message collaboration.

Use session.swimlanes.execute for participant/lane operations such as create, lane-insert, lane-update, lane-remove and ordering. The swimlane guide records the generic geometry/actions. Use editor.reparent to transfer process content so semantic scope and actual lane parent change together. Transfers that leave incompatible flows/references reject as a whole.

#Message flow reference

Message data has kind: 'message' with processId and scopeId equal to the collaboration page. Both compatible endpoints must be in different participant processes on that page. Supported sources/targets include participants, tasks, calls, non-event subprocesses and the appropriate standalone Message throw/catch positions. A standalone Message boundary is allowed as a target, never a source. Other boundaries, gateways, artifacts and composite events are excluded as endpoints. Same-participant message flow rejects.

The envelope stays upright as the route changes. It is connector midpoint adornment, with labels independently editable. editor.updateFlow uses the connection adornment path for a Message Flow display change, including current appearance permissions, approval and controlled-store acknowledgement. DiagramBpmnRoot.updateFlow reports that status. Inspector messageDisplay clears the optional field for plain or saves the exact chosen value. It does not send a message or infer process routing.

editor.connect constructs a Message Flow through the connection controller; reconnect(id, 'source' | 'target', nodeId) rechecks endpoint/process legality. For sequence or annotation associations inside a pool, keep both endpoints and flow in the same semantic scope. Cross-pool visual Groups can categorize records without moving them into a shared process.

#Related Docs

• Choose a Notation
• Supported Profiles
• API