> ## Documentation Index
> Fetch the complete documentation index at: https://docs.quixa.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Subflows & Modular Workflows

> Package multi-node workflows into reusable modular subflows for cross-team sharing and DRY architecture.

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.

```mermaid theme={null}
graph LR
    subgraph ParentFlow["Parent Workflow: Order Processing"]
        A["Start"] --> Sub["Subflow Node: 'Provision Customer'"]
        Sub --> B["POST /orders"]
        B --> C["POST /fulfillment"]
    end

    subgraph InternalSubflow["Internal 'Provision Customer' Subflow (5 Steps)"]
        S1["POST /auth/login"] --> S2["POST /customers"]
        S2 --> S3["POST /wallets"]
        S3 --> S4["POST /kyc/verify"]
        S4 --> S5["Return Output: customerId"]
    end

    Sub -.-> InternalSubflow
    style Sub fill:#7c3aed,stroke:#a78bfa,stroke-width:2px,color:#fff
```

***

## 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:

```json theme={null}
{
  "customerType": "Premium",
  "initialDeposit": 1000,
  "currency": "USD"
}
```

### Output Contracts (Subflow $\to$ Parent)

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

```handlebars theme={null}
{{ResponseBinding.ProvisionCustomer.body.customerId}}
{{ResponseBinding.ProvisionCustomer.body.walletId}}
{{ResponseBinding.ProvisionCustomer.body.sessionToken}}
```

***

## 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.