Control nodes
Control nodes shape the path execution takes through a flow. Instead of moving or transforming data, they decide what runs next — branching down different paths based on a condition, or repeating a set of nodes for each item in a collection. They are how a single flow handles more than one outcome.
Three control nodes are available today, plus one that is visible but disabled:
- Conditional Branching — split into two paths on a single condition.
- Multiple Condition Branches — route to one of several paths by matching cases.
- For Loop — repeat a set of nodes once per item in a collection.
- Pause Flow Execution — not available.
Permissions. Adding and configuring control nodes is part of building a flow, so it requires the Admin or Partner role. See Users and access.
Conditional Branching
In the Nodes library this node is labelled If.
What it does. Evaluates one condition and sends execution down the true branch or the false branch.
Status: Available.
When to use it. For a simple two-way decision — when something either is or isn't the case and each outcome needs a different path.
Configuration fields
- Left Value — the value to compare, usually a variable mapped from an earlier step (such as an extracted field).
- Operator — equals (default) or not equals.
- Right Value — the value to compare against: a literal you type, or another variable.
Data flow. The node has two outgoing paths. Connect the nodes that should run when the condition is true to one branch, and the nodes for the false case to the other. Both branches see the same flow data the node received.
Outputs. It doesn't produce a data value of its own — its effect is the path taken.
Limits. This node supports equality checks only (equals / not equals). For thresholds, ranges, or confidence checks, use Field Validation and branch on its result.
Example. After classification, branch on document type: if the document type equals FNOL, run the claims-setup path; otherwise send it to a general-handling path.
Common errors. The condition never matches because the two values differ in type or formatting (for example, extra whitespace or different casing); or a branch is left unconnected, so one outcome does nothing.
Related. Multiple Condition Branches, Field Validation.
Multiple Condition Branches
In the Nodes library this node is labelled Switch.
What it does. Evaluates several cases and routes execution down the branch for the first matching case. If nothing matches, it follows the default case.
Status: Available.
When to use it. For a multi-way decision — when an input can fall into one of several categories that each need different handling.
Configuration fields
- Switch Cases — the list of cases. Each case has a name and the condition that selects it; each case is a separate outgoing branch.
- Default Case — the case to use when none of the conditions match. Define one so unmatched items always have somewhere to go.
Data flow. One outgoing branch per case, plus the default branch. Cases are checked in order and the first match wins, so order matters when conditions overlap.
Outputs. The selected case, which you can read downstream, alongside the path taken.
Limits. Only the first matching case runs. Always configure a default branch to catch anything that doesn't match.
Example. Route a mixed inbound batch by document type: an FNOL case to the claim-creation path, a medical bill case to the bill-extraction path, a policy document case to the comparison path, and a default case to Flag for Human Review for anything unrecognized. See Claim Indexing.
Common errors. Items fall through with nowhere to go because no default case is set; or the wrong branch runs because two cases overlap and the earlier one matched first.
Related. Conditional Branching, InsurGPT nodes.
For Loop
In the Nodes library this node is labelled For Loop.
What it does. Iterates over a collection and runs the nodes inside the loop once for each element.
Status: Available.
When to use it. When the same processing must apply to many items — each document in a multi-document file, or each line item in a list.
Configuration fields
- Collection — an expression that returns the array to iterate over. Type
$in the field to see the variables available from earlier steps. - Iterator Variable — the name for the current element inside the loop (default
item). Reference it from the nodes in the loop body. - Index Variable (optional) — the name for the current position, starting at
0.
Data flow. On each pass, the current element (and index, if set) is available to the nodes inside the loop. Iterations run in sequence.
Outputs. The loop runs its body per element; results are produced by the nodes inside it rather than by the loop node itself.
Limits. The Collection expression must resolve to an array; if it resolves to nothing, the loop runs zero times. Iterations are sequential, so very large collections take proportionally longer.
Example. After Split Documents segments a claim file into separate documents, a For Loop iterates over each document and runs extraction and Field Validation on every one. See Claim File Summarization.
Common errors. The loop does nothing because Collection doesn't point at an array; or body nodes can't find the current element because they reference a different name than the Iterator Variable.
Related. InsurGPT nodes, Utility nodes.
Not available
Pause Flow Execution (labelled Sleep in the Nodes library) is visible but disabled. It cannot be added or configured, and has no setup guidance until it is enabled.
| Node | Status |
|---|---|
| Pause Flow Execution | Not available |
Where to go next
- Node catalog — every node and category at a glance.
- Utility nodes — Field Validation, whose results you branch on.
- InsurGPT nodes — classification and splitting that feed branching and loops.
- App integration nodes — the write-back steps each branch leads to.
- Test and debug a draft — confirm branches and loops behave as intended.