Sub-Process 📦

Embeds a nested workflow within the current workflow.

Node type: subProcess Category: Flow Control Actor: subProcess (1 thread)

---

Description

The Sub-Process node contains an embedded mini-workflow that executes as part of the parent process. Unlike Call Process (which invokes an external workflow), a Sub-Process defines its own Start and End Events inline within the parent workflow's designer canvas.

Sub-Processes are useful for:

• Grouping related nodes into a logical block
• Applying shared timeout or boundary events to a group of nodes
• Keeping complex workflows organized without creating separate workflow definitions
• Transaction-like grouping (all or nothing via error boundary events)

---

Properties

Property	Type	Required	Description
subProcessType	select	Yes	embedded (inline) or referenced (external definition)
processKey	text	Conditional	Required for referenced type — the referenced process ID
transaction	checkbox	No	Mark as a transactional sub-process (enables compensation)

---

Embedded Sub-Process

An embedded sub-process is defined graphically within the parent workflow. In the designer, double-click the Sub-Process node to open its inner canvas and add nodes.

[Parent Workflow]
   ↓
[Sub-Process: Payment Processing]
   │  [Start]
   │     ↓
   │  [Validate Card]
   │     ↓
   │  [Charge Card via Stripe]
   │     ↓
   │  [Record Transaction]
   │     ↓
   │  [End]
   ↓
[Send Receipt Email]

The sub-process has its own Start and End Events. When the inner End Event is reached, control returns to the parent.

---

Referenced Sub-Process

A referenced sub-process calls an external workflow definition by key. This is functionally similar to Call Process but uses the Sub-Process node type:

{
  "subProcessType": "referenced",
  "processKey": "proc_payment_handler"
}

---

Variable Scope

Sub-processes inherit the parent's variable scope. All parent variables are accessible inside the sub-process, and any variables set inside the sub-process are available to the parent after completion.

---

Boundary Events

Sub-process nodes support boundary events — events attached to the border of the sub-process that can interrupt it:

Boundary Event	Behavior
Error Boundary	Interrupts the sub-process if any inner node throws an error. Takes the error exit path on the parent.
Timer Boundary	Interrupts the sub-process if it takes longer than a configured time
Compensation Boundary	Triggers compensation logic if the transaction is rolled back

[Sub-Process: Place Order]
     │  [inner nodes...]
     │
  ↓ (success)    ↕ (error boundary)
[Ship Order]     [Cancel Order / Refund]

---

Connections

Connection	Description
sequenceFlow (incoming)	Arrives from parent
successFlow / sequenceFlow (outgoing)	Continues after sub-process completes
errorFlow (outgoing)	Taken if sub-process fails (no error boundary)
Boundary event exit	Taken if a boundary event fires

---

Editing the Sub-Process

In the workflow designer:

1. Double-click the Sub-Process node to expand it
2. The inner canvas opens — add nodes like a regular workflow
3. The inner canvas must have a Start Event and at least one End Event
4. Click outside the sub-process to collapse it back

---

Sub-Process vs. Call Process

Feature	Sub-Process	Call Process
Definition	Inline in parent canvas	Separate workflow definition
Reusability	One parent only	Reusable across many parents
Variable scope	Shared with parent	Separate (data passed as input)
Visibility in executions	Part of parent instance	Independent child instance
Best for	Organization, grouping, transactions	Reusable building blocks

---

Best Practices

• Use embedded sub-processes to organize long workflows into named sections
• For any group of nodes that should succeed or fail together, wrap them in a Sub-Process with an Error Boundary event
• Keep sub-process inner canvases focused — if the inner workflow has more than 10–15 nodes, it should probably be a separate Call Process
• Use boundary timer events on sub-processes that may hang (e.g., a sub-process that includes an Input Node)