Supported BPMN execution profile#
The documented Workflow profile executes one process per definition, one start node per version and one active business token per instance. Its sequence-flow graph is acyclic. Multiple independent instances can wait concurrently, but a single instance does not use parallel tokens.
Every executable node must be reachable from the start. Every reachable path must terminate or enter a durable wait. Ordinary activities have one incoming and one outgoing sequence flow; explicit gateways handle branching and merging. Multiple end events can represent different business outcomes.
Executable elements#
| Element | Supported behavior |
|---|---|
| None start | An authorized, idempotent API start with declared input |
| Message start | An eligible durable event starts an instance for each explicitly active binding |
| Service task | An approved capability with typed input/result and an asynchronous operation lifecycle |
| User task | One eligible human responder, claim/release behavior and typed outcomes |
| Exclusive split | Ordered typed conditions with a required default path |
| Exclusive merge | Passes the arriving token; it is not a parallel synchronization barrier |
| Message catch | Waits for a registered event with exact correlation |
| Timer catch | Persists a due instant or resolved duration in PostgreSQL |
| None end | Records the outcome after the active token settles and operations are resolved |
The first true exclusive condition wins. The designer displays the condition order, and compilation preserves it. Conditions use supported typed comparisons and Boolean combinations over declared process data; they are not arbitrary executable expressions.
Approval example#
A bounded approval can follow this sequence:
- Start from an authorized request.
- Validate the request through a service task.
- Ask an eligible person to review it through a user task.
- Route the typed decision through an exclusive gateway.
- Apply an approved change through another service task, or end with the rejection outcome.
A rejected request is a business outcome. It need not be represented as a transport error or recovery incident. Similarly, a service can successfully return a result that requires review. Technical failures and uncertain external effects follow the operation recovery contract.
Human expiry#
The default expiry policy is onExpiry=incident. A definition can explicitly publish onExpiry=continueWithExpiredResolution, which settles the node with a typed system-expiration result while leaving the task Expired.
That resolution is not a human decision and cannot grant approval. Publication checks the resolution schema and route. The next ordinary sequence flow can reach a gateway and an expiry end. This extension does not imply BPMN boundary-event support.
Unsupported constructs#
The profile excludes loops, parallel and inclusive gateways, event-based gateways, subprocesses, call activities, multi-instance tasks, quorum voting, boundary events, signals, message throws and message ends. It also excludes timer starts, cron scheduling, script tasks and automatic saga compensation.
Pools, BPMN choreography and cross-process message flows are not executable features of this profile. Event-driven choreography between applications remains available through integration contracts; it is a different concern.
Where rework is required, end the original process with a resubmission outcome and start a new linked instance. Do not draw a loop and assume the runtime will execute it.
Validation and import#
The server compiler is authoritative. An imported XML file must satisfy the same supported elements, extension vocabulary and schema rules as a diagram created in the browser. Unsupported semantics are rejected rather than silently discarded. Saved labels and layout have no execution authority.
BPMN element identifiers remain available after compilation so diagnostics and runtime progress can refer to the original diagram. The deployed compiler/profile must support the definition being activated. See typed mappings for the mapping extension and definition lifecycle for version pinning.