A nested workflow task (Run Job) calls another workflow within the current workflow to enable modular reuse and cross-module orchestration of workflows.
Overview
Key features of nested workflows:
Reusable: Encapsulate common subprocesses (such as data validation, dimension generation, and model evaluation) into independent workflows, which can be referenced by multiple main processes through nesting.
Decoupling: Subworkflows can be maintained by different teams, while the main workflow only references their results.
Multi-level nesting: Supports up to 3 levels of nesting. Exceeding this limit is blocked.
For general configurations (task name, upstream dependencies, run conditions, parameters, monitoring metrics, alarms, and failure and timeout policies), see Task General Configuration. Prerequisites
You are already the workflow owner or have Manage permission.
The nested workflow (subworkflow) has been created and is runnable. The current user (or Run As account) has Run or Manage permission on the subworkflow.
Operation Steps
Step 1: Creating a Job
1. On the workflow canvas, click + Add Task.
2. Select Nested Workflow as the task type.
Step 2: Configuring Basic Information
Parameter | Description | Required |
Task Name | Unique within the same workflow. | Yes |
Task type | Nested workflow. You can switch to other task types from the dropdown list. After switching, the parameter area will be cleared. | Yes |
Select Workflow | Select the nested workflow from the dropdown list. | Yes |
Step 3: Selecting the Nested Workflow
1. Click the Select Workflow dropdown. The list displays workflows for which the current user has Run or Manage permission.
2. Supports both fuzzy search and exact search.
3. After a workflow is selected, a jump Icon appears on the right. Click it to go to the Workflow Orchestration Tab of the selected workflow.
Step 4: Parameters
Parameters for nested workflow tasks have three types of sources, listed by priority (high to low):
Priority | Source | Action |
1 | Current task parameter | Task-level new parameter. Highest priority. |
2 | Current workflow parameter | Current workflow parameters are automatically delivered to tasks. Parameter names are grayed out and cannot be modified. |
3 | Task parameter of nested workflow | Displayed in the task panel. Parameter names cannot be modified, while parameter values can be modified. Modified values are passed to the subworkflow. |
4 | Workflow parameter of nested workflow | Same as above. |
Name Conflict Rules
The priority for parameters with the same name in a nested workflow is determined by two independent dimensions: the general principle of "outer layer > inner layer", and within the same layer, "task parameters > workflow parameters".
Dimension 1 (cross-layer): outer layer > inner layer: any parameter of the current workflow > any parameter of the nested workflow.
Dimension 2 (within the same layer): task parameters > workflow parameters: within each layer, task-level parameters take precedence over workflow-level parameters.
Combining the two dimensions yields the four priority levels shown in the table above: current task parameters (1) > current workflow parameters (2) > task parameters of the nested workflow (3) > workflow parameters of the nested workflow (4).
When duplicate names appear in the downstream configuration panel:
Parameters of the nested workflow are automatically grayed out, and their values display the values inherited from the parent level.
If a parameter in the current workflow has the same name as a parameter in the nested workflow, a prompt is displayed for the nested parameter: "This is a parameter of the nested workflow. If it has the same name as a workflow parameter, the outer workflow parameter takes precedence and its value overrides the value of the nested workflow parameter."
Step 5: Upstream Dependencies, Run Conditions, Monitoring Metrics, Alarms, and Failure and Timeout Policies
Step 6: Saving
Click Create Task or Save Task.
Runtime Behavior
Triggering a Subworkflow from a Running Job
When a nested workflow task runs, it triggers the corresponding subworkflow run:
A new record is added to the run list of the subworkflow.
The "Trigger Method" of the subworkflow run is displayed as the parent task name (click to jump to the run details of the nested workflow task).
Job Run Details
The run details page of a nested workflow task displays only the "Run Result" Tab:
Content. | Display |
Execution result | Go to the nested workflow run details page to view the run result: /Nested workflow ID/ (displayed in blue and clickable). |
File path | Display the nested workflow name. Click to go to the workflow details page. |
Workflow Run Details Redirect
Single-task workflow (with only one nested node): Click the workflow run ID to jump directly to the subworkflow run details.
Multi-task workflow: Click the workflow run to go to the workflow details page, and then click the nested node to jump to the subworkflow run details.
Parameter Description
Parameter Passing Rules
Scenario | Action |
Parameters Passed from Upstream | When a nested node runs with the external workflow, the parameters can be passed and take effect on each task under the run_job node. |
Running the Run Job Node Independently | Unable to obtain parameters passed from upstream. |
Passing Parameters from the Run Job Node to Downstream | Downstream can use the parameters defined in it. |
Internal and External Parameters with the Same Name | When the process is run externally: external values take precedence; when the process is run inside Run Job: internal values take precedence. |
Use Limits
Nesting supports up to 3 levels. For example, Workflow A → Workflow B → Workflow C is 3 levels. Nesting D further exceeds the limit.
Circular nesting is not supported (for example, A nests B, and B nests A).
The scheduling backend verifies level by level the run account's (Run As / current operator) run permissions on each referenced subworkflow layer. If any layer lacks the "Runnable" permission or higher, the entire task is set to failed.
After a nested workflow task is deleted, the corresponding subworkflow still exists, and only the reference relationship from the parent workflow is disconnected.
FAQs
Q1: Whose identity does the run account of a nested workflow use?
Scheduling run: The Run As account of the current task is used. This account must have run permissions on the subworkflow.
Debugging run: Use the current operator account.
Q2: What error messages may appear when a nested workflow task fails to execute?
Error Message | Description |
Workflow Does Not Exist. | The nested subworkflow has been deleted. |
No Tasks Exist in the Workflow. | The subworkflow contains no tasks. |
{Account} Does Not Have Run Permission on {Workflow Name}.
| The Run As account does not have run or higher permissions on the subworkflow (any level of validation failed). |
Detailed error information is displayed at the top of the task run log.
Q3: Can a workflow be nested within a For Each node?
Yes. The inner node of a For Each node supports the nested workflow type. Multiple loops correspond to multiple instances of the nested workflow. For details, see "Inner Loop Node Configuration" in For Each Loop Task. Q4: What happens if you view the task details after the instance of a nested workflow is deleted?
When you are redirected to the nested workflow page, the following message appears: "This page does not exist. The page may have been deleted."
References