Compose processes with subworkflows
A subworkflow delegates a responsibility to another process while preserving a typed contract between parent and child. The parent creates a child instance, waits for its resolution, then resumes with outputs declared by the child process.
A real child instance, not a graph macro
The node Subworkflow does not copy child-process nodes into the parent. It opens a separate execution with its own revision, observable graph, and status. The parent remains suspended on the node until that execution produces a result or fails.
The parent delegates a complete responsibility to a child instance and resumes only at the boundary of its output contract.
Use a subworkflow when a sequence has a reusable business responsibility, a clear input/output contract, or deserves autonomous observability. If the goal is only to make the graph look cleaner, splitting into a subprocess probably adds an unnecessary boundary.
Select the process and revision
The designer selects the child definition and revision to execute. A pinned revision ensures that a later child-process evolution does not silently change the behavior of an already-published parent process.
In a test environment, Process Builder may also target the Working revision to iterate quickly across both graphs. This authoring convenience does not change the production principle: reproducible execution must identify the child snapshot it executes.
Changing the child's input or output contract may invalidate parent mappings. Treat adoption of a new child revision as a parent-process change and recheck its bindings.
Inputs and outputs follow the child contract
Node parameters derive from the child process input_schema contract. Every required input must be fed from a compatible parent source. Outputs visible after resolution derive from the child output_schema contract.
This boundary avoids opaque context exchange: the subprocess does not automatically receive all parent state. It receives values explicitly mapped by the designer and returns only its output contract.
For the typing and compatibility rules used by these mappings, see Inputs, outputs, and bindings.
Choose participant continuity
A child process may declare its own participants. By default, these participants remain independent from the parent's. The designer may explicitly map a child participant to a parent participant when they genuinely represent the same person or role in the experience.
Several child participants may be linked to the same parent participant, but this must be intentional: they then share the same participant identity at that journey boundary. No mapping preserves explicit separation.
Data protection crosses the boundary
Mapping a value into the subprocess does not remove its classification. Protection policies associated with inputs are carried into the child instance. On return, outputs are classified according to the child's output contract while preserving inherited protections that still apply.
Splitting a process must never be used to implicitly turn protected data sensitive or secret into normal data. An explicit classification reduction remains subject to the same consent rules as in the parent graph.
See Data protection.
Failures, warnings, and observability
The child instance is inspectable like any other process instance. From the parent node, the user can drill into that execution to understand its path, inputs, outputs, and diagnostics.
If the child fails before producing a usable resolution, the node Subworkflow fails in turn and the parent follows its failure policy. When the child completes with warnings, the parent receives a summary warning rather than a copy of every internal diagnostic; detail stays in the child instance.
A warning indicates that investigation may be useful; it does not automatically turn a valid child result into failure. Open the child instance to inspect warnings at their source.
See Observability for reading nested executions.