Article Type: Node Reference
Audience: Developers, App Admins
Module: Data Flows / Node Designer
Applies to Versions: Platform 3.0+
Prerequisites: Basic understanding of Data Flow concepts

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

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.

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.

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

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"}}}
}

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

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

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

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

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

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

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

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

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

13. Related Resources

• Source & Trigger Nodes Complete Guide - Initiating flows and trigger mechanisms
• Transform Nodes Complete Guide - Data format conversion and array manipulation
• Script Nodes Complete Guide - JSONata and JavaScript custom logic
• Debugging Nodes Complete Guide - Echo, Log, and diagnostic tools
• Data Flow Design Standards - Best practices for flow architecture
• Platform Website: fuuz.com

14. Revision History