# Flow Control Nodes

> / Node Designer Applies to Versions: Platform 3.0+ Prerequisites: Basic understanding of Data Flow concepts 1. Overview What are Flow Control Nodes? Flow…

Source: https://www.fuuz.com/help/flow-control-nodes
Last updated: 2026-06-11

Build Apps · Data Flows


Last updated June 11, 2026, 2:07 PM UTC

## 1. Overview

**What are Flow Control Nodes?**

Flow Control nodes manipulate and control the execution path of your data flows. They enable parallel processing, branching, timing control, error handling, and resource locking — providing fine-grained solutions to address even the most complex scenarios without custom code.

**Why are they important?**

Enterprise integrations rarely follow a simple linear path. You may need to query multiple systems simultaneously, wait for external processes, prevent concurrent execution conflicts, or gracefully handle failures. Flow Control nodes provide the orchestration logic that makes complex workflows reliable and maintainable.

### The 10 Flow Control Node Types

| Node Type | Primary Purpose | Best For |
| --- | --- | --- |
| **Broadcast** *(deprecated)* | Stream individual messages from array/object (For-Each) | **Do not use — Remove from existing flows** |
| **Fork** | Execute multiple branches in parallel with same payload | Querying multiple systems simultaneously |
| **Combine** | Recombine messages from Fork or Broadcast | Merging parallel execution results |
| **Collect** | Accumulate messages by time or count | Batching events for bulk processing |
| **Schedule** | Trigger flow on defined frequencies | Scheduled jobs, polling, recurring reports |
| **Delay** | Pause execution for specified time | Rate limiting, waiting for external processes |
| **Mutex Lock** | Acquire exclusive lock on resource | Preventing concurrent processing conflicts |
| **Mutex Unlock** | Release lock acquired by Mutex Lock | Completing locked sections |
| **Try Catch** | Catch and handle errors from downstream nodes | Graceful error handling, logging failures |
| **Throw Error** | Explicitly throw error with custom message | Business rule violations, custom error formatting |

## 2. Broadcast Node (Deprecated)

### Purpose & Use Cases

The Broadcast node outputs a stream of individual messages based on an input array or object. It implements "For-Each" or "Map" style logic, with subsequent nodes operating on each individual element rather than the collection as a whole. Non-object values are wrapped into a single-element array.

> **Important:** The Broadcast node is being deprecated and should NOT be used. If you have any existing flows using the Broadcast node, you should remove it and redesign those flows as soon as possible. Broadcast leads to flows that scale poorly, perform poorly, and are failure prone.

**Why Broadcast Performs Poorly:**

The number of requests made increases drastically with the number of records in the input payload. With the equation (Number of Parts) × (Number of Nodes) = Total Requests:

- 10 Parts × 3 Nodes = 30 requests (acceptable)
- 1,000 Parts × 3 Nodes = 3,000 requests (problematic)
- Using Script Node batching: 3 requests total (optimal)

### Operating Modes

**For-Each Mode (Object Input):** If provided an object, Broadcast sends each property as a single node execution.

**Map Mode (Array Input):** If provided an array of values, Broadcast sends each index of the array as a single node execution.

> **Note:** *Required Alternative* — Use a Script Node to format data for batch operations. Instead of broadcasting 1,000 items through 3 nodes (3,000 requests), format all data in one Script Node and make bulk API calls (3 requests total). All existing Broadcast nodes must be replaced with this pattern.

## 3. Fork Node

### Purpose & Use Cases

The Fork node creates batches of messages based on branches in the flow. Each branch executes in parallel with the full payload passed to the Fork node. This allows flows to run different flow paths on the same payload simultaneously.

The forked branches can be recombined into a single array using a Combine node. When combined, the data from each path is merged into a single Object with the branch name as the property name.

### Configuration Parameters

| Parameter | Description |
| --- | --- |
| Branches | Add one or more branches linked to downstream nodes. Name branches to reflect downstream actions. |

### Fork/Combine Example

**Fork 1 Output:**

```
{"data": {"Parts": [{"Part_No": "P123", "Revision": "A"}]}}
```

**Fork 2 Output:**

```
{"data": {"Customer": {"name": "Acme Industries"}}}
```

**After Combine:**

```
{
  "Fork 1": {"data": {"Parts": [{"Part_No": "P123", "Revision": "A"}]}},
  "Fork 2": {"data": {"Customer": {"name": "Acme Industries"}}}
}
```

> **Tip:** Name your branches descriptively (e.g., "Get Parts", "Get Customer") rather than using default names. This makes the combined output self-documenting.

## 4. Combine Node

### Purpose & Use Cases

The Combine node combines batches of messages created through Fork or Broadcast nodes back into a single message. The default configuration covers most use cases.

### Configuration Parameters

| Parameter | Default | Description |
| --- | --- | --- |
| Timeout (s) | 10 | How long to wait for all messages before erroring (seconds) |
| Payload Combination Strategy | Index | Index (array), Last (single payload), or Merge (combined object) |
| Context Combination Strategy | Last | Index (array), Last (single context), or Merge (combined context) |

## 5. Collect Node

### Purpose & Use Cases

The Collect node collects messages by time or count, emitting an array of collected messages when the threshold is reached. Useful for batching incoming events for bulk processing.

### Configuration Parameters

| Parameter | Description |
| --- | --- |
| Batch Count | Number of messages to collect before emitting |
| Batch Time (ms) | Time in milliseconds to wait before emitting stored messages |
| Payload Combination Strategy | Index (array), Last (single payload), or Merge (combined object) |
| Context Combination Strategy | Index (array), Last (single context), or Merge (combined context) |

> **Important:** Always use Batch Count in combination with Batch Time. If you set Batch Count to 5 but only receive 3 messages, the node will not emit until it receives the other 2 messages. Having both ensures messages are emitted on the timeout as a fallback.

## 6. Schedule Node

### Purpose & Use Cases

The Schedule node is a source node used to issue a payload on a frequency or frequencies defined by Data Flow Schedules. It provides flexible cron-based scheduling with timezone support.

### Configuration

| Parameter | Description |
| --- | --- |
| Configure | Link opens Data Flow Schedule Editor in new browser tab |

The Schedule Editor allows you to configure multiple frequencies with different cron schedules, timezones, and payloads. Key schedule properties include:

- **Name:** Descriptive name for the schedule
- **Active:** Enable/disable the schedule
- **Input Schema:** JSON Schema defining inputs rendered on frequency dialogs
- **Frequencies:** Multiple cron-based schedules with individual payloads

> **Note:** The older Schedule Node V1 is deprecated. Use the new Schedule Node which links to the Data Flow Schedule Editor for more flexible configuration.

## 7. Delay Node

### Purpose & Use Cases

The Delay node pauses execution of the next nodes by a specified time. Useful for rate limiting API calls, waiting for external processes to complete, or implementing polling patterns.

### Configuration Parameters

| Parameter | Description |
| --- | --- |
| Delay (ms) | Time in milliseconds the node should wait before executing next nodes |

## 8. Mutex Lock / Unlock Nodes

### Purpose & Use Cases

The Mutex Lock node blocks execution until an exclusive lock is acquired on a resource. This is useful when you need to ensure a portion of a flow or the entire flow can only run once for a specific resource.

**Example:** You have a flow that runs on a schedule every 1 minute. You don't want the flow to process the same data twice. Use a Mutex Lock node to block the next execution from running if the prior execution is still running.

### Mutex Lock Configuration

| Parameter | Description |
| --- | --- |
| Resource ID | Transformable field indicating the lock name. For flow-level locking, use a hard-coded string. |
| Lock TTL (ms) | How long the lock can be held. Auto-unlocks after this time. Min: 30,000ms, Max: 300,000ms |
| Lock Retries | Retry attempts. Set -1 for infinite retries. Set >0 for specific retry count. |
| Throw Error When Lock Not Acquired | If enabled, throws error when lock cannot be acquired. Otherwise, message is discarded. |

> **Critical:** You MUST add a Mutex Unlock on all terminating routes of the flow, or you risk the lock persisting for the next execution until the Lock TTL expires.

### Mutex Unlock

The Mutex Unlock node releases the last lock placed by a Mutex Lock node. It has no parameters — it automatically releases the most recent lock acquired in the flow.

## 9. Try Catch Node

### Purpose & Use Cases

The Try Catch node catches errors that occur in downstream nodes. When an error occurs on the Try route, nodes linked to the Catch port are executed instead.

When no nodes are linked to the Catch port, the error is thrown and stops flow execution. This also occurs if you had a prior Try Catch node and want to clear it so errors stop execution.

### Node Outputs

| Output | Description |
| --- | --- |
| Try (port) | Normal execution path — link to nodes that may throw errors |
| Catch (port) | Error handling path — link to error handling nodes |
| `$state.lastError` | State property containing the caught error when in the catch branch execution |

> **Important:** Never loop back into the flow from the Catch port. This can create an infinite loop inside the Data Flow if you don't carry an iterator.

## 10. Throw Error Node

### Purpose & Use Cases

The Throw Error node throws a ThrowBindingError which halts execution. The error uses the provided Message, and the data includes an object with an `info` property holding the Error Info parameter value.

**Example:** A Data Flow integrates a Purchase Order with an external system. When creation fails, the error needs to be rethrown with custom formatting after being caught by a Try Catch node.

### Configuration Parameters

| Parameter | Description |
| --- | --- |
| Message | String or transform for dynamic message. E.g., `"PO " & $state.context.purchaseOrder.number & " failed creation"` |
| Error Info | Transformable field for any valid JSON pushed to the error's `info` property |

### Example Output

**Message Transform:** `"PO " & $state.context.purchaseOrder.number & " failed creation"`

**Error Info Transform:** `{"purchaseOrder": $state.context.purchaseOrder}`

**Resulting Error:**

```
{
  "message": "PO 145 failed creation",
  "info": {
    "purchaseOrder": {
      "number": "145",
      "supplier": {"name": "Acme Industries"}
    }
  }
}
```

## 11. Best Practices

### Error Handling Patterns

**Pattern 1: Log and Continue**

Try Catch → (Catch) Log Node → Continue Processing

**Pattern 2: Rethrow with Context**

Try Catch → (Catch) Throw Error (formatted message with `$state.lastError`)

**Pattern 3: Notify on Failure**

Try Catch → (Catch) Send Notification → Log Error

### Concurrency Patterns

**Pattern: Prevent Overlapping Scheduled Executions**

Schedule → Mutex Lock (hard-coded Resource ID) → Process → Mutex Unlock

**Pattern: Resource-Level Locking**

Mutex Lock (Resource ID = `$.orderId`) → Update Order → Mutex Unlock

### Performance Guidelines

- **Remove Broadcast:** Broadcast is deprecated — redesign flows using Script Node batching
- **Use Fork for Parallelism:** Query multiple systems simultaneously, then Combine results
- **Set Reasonable Timeouts:** Combine and lock timeouts should account for expected processing time
- **Always Unlock:** Ensure Mutex Unlock is on ALL terminating paths, including error paths

## 12. Troubleshooting

| Symptom | Likely Cause | Resolution |
| --- | --- | --- |
| Combine node times out | One Fork branch failed or takes too long | Add Try Catch to each branch; increase timeout |
| Collect node never emits | Batch Count set but Batch Time not configured | Always set both Batch Count and Batch Time |
| Mutex lock persists between executions | Mutex Unlock missing on error path | Add Mutex Unlock to ALL terminating paths including Catch |
| Infinite loop in error handler | Catch port loops back into flow without iterator | Never loop from Catch; terminate or log and exit |
| Broadcast flow performs poorly | Broadcast is deprecated and scales poorly | Remove Broadcast node; redesign using Script Node batching |
| `$state.lastError` is empty in Catch | Error occurred before Try Catch was set | Place Try Catch before nodes that may error |

## 13. Related Resources

- Source & Trigger Nodes — Initiating flows and trigger mechanisms
- Transform Nodes — Data format conversion and array manipulation
- Script & Validation Nodes — JSONata and JavaScript custom logic
- Debugging & Context Nodes — Echo, Log, and diagnostic tools
- Data Flow Design Standards — Best practices for flow architecture
- Platform Website: [fuuz.com](https://www.fuuz.com/)

## 14. Revision History

| Version | Date | Author | Description |
| --- | --- | --- | --- |
| 1.0 | 2025-01-01 | Fuuz Documentation Team | Initial release - Complete guide covering all 10 flow control nodes with configuration parameters, examples, best practices, and troubleshooting. |

## See Also

- [Data Flow Nodes Reference](https://www.fuuz.com/help/data-flow-node-reference)
- [Source & Trigger Nodes](https://www.fuuz.com/help/source-trigger-nodes)
- [Transform Nodes](https://www.fuuz.com/help/transform-nodes)
- [Script & Validation Nodes](https://www.fuuz.com/help/script-validation-nodes)
- [Debugging & Context Nodes](https://www.fuuz.com/help/debugging-context-nodes)
- [Flow Schedules](https://www.fuuz.com/help/flow-schedules)

### Need more help?

Ask the Fuuz community, or open a ticket with Fuuz support.

[Ask the community](https://www.fuuz.com/community) [Open a ticket](https://support.fuuz.com/portal/en/newticket)

On this page

[1. Overview](#1-overview)

[2. Broadcast Node (Deprecated)](#2-broadcast-node-deprecated)

[3. Fork Node](#3-fork-node)

[4. Combine Node](#4-combine-node)

[5. Collect Node](#5-collect-node)

[6. Schedule Node](#6-schedule-node)

[7. Delay Node](#7-delay-node)

[8. Mutex Lock / Unlock Nodes](#8-mutex-lock-unlock-nodes)

[9. Try Catch Node](#9-try-catch-node)

[10. Throw Error Node](#10-throw-error-node)

[11. Best Practices](#11-best-practices)

[12. Troubleshooting](#12-troubleshooting)

[13. Related Resources](#13-related-resources)

[14. Revision History](#14-revision-history)

[See Also](#see-also)