Sub-Workflows v2

A Sub-Workflow is a published Workflow called from another Workflow. It lets you reuse logic in Workflows that would otherwise be repeated in multiple places and provides a way to create abstraction.

The calling Workflow is the parent and the invoked Workflow is the child. A Workflow can be both: it can be called by one Workflow while calling other Sub-Workflows itself.

When to use a Sub-Workflow

Use a Sub-Workflow to isolate logic that is:

Reused by more than one Workflow.
Easier to test and release behind a small contract.
Owned or changed independently from the surrounding process.
A distinct business operation, such as validating an order or creating a customer.
Better placed on a different Cluster as a separate unit of execution.

Do not split a Workflow only to reduce its Step count. Every child adds a release dependency, an invocation boundary, and another contract to maintain.

Contract

The child's Workflow Parameters are its inputs. Its Workflow Returns are its outputs.

The parent maps values into those Parameters and consumes the returned values like any other Step Returns. the Runtime exposes each child Return directly on the Sub-Workflow Step; it does not add a synthetic Result wrapper around multiple Returns.

Treat names, types, nested Properties, and collection shapes as a versioned interface. Add compatible fields where possible. Coordinate breaking changes with every parent that calls the child.

Publish and Environment

The target must be published before the designer can obtain its contract. At runtime, the parent resolves the target's latest published revision in the same Site and Environment as the parent invocation.

This means:

A parent running in Test calls the child published in Test.
A parent running in Production calls the child published in Production.
Promoting only the parent does not promote the child.
You should release the child contract before or together with parents that require it.

In order for a Workflow to execute, it must be Enabled in that Environment. The designer warns when a selected Sub-Workflow is disabled, and the runtime fails the call if it remains disabled.

Runtime and Cluster boundary

The child is a separate Workflow with its own Steps and Runtime state. It can target a different Cluster from the parent. Flowgear invokes it in the current Runtime process when their Cluster selection matches or routes it to a compatible Runtime Host when they differ.

The child inherits the root invocation's Site, Environment, request context, caller identity, cancellation, and remaining execution deadline. Calling a child does not restart the parent timeout.

Avoid direct or indirect cycles. A Workflow that was invoked as a Sub-Workflow should never call back to the parent via a Sub-Workflow call of its own.

Errors and logs

If a child fails, its exception propagates through the Sub-Workflow Step. A parent TryCatch container can catch that failure.

Child Steps share the root execution's instance identity and appear nested under the Sub-Workflow call in the Workflow logs. The call row records mapped inputs and Returns, while nested child rows show the work performed by the child. This preserves one ordered trace across parent and child execution.

v1 Runtime compatibility

You can use the Sub-Workflow Node to call a v1 Runtime Workflow too. This is a good way to progressively migrate Workflows to the Runtime.

v1 Runtime templates are marked (v1) in the selector and derive their contract from applicable Variable Bar inputs and outputs.