Skip to main content

Subworkflow

The subworkflow node is a workflow component that allows an existing workflow to be invoked as a step inside another workflow. Through this component, complex business logic can be broken down into smaller, reusable workflows and orchestrated from a parent workflow.

When the subworkflow component is selected, it is configured via the properties panel located on the right-hand side. The parent workflow waits for the selected sub-workflow to complete and then continues execution from the next step.

The subworkflow and its parent workflow run on the same data instance and therefore share the same execution context. Any change made on the shared context inside the sub-workflow is visible to the parent workflow after the sub-workflow completes, and vice versa.

Properties

The behavior of the subworkflow component is defined through the properties panel. This panel contains the core configuration fields that determine both the identifying information of the subworkflow component and the workflow it will execute together with its input/output bindings.

When configuring a subworkflow component:

  • The workflow that will be executed as the sub-workflow is selected.
  • Input variables of the selected workflow are mapped from the parent workflow's data.
  • Output variables of the selected workflow are mapped back into the parent workflow's data.

These settings directly determine which workflow will run at runtime and how data will flow between the parent workflow and the sub-workflow.

Name

Name represents the visible name of the subworkflow component within the workflow. It is used for readability only and does not affect runtime behavior.

Step ID

Step ID is the technical identifier that uniquely defines the subworkflow component within the workflow. It is used by the runtime to reference this step and must be unique within the parent workflow.

Select Workflow

The Select Workflow field determines which workflow will be invoked as the sub-workflow at runtime. The dropdown lists all workflow models available in the current project.

  • The dropdown supports searching, which makes it easier to locate the desired workflow in projects with many workflow models.
  • The selection can be cleared, in which case the subworkflow component will not be bound to any workflow.
  • The selected workflow model can be opened in a new tab directly from the dropdown for inspection.

Once a workflow is selected, the subworkflow component automatically reads the input and output variables defined in the store of the selected workflow and prepares the mapping sections accordingly.

Selecting a different workflow resets the previously defined input and output mappings.

Variable Mapping

After a workflow is selected, two standard mapping sections are populated automatically based on the selected workflow's store:

  • IN VARIABLES MAPPING – Provides values from the parent workflow to the sub-workflow's input variables.
  • OUT VARIABLES MAPPING – Writes the sub-workflow's output variables back into the parent workflow.

Variable mapping behaves exactly the same as in any other component that exposes IN/OUT mappings; no subworkflow-specific rules apply.

Runtime Behavior

At runtime, the subworkflow component executes the selected workflow as part of the parent workflow's execution.

  • The input mappings are evaluated first, and their resulting values are written into the corresponding input variables of the sub-workflow.
  • The sub-workflow is then started and runs on the same data instance as the parent workflow.
  • If the sub-workflow completes successfully, the output variables of the sub-workflow are written into the targets defined by the output mapping, and the parent workflow continues with the next step.
  • If the sub-workflow does not complete in the same execution (for example, because it pauses on a User Task waiting for user input), the parent workflow is also paused. Execution resumes automatically when the sub-workflow continues.

Best Practices

  • Prefer subworkflows for logic that is reused in multiple workflows or that represents a clearly separable business capability.
  • Re-check the IN and OUT mappings after changing a sub-workflow's store, because added or renamed variables may require new mappings.
  • To avoid data access issues inside a sub-workflow, the data instance types of the sub-workflow and the parent workflow must be compatible with each other.