Sub-Workflows Overview — Guide34_SubWorkflows

What Are Sub-Workflows?

A sub-workflow is a complete BizFirstGO workflow process that is invoked from within another workflow (the parent). The parent workflow uses a SubWorkflow node to trigger a child process, pass data to it, and optionally wait for its result.

Sub-workflows enable you to:

Build reusable workflow modules (e.g., "Send Approval Email" workflow used by dozens of parent workflows)
Decompose complex flows into manageable, independently testable units
Fire parallel child workflows from one parent for distributed processing
Apply different security policies to child workflows (e.g., a privileged subprocess)

Parent / Child Relationship


Parent Workflow (ExecutionId: "exec-100")
    │
    ├── Node A
    ├── Node B
    └── SubWorkflowNode
            │
            │ Invokes:
            ▼
    Child Workflow (ExecutionId: "exec-101", ParentExecutionId: "exec-100")
            ├── Child Node 1
            ├── Child Node 2
            └── Child Node N → Result
            │
            ▼ (sync: parent resumes with child result)
    Parent resumes after SubWorkflowNode
            └── Node C

Two Invocation Modes

Mode	Parent Behavior	Use When
Synchronous	Parent suspends (HIL-like) until child completes	Parent needs child's result to continue
Asynchronous	Parent continues immediately; child runs independently	Parent fires-and-forgets (notifications, logging)

Data Contract

Data flows between parent and child through two explicit maps:

inputMap — parent expressions → child's trigger $json
outputMap — child's output expressions → parent's ExecutionMemory variables

There is no implicit data sharing. Parent and child each have their own isolated ExecutionMemory. The maps are the only bridge.

Design for reuse: A well-designed sub-workflow depends only on its input parameters (via $json), not on any parent-specific node IDs. This makes it truly reusable across multiple parent workflows.

Next: SubWorkflow Node →