Skip to main content
Subflows enable you to break complex workflows into modular, reusable components. Think of them as “functions” that can be called from other workflows, promoting code reuse and cleaner workflow design.

What are Subflows?

A subflow is a workflow that can be invoked from another workflow. It:
  • Accepts inputs from the parent workflow
  • Executes its own nodes independently
  • Returns outputs back to the parent workflow
  • Can be reused across multiple workflows

Benefits

Modularity: Break complex workflows into manageable pieces Reusability: Build once, use in many workflows Maintainability: Update logic in one place, affects all usages Clarity: Keep parent workflows clean and readable Testing: Test components independently Collaboration: Team members can own specific subflows

Subflow Node Types

The modern, recommended way to use subflows. Features:
  • Isolated execution context (own result pool)
  • Proper error propagation
  • Resume support (works with HITL)
  • Nested subflows (unlimited depth)
  • Progress mirroring to parent
  • Efficient parallel execution
Use Cases:
  • Production workflows
  • Complex nested logic
  • Human-in-the-loop workflows
  • Workflows requiring resume capability

Subflow Node (Legacy)

The older implementation, still supported for legacy workflows. Features:
  • Flattens subflow into parent graph
  • Shared result pool
  • Simpler execution model
Limitations:
  • No isolation between parent and child
  • Resume issues with HITL
  • Harder to debug
  • No nested subflow support
Recommendation: Use Invoke Subflow V2 for all new workflows.

Creating a Subflow

Step 1: Design the Subflow

Identify logic to extract:
  • Repeated operations
  • Complex multi-step processes
  • Domain-specific logic
  • Reusable components
Example: Customer data enrichment

Step 2: Create the Subflow Workflow

  1. Create a new workflow
  2. Add Input Node for each subflow input
  3. Build the subflow logic
  4. Add Output Node for each subflow output
  5. Test the subflow independently
Example Subflow: “Enrich Customer”

Step 3: Use the Subflow

In your parent workflow:
  1. Add Invoke Subflow Node
  2. Select the subflow workflow
  3. Map inputs to subflow input nodes
  4. Connect subflow outputs to downstream nodes

Input and Output Mapping

Defining Subflow Inputs

Use Input Nodes in the subflow:
Multiple inputs:

Defining Subflow Outputs

Use Output Nodes in the subflow:
Multiple outputs:

Mapping in Parent Workflow

When you add an Invoke Subflow Node: Inputs automatically appear based on subflow Input nodes:
Outputs automatically appear based on subflow Output nodes:

Execution Model

Isolated Execution

Invoke Subflow V2 runs in an isolated context: Parent Workflow:
Subflow Execution:
Subflow cannot access parent results directly, only through inputs.

Shared TaskRunner

While result pools are isolated, subflows share the parent’s TaskRunner:
  • Efficient resource usage
  • Parallel execution across parent and subflow
  • Respects concurrency limits globally

Progress Mirroring

Subflow progress updates reflect in the parent:
  • Parent UI shows subflow execution
  • Real-time status updates
  • Error states propagated

Common Patterns

Pattern 1: Data Enrichment

Subflow: Enrich single record Parent: Iterate over list

Pattern 2: Multi-Stage Processing

Subflow 1: Extract data Subflow 2: Validate data Subflow 3: Transform data Parent: Orchestrate the pipeline

Pattern 3: Conditional Subflow Execution

Subflows: Different processing logic Parent: Route to appropriate subflow

Pattern 4: Retry Logic

Subflow: Operation that might fail Parent: Retry on failure

Pattern 5: Parallel Processing

Subflows: Independent operations Parent: Execute in parallel

Nested Subflows

Invoke Subflow V2 supports unlimited nesting depth:
Use Cases:
  • Complex hierarchical logic
  • Deeply modular designs
  • Recursive-like processing
Considerations:
  • Each level adds execution overhead
  • Debugging nested flows requires drilling down
  • Keep nesting reasonable (3-4 levels max recommended)

Error Handling

Error Propagation

Errors in subflows propagate to the parent:

Continue on Error

Configure Invoke Subflow Node with “continue on error”:
  • Subflow errors don’t stop parent
  • Outputs are empty/default values
  • Check for success downstream with conditionals

Error Context

Errors include subflow context:

Human-in-the-Loop with Subflows

Subflows can include HITL nodes:
Parent Workflow:
Key Feature: Invoke Subflow V2 properly handles workflow pause/resume for HITL.

Performance Considerations

Overhead

Subflows add small execution overhead:
  • Subflow lookup/initialization
  • Input/output mapping
  • State management
Impact: Negligible for most workflows (<100ms) Optimization: Don’t overuse subflows for trivial operations (e.g., simple text concatenation)

Parallel Execution

Subflows leverage parallel execution:
  • Multiple subflow invocations run concurrently
  • Independent nodes within subflow run in parallel
  • Efficient use of worker resources

List Iteration

When a list connects to a non-list subflow input:
  • Subflow executes once per list item
  • Items processed in parallel (up to concurrency limit)
  • Results consolidated into list

Debugging Subflows

Testing Independently

Test subflows standalone before using in parent:
  1. Open subflow workflow
  2. Provide test input values
  3. Run and verify outputs
  4. Fix issues before integrating

Execution Logs

View subflow execution in run history:
  • Drill down into subflow execution
  • See all node results within subflow
  • Identify where failures occurred

Progress Tracking

Monitor subflow progress in real-time:
  • Parent workflow shows subflow status
  • Real-time updates as subflow executes
  • Visual feedback on current subflow node

Best Practices

Design

Single Responsibility: Each subflow should do one thing well Clear Inputs/Outputs: Descriptive names, clear types Self-Contained: Subflows shouldn’t rely on parent workflow context beyond inputs Reusability: Design for reuse, not just extraction

Naming

Descriptive Names: “Enrich Customer Data” not “Subflow 1” Verb-Based: Use action verbs (Process, Validate, Transform, Enrich) Domain-Specific: Reflect business logic (Approve Loan, Score Lead, Send Invoice)

Organization

Folder Structure: Group related subflows in workspace folders Documentation: Add descriptions to subflow workflows Versioning: Consider naming conventions for versions (V1, V2) if making breaking changes

Testing

Unit Test Subflows: Test each subflow independently Integration Test Parents: Test full workflow with subflows Edge Cases: Test with empty inputs, invalid data, errors

Migration from Legacy Subflow Node

To migrate legacy subflows to Invoke Subflow V2:
  1. Identify Legacy Subflow Nodes: Find workflows using old Subflow node
  2. Replace Node: Swap with Invoke Subflow V2 node
  3. Remap Inputs/Outputs: Connect same inputs/outputs
  4. Test Thoroughly: Verify behavior matches
  5. Handle State Differences: Isolated state may require adjustments
Breaking Changes:
  • Subflow can’t access parent result pool (pass data via inputs)
  • Different error handling (proper propagation)
  • HITL behavior improved (may need to adjust logic)

Example: Customer Onboarding Subflow

Subflow Workflow: “Onboard Customer”

Inputs:
  • customer_email: Email address
  • company_name: Company name
  • plan_tier: Plan level (free, pro, enterprise)
Logic:

Parent Workflow: “Bulk Customer Onboarding”

Example: Multi-Stage Document Processing

Subflow 1: “Extract Document Metadata”

Inputs: document_file Outputs: title, author, date, page_count

Subflow 2: “Classify Document”

Inputs: document_text, metadata Outputs: category, tags, confidence

Subflow 3: “Index Document”

Inputs: document_file, metadata, category Outputs: kb_document_id, indexed_at

Parent Workflow: “Document Processing Pipeline”

Next Steps

Conditionals

Control flow with conditional branching

Loops

Iterate with loop nodes

Error Handling

Handle errors and failures gracefully

List Handling

Understand automatic list iteration

Subflows are essential for building maintainable, scalable workflows. Master them to create modular, reusable automation components.