Sub-workflow Node

The Sub-workflow node runs another workflow of the same project as a single step. Its Input fields become the node's inputs, its Output fields become the node's outputs, and the call is traced under the step so a run shows the callee nested beneath the caller. Build a decision — an eligibility check, a fraud screen, a pricing chain — once, and reuse it from every workflow that needs it, or run it once per item inside a Map node.

Configure a Sub-workflow on the canvas

How it runs

• The mapped inputs are the callee's request; the callee's Output node fields are the node's result.
• Every run executes its own copy of the callee, so two Sub-workflow nodes calling the same workflow in parallel branches — or a Map running one over a batch — never share state, and a retried step starts clean.
• Under a dry run, what the callee's writers ingested is deleted when the whole run ends, not when the callee returns, so a step after the Sub-workflow node still reads it.
• The callee's nodes are traced under the step: expand the Sub-workflow node in the trace to read their inputs and outputs. A failing node inside the callee fails the step with a message naming that node.
• A workflow cannot call itself, directly or through another workflow: the editor never offers the workflow you are editing, and the runtime refuses to run a flow that is already running above the step.
• The Error handling tab applies to the whole call: a timeout bounds the callee's run, retries run it again, and Return lets the rest of the workflow continue past a failed callee.

Versions and deployments

A saved version of a workflow is a release. Latest released means the newest version at the moment the caller is saved, tested or deployed — a deployed App keeps the callee version it was built with until you redeploy, so a new release of a shared decision never changes a running App by surprise. Pin a version when a caller must stay on a known rule set; the version picker in the panel lists them newest first. See Versions and releases.

Test cases and coverage

When you run the caller's test cases, the callee runs too, but its result is the caller's business: cases are scored against the caller's Output node, and rule coverage counts only the caller's own Decision Tables and Rules nodes. Give the callee its own cases in its own editor.

Runtime and SDK

The node is dynamiq.nodes.operators.SubWorkflow. When the workflow is saved, tested or deployed, the platform resolves the chosen version and inlines its nodes as the node's flow, so the runtime sees a nested flow rather than a reference. The platform refuses a save, test or deployment whose sub-workflow names a workflow of another project, a workflow that calls itself directly or through other workflows (the message names the chain), a pinned version that was archived, a workflow without a released version, or sub-workflows nested more than eight levels deep. A test run of an unsaved flow admits a sub-workflow you can open yourself. The SDK class, the isolation rules and the nested-flow YAML form are in Sub-workflow.

Pitfalls