When a data pipeline grows complex, maintaining all logic in a single workflow makes it hard to test, reuse, or hand off to other teams. A SUB_PROCESS node lets one workflow call another workflow as a subtask, so you can split a large pipeline into smaller, independently managed pieces.
Use this node type when you want to:
Reuse a workflow across multiple pipelines without duplicating its logic.
Isolate a subtask so it can be developed, tested, and maintained independently.
Compose nested structures — linear chains or multi-branch hierarchies — to match how your business process is organized.
How it works
A SUB_PROCESS node creates a trigger relationship, not an upstream or downstream dependency. This distinction matters:
| Relationship type | How it works | Dependencies allowed |
|---|---|---|
| Trigger (SUB_PROCESS) | The referencing workflow synchronously triggers the referenced workflow to run when it reaches the SUB_PROCESS node | No — the referenced workflow cannot have dependencies on other tasks, and no other task can depend on it |
| Upstream/downstream dependency | Tasks run in sequence based on explicit dependency links | Yes — standard task dependency configuration applies |
When a workflow reaches a SUB_PROCESS node during execution, it synchronously triggers the referenced workflow to run. The referenced workflow does not run on its own schedule — its execution is controlled by the workflow that references it.
Specifically:
A referenced workflow runs only when triggered by a SUB_PROCESS node.
Its scheduling parameters are inherited from the triggering workflow's scheduled time, not its own.
If multiple SUB_PROCESS nodes in different workflows reference the same workflow, it runs once per reference.
You can organize referenced workflows into two structures:
Linear hierarchy (left diagram): each workflow references the next one through a SUB_PROCESS node, forming a chain. For example, Workflow-E references Workflow-D, which references the next, down to Workflow-A.
Multi-branch hierarchy (right diagram): one workflow is referenced by multiple parent workflows. For example, both Workflow-B1 and Workflow-B2 reference Workflow-A through their own SUB_PROCESS nodes.
Limits
| Limit | Value |
|---|---|
| Maximum nesting depth (including the root workflow) | 5 layers |
| Maximum total workflows in a nested structure | 200 |
A referenced workflow and its internal nodes cannot have dependencies on other tasks, and no other task can depend on it. This applies to other workflows, nodes outside the current workflow, and the root node of the workspace.
Prerequisites
Before you begin, ensure that you have:
A workspace with Use Data Studio (New Version) enabled and a resource group attached. For more information, see Create a workspace.
Configure workflow references
This section walks through a complete example: enabling Workflow1 to be referenced, then creating a SUB_PROCESS node in Workflow2 that calls it.
Publish Workflow1 before publishing Workflow2. If the referenced workflow is not published first, the referencing workflow fails to publish.
Step 1: Enable referencing on Workflow1
A workflow must have the Referenceable switch turned on before another workflow can call it through a SUB_PROCESS node. Once enabled, you do not need to configure a schedule or dependencies for the workflow — both are controlled by the referencing workflow.
After enabling Referenceable, the workflow and its internal nodes cannot have dependencies on other tasks, and no other task can depend on it.
Go to the Workspaces page in the DataWorks console. In the top navigation bar, select a region. Find your workspace and choose Shortcuts > Data Studio in the Actions column.
In the left navigation pane, click
. To the right of Workspace Directories, click 
> Create Workflow. Enter a name for the workflow and save it. The workflow editor opens.On the configuration page for
Workflow1, click Property on the right. In the properties panel, turn on the Referenceable switch.
Step 2: Create a SUB_PROCESS node in Workflow2
Create a workflow named
Workflow2. For more information, see Recurring workflows.Open
Workflow2and drag a SUB_PROCESS node from Logical Node onto the canvas.In the Add Node dialog box, configure the following properties, then click Confirm.
After confirmation, if you created a new referenced workflow, hover over the SUB_PROCESS node and click Open Referenced Workflow. In the dialog box, click Save And Open to open the new workflow's configuration page. The Referenceable switch is on by default for workflows created this way.
Property Description Reference Workflow Set to Select Existing, then select Workflow1from the drop-down list. To create and reference a new workflow at the same time, enter a custom value for Workflow Name instead.Node Name Keep the system-generated name or enter a custom name. On the configuration page for
Workflow2, click Save. On the Change Check page, click Save to confirm. To see how many timesWorkflow1is referenced, open its Property panel on the right. Click View Details for more information.
What's next
After configuring the workflow reference, publish both workflows and monitor their execution:
Configure scheduling — set the scheduling properties for
Workflow2to run it periodically. For more information, see Node scheduling.Publish the workflows — publish
Workflow1first, then publishWorkflow2. A workflow runs on its schedule only after it is published to the production environment. For more information, see Publish an auto triggered task.Monitor execution — use Data Backfill to observe the running status of the auto triggered task in Operation Center. For more information, see Getting started with Operation Center. To view the execution status of all internal nodes in the referenced workflow, right-click the running SUB_PROCESS node and select View Internal Tasks Of The Referenced Workflow.