Sub Flow node

A Sub Flow node lets you call another flow from within your flow. The flow you call is a normal flow; it acts as a sub flow only when it is invoked from a Sub Flow node. You can reuse shared logic, break complex flows into smaller pieces, or orchestrate multiple flows from a single parent flow. For example, a parent flow might decide which cloud account or region to act on, then call a sub flow that performs the same cleanup or compliance check for that target, so you maintain one sub flow instead of duplicating logic per account. The sub flow runs as a child of the current flow, and its output is available to subsequent nodes.

When both the parent flow and the sub flow use a schedule trigger, the sub flow's schedule is ignored. When the parent flow is triggered, it invokes the sub flow immediately when execution reaches the Sub Flow node, regardless of the sub flow's own schedule. You do not need to disable the sub flow's schedule when it is called by another flow.

Input and output

Input: The sub flow receives input from the parent via the values you configure in the Sub Flow node. Those values are passed into the sub flow as its local variables when the parent runs, so nodes inside the sub flow can use them like any other flow variables.

Output: Without Flow output nodes, the subflow has no output data for the parent apart from an executionId. Add Flow output nodes in the subflow to expose named outputs (for example, multiple fields or a specific shape); the parent then references those outputs via the + button or field picker. Subsequent nodes in the parent can use the Sub Flow node's output like any other node's output.

Configure Sub Flow node

1. Create the sub flow you want to call. In that flow, create local variables for each value you want the parent to pass in when it invokes the sub flow. You must define these in the subflow before configuring a Sub Flow node. They become the execution parameters on the Sub Flow node in the parent, so without them there is nothing for the parent to pass in.

   In the parent flow, supplying values for these parameters is optional. The parent can set values for any of the subflow's local variables when configuring the Sub Flow node. Create and publish the sub flow so you can select it in a parent flow's Sub Flow node; if it is not published, CloudFlow throws an error when the parent flow reaches the Sub Flow node.

2. Add a Sub Flow node to your parent flow.

3. In Flow to call, select the sub flow you want to invoke.

4. After you select the flow in Flow to call, select +Add additional parameters to add the parameters you want to pass to the subflow. These are that subflow's local variables (the ones you defined in that flow in step 1).

   

   Set each parameter from the parent (for example, from a previous node's output or from the parent's local or global variables).

   

   CloudFlow passes those values into the subflow when the parent runs. The sub flow uses these parameters only when it is invoked by another flow; when the sub flow runs on its own (for example, via its own trigger or a manual run), you set those variables in that run and it does not use the values from the parent flow.

When the parent flow runs, it executes the selected flow as a sub flow. The sub flow runs in the context of the parent run, so you can pass data in and use the sub flow result in subsequent nodes in the parent flow. That result is the sub flow's output (see Input and output).

Sub flow run history

In the parent flow's run history, each Sub Flow node run includes a link to the corresponding sub flow run so you can open the child run and inspect its steps, outputs, and timing.

Select View subflow run to view a subflow's run history.

When a sub flow fails, the parent flow fails at the Sub Flow node. In the parent flow run history, the error shown at that node is the same error from the failed node inside the sub flow (which node failed and why), so you can understand what went wrong without opening the sub flow run. Select View subflow run to inspect its full history.

Approvals in subflows

When the subflow contains a node that requires approval (for example, an AWS node or GCP node with Require approval for this action), the parent flow pauses at the Sub Flow node until the approval is completed.

When the approver approves, the subflow continues and the parent resumes automatically when the subflow finishes. The parent then receives the subflow output and continues to the next node.

When the approver rejects the action or the approval times out, the result is propagated to the parent and the parent flow fails at the Sub Flow node. An approval rejection or timeout error is shown in the run history.

Example: Orchestrated compliance check

The following design uses a parent flow to run a weekly compliance check by calling a reusable sub flow that evaluates one account. The sub flow can also be run on its own (for example, manually for a single account) using its own parameters.

Parent flow: Weekly compliance orchestration

1. Schedule trigger: Runs the flow weekly (for example, every Monday).
2. Datastore node: Reads which account ID and region to check from a config table (for example, a list of accounts to include in the weekly run). For a single-account setup, this could be a fixed value or a Code node that returns one account.
3. Sub Flow node: Calls the sub flow Single-account compliance check and passes the account ID and region from the previous node as execution parameters.
4. Branch node: Evaluates the sub flow output (for example, violation count). One path when violations exist, one when the account is compliant.
5. Notification node: Sends a summary to Slack or email (for example Compliance check completed for account X: 3 violations or No issues found).

Sub flow: Single-account compliance check

The sub flow defines local variables accountId and region. When called from the parent, the Sub Flow node supplies these; when the sub flow is run on its own (manual or its own trigger), you manually set them in that run.

1. AWS node (or GCP node): Lists resources in the given account and region (for example, S3 buckets or EC2 instances). Configure the node with the flow's local variables accountId and region—whether the flow runs on its own or is called from a parent, you set the node to use these variables; only the source of the values differs (the run when standalone, the parent when called as a subflow).
2. Filter node: Narrows the list to resources that need checking (for example, buckets without a specific tag or instances in a given state).
3. Policy node: Evaluates the filtered resources against a policy (for example, "S3 buckets must have cost-allocation tags").
4. Transform node: Builds a summary from the policy result (for example, violation count, list of resource IDs).
5. Flow output node: Exposes the summary (for example, violation count) so the parent flow can use it. Without this node, the subflow would have no output data for the parent apart from an executionId.

The parent flow then uses that summary in the Branch and Notification nodes. You can reuse Single-account compliance check from other parent flows (for example, different schedules or triggers) without duplicating the compliance logic.