Diagram - BPMN Gateways

#Usage

Use a selected Gateway record. Its outgoing-flow rules remain part of validation.

A gateway declares how branches relate. Ordinary decisions, parallel branches and an event-based choice have different allowed flows; changing the marker alone can invalidate the existing graph.

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.

#Model an ordinary decision

The initial graph isolates the gateway decision. Review has no incoming sequence flow, and Ship and Clarify have no outgoing flows, so it starts with completeness warnings. Add the surrounding process to complete it; these warnings do not reject the valid branch edits.

The short slash across the start of Clarify marks the default outgoing flow. It sits outside the gateway; the arrowhead at the other end indicates the direction. The X inside Approved? identifies the exclusive gateway.

Select Approved? or a branch. Approved has a condition; Clarify is the default. The inspector changes gateway type, outgoing default ID and branch condition. Try Parallel while these decision properties remain: incompatible metadata rejects. Clear the condition/default before converting the graph.

A default references an actual outgoing sequence and carries no condition. Removing or reconnecting a referenced default requires repairing the owner. Conditions are nonblank ≤2048 characters. These choices do not evaluate expressions or choose a route.

#Wait for modeled event choices

First event targets a Message catch and Timer catch. Try mixed Receive branch rejects mixing Receive tasks with Message catches (including Multiple constituents). Try second incoming rejects another source into a choice target.

Event-based targets are Receive tasks or intermediate Message, Signal, Timer, Conditional or Multiple catches. Each target has exactly one incoming branch and no duplicate edge. Receive targets cannot have attached boundaries. Multiple constituents are restricted to Message/Signal/Timer/Conditional. Event-based outgoing sequences cannot have conditions or defaults.

instantiate: true describes a process-level entry choice. It is excluded inside subprocesses and permits no incoming sequence. eventGatewayType defaults exclusive; parallel requires instantiate: true in this profile. Missing two distinct outgoing choices warns while authoring; incompatible relationships reject.

#Model a process entry choice

Select the gateway and compare Exclusive/Parallel in the inspector. This separate specimen has no incoming sequence. Try incoming flow rejects without adding an edge. Parallel event-based mode requires instantiation; it is not available for an ordinary non-instantiating event choice.

#Record Complex activation

Select Three approvals to edit its Activation condition. Clear activation leaves a warning and the graph unchanged geometrically. The condition is inert nonblank text ≤2048; there is no Complex activation engine.

#Gateway reference

DiagramBpmnNode with kind: 'gateway' has gateway from BPMN_GATEWAYS: exclusive, inclusive, parallel, complex, eventBased. Only Complex accepts activationCondition. Only event-based accepts Boolean instantiate (default false) and eventGatewayType: 'exclusive' | 'parallel' (default exclusive; parallel requires instantiation). Generic optional defaultFlowId is excluded for Parallel/event-based. Every gateway has the actual process/scope identity and a square symbol body.

Copied inspector actions are gatewayChange, gatewayInstantiate, eventGatewayMode, gatewayActivation, setDefault and conditionChange on the flow. They submit through the same typed editor and current policy. Validators recheck reverse edits to target roles and attachments, so changing a catch into an incompatible task or attaching to a Receive target cannot bypass the restrictions. Warnings and rejected transactions remain distinct.

#Related Docs

• Choose a Notation
• Supported Profiles
• API