Skip to main content
In large engineering organizations, different squads often duplicate identical API sequences (e.g. acquiring an OAuth token, provisioning an authenticated test customer, or establishing a tenant session). Subflows (subflow) solve this by allowing any complete workflow to be packaged as a single reusable node that can be dropped into parent workflows.

​
1. Why Use Subflows?

​
1. Cross-Team Reusability

Instead of every QA engineer or developer building a 5-step customer onboarding chain from scratch, the Identity squad publishes a single “Provision Customer” Subflow. Other teams (Billing, Checkout, Loans, Inventory) simply drag the subflow node onto their canvas.

​
2. Single Point of Maintenance (DRY)

When the identity service adds a mandatory header or alters an onboarding step, the Identity team updates the subflow once. All parent workflows across the organization automatically run the updated logic without breaking.

​
3. Encapsulation & Canvas Clarity

Hides complex plumbing (token exchange, error handling, session cookies) inside the subflow, keeping parent business flows clean, readable, and focused on core business logic.

​
2. Input & Output Contract Mapping

Every subflow defines explicit input parameters and output values:

​
Input Parameters (Parent →\to Subflow)

The parent flow passes variables into the subflow:

​
Output Contracts (Subflow →\to Parent)

The subflow designates which internal node responses are exposed to the parent flow:

​
3. Scope Isolation & Runtime State

  • Variable Isolation: Subflows execute within their own scoped variable context. Internal temporary variables created during subflow execution do not pollute the parent flow’s state.
  • Failure Propagation: If any step within a subflow fails, configurable policies determine whether the parent flow halts or executes a fallback branch.