- Introduction
- Getting started
- Building with Maestro BPMN
- Understanding Maestro BPMN modeling
- Opening the modeling canvas
- Modeling your process
- Aligning and connecting BPMN elements
- Autopilot for Maestro (Preview)
- Process Repository
- Implementing a simple BPMN process
- Implementing a complex BPMN process
- Debugging
- Simulating
- Evaluations (Preview)
- Common implementation scenarios
- Building with Maestro Case
- Introduction to Maestro Case
- Maestro BPMN vs. Maestro Case: when to use case management
- The Maestro Case lifecycle: from event trigger to app experience
- Build your first case with Maestro Case
- Build a Maestro Case with a coding agent (preview)
- Defining case keys (system vs. external)
- Establishing task I/O and write-back contracts
- Exit rules and early stage termination
- Modeling primary and secondary stages
- Triggering a case from Data Fabric
- Implementing stage-level personas and permissions
- Setting SLAs and automated escalation rules
- Configuring a rework loop (re-entry)
- Configuring and testing the Case Manager Agent (preview)
- Case Manager input and output contract
- Maestro Case component dictionary
- Building with Maestro Flow
- Maestro Automate
- Integrations
- Operating
- Monitoring
- Optimizing
- Reference information
Subflows for grouping process nodes into reusable, self-contained units within a parent workflow, with variable scoping rules and input/output configuration.
What it is
A subflow is a process embedded within another process. It groups a set of nodes into a self-contained unit that executes as part of the parent process and returns output to it. Subflows help you organize complex logic into reusable, manageable pieces.
How it works
When a parent process reaches a subflow node, execution enters the subflow and runs its nodes in sequence. The subflow has its own variable scope, so variables defined inside it don't collide with variables in the parent process. When the subflow completes, its return value is passed back to the parent process and execution continues from the next node after the subflow.
Nodes inside a subflow can access:
- Other nodes within the same subflow
- The parent process's scope
The subflow's return value is accessible to the parent process as $vars.<subflowName>.output.
Creating a subflow
To add a subflow to your process:
- Open the node palette on the canvas.
- Search for or locate the Subflow node.
- Drag it onto the canvas and connect it to the preceding node.
Flow adds the subflow as a collapsible container on the canvas. Select it to expand it and add nodes inside.
Result: The subflow appears on the canvas as a collapsible container. Drag nodes inside it to define the subflow's logic.
Passing data in and out
Inputs
You define subflow inputs in the properties panel. Each input accepts a value or expression from the parent process's scope.
To configure subflow inputs:
- Select the subflow node on the canvas.
- Open the Subflow Inputs section in the properties panel.
- For each input, enter a name and a value or expression.
Result: The inputs are configured and available inside the subflow body as $vars.<inputName>.
Output
The subflow's return value is available to the parent process as $vars.<subflowName>.output. You reference it in any downstream node expression just like any other node output.
// Access the output of a subflow named "validateOrder"
$vars.validateOrder.output
$vars.validateOrder.output.isValid
// Access the output of a subflow named "validateOrder"
$vars.validateOrder.output
$vars.validateOrder.output.isValid
Variable scoping
Subflows create their own variable scope. This means variables updated inside a subflow are namespaced to avoid collisions with the parent process.
From outside the subflow, you reference a subflow's internal variables as $vars.<subflowName>.<variableName>. For example, a variable counter inside a subflow named subflow1 is referenced as $vars.subflow1.counter from the parent process.
From inside the subflow, nodes access their sibling nodes' output using the standard $vars.<nodeName>.<property> pattern. They can also read from the parent process's scope directly.
Variable namespacing prevents a subflow's internal variables from overwriting parent variables that share the same name. You don't need to coordinate variable names between parent and subflow.
Practical example
A parent process that calls a subflow to validate order data before processing it.
Parent process:
- HTTP Request (
httpRequest1) — fetches order data from an external API. - Subflow (
validateOrder) — validates the order data and returns a result. - Decision (
decision1) — branches based on the validation result.
Inside the validateOrder subflow:
-
Script (
script1) — checks that required fields are present and the order total is above zero.const order = $vars.validateOrder.orderData; const isValid = order.items.length > 0 && order.total > 0 && order.customerId !== undefined; return { isValid: isValid, reason: isValid ? "OK" : "Missing required fields" };const order = $vars.validateOrder.orderData; const isValid = order.items.length > 0 && order.total > 0 && order.customerId !== undefined; return { isValid: isValid, reason: isValid ? "OK" : "Missing required fields" }; -
The subflow returns the Script's output as
$vars.validateOrder.output.
Back in the parent process:
The Decision node evaluates $vars.validateOrder.output.isValid === true and routes to either a fulfillment path or an error-handling path.
Related pages
- Variables and data flow — variable scoping rules, expression syntax,
$varsaccess patterns - The Canvas — navigating the canvas, properties panel, node palette
- Error handling — configuring error handles on nodes, including within subflows