How Flows Work
Understanding the execution model helps you build reliable, efficient automations. Learn how nodes execute, how data flows between them, and how errors are handled.
Execution Model
Flow Execution Lifecycle
A trigger (Webhook, Schedule, or Table Event) receives data and initiates the flow execution.
System finds all nodes reachable from trigger. Orphaned nodes (not connected) are skipped.
Nodes execute in order following the edges. Each node's output becomes available to downstream nodes.
Execution finishes when all branches complete. Results are saved to execution history.
Test Mode
For development and testing. Uses pinned data on triggers for consistent testing.
- • Click "Run" button to execute
- • Uses pinned data if available
- • Real-time node status updates
- • View execution results instantly
Live Mode
For production. Runs automatically when triggers fire with real data.
- • Executes on real trigger events
- • Runs in background
- • Logged in execution history
- • Enable "Listen" to watch live executions
Bundles & Data Flow
Data in flows is organized into bundles. A bundle is a single unit of data that moves through the flow. When working with arrays, iterators split them into individual bundles for processing.
{
items: [
{ name: "A" },
{ name: "B" },
{ name: "C" }
]
}Each downstream node runs 3 times (once per bundle):
Execution Patterns
Bundle-First (Default)
Bundle 1 → Branch A → Branch B Bundle 2 → Branch A → Branch B Bundle 3 → Branch A → Branch B
Each bundle completes all branches before the next bundle starts. Best for maintaining data consistency.
Branch-First Iterator
Branch A: Bundle 1,2,3 Branch B: Bundle 1,2,3
Each branch processes all bundles before moving to next branch. Good for rate-limited APIs.
Parallel Execution
Branch A: 1,2,3 ⟩ run at Branch B: 1,2,3 ⟩ same time
All branches run simultaneously, each processing bundles in sequence. Fastest for independent operations.
Accessing Node Output
Each node's output is stored and can be accessed by downstream nodes using template syntax.
Node Output Reference
Reference node #1's output field
Nested Data
Access nested properties with dots
Inside Iterators
{{iterator.item}}Current item
{{iterator.index}}0-based index
{{iterator.total}}Total bundles
Execution Globals
$executionId$userId$flowId$triggerIdError Handling
When a node fails, the flow's behavior depends on whether error handling is configured.
Without Error Handler
When a node fails and no error handler is attached:
- Execution stops immediately
- Downstream nodes don't run
- Flow status = FAILED
- Error saved to execution log
Node 3 never executes
With Error Handler
When a node has an error handler attached:
- Error handler receives error details
- Can route to recovery branch
- Other branches continue
- Flow status = PARTIAL (if some succeed)
Error handler processes the failure
Error Information Available
{
"error": true,
"message": "API request failed: 404 Not Found",
"code": "NOT_FOUND",
"nodeId": "node_abc123",
"nodeName": "Get Customer",
"timestamp": "2024-01-15T10:30:00Z"
}Stopping Execution
Manual Stop
Click the Stop button during execution to cancel. The current node will complete, but no new nodes will start.
Break Iteration
Use the "Break Iteration" utility to conditionally stop processing remaining bundles.
Stop when {{iterator.item.status}} = "found"Execution Status
Execution in progress
All nodes completed
Some nodes failed
Critical error occurred
Best Practices
Performance
- Use Bundle Limit to cap iterations
- Use Parallel Execution for independent operations
- Use Branch-First for rate-limited APIs
Reliability
- Add error handlers to critical nodes
- Use IF nodes to validate data before processing
- Test flows with pinned data before enabling