Skip to main content
Ingestly branches a workflow at a node’s output ports. A node decides which of its ports fires, and an edge simply carries the run from a port to the next node. Edges themselves hold no rules: to change how a run branches, you configure the source node, not the connection.
Routing used to live on the edge, as a Condition Type you picked after clicking a connection. That model is gone. Every rule now lives on a node, and each outgoing edge is attached to a named port on that node.

​
Port types

A node publishes its ports in the workflow editor as labeled handles on its right edge. Drag from a handle to connect that specific port. Exactly one port fires per step. Branches are mutually exclusive by construction, so unlike the old edge conditions you cannot accidentally fire two paths from one node.
A node can have several edges on the same port. Those all fire together and run in parallel.

​
Branching on a rule: If and Switch

Two nodes exist to branch on your own rules over upstream data.
  • If holds one condition and publishes True and False. Use it for a yes/no split.
  • Switch holds an ordered list of named cases, each with its own condition, and publishes one port per case plus Other. The first matching case wins, and Other is the fallback when none match.
Both pass the incoming data straight through, so downstream nodes still reference the upstream node’s fields, not the If or Switch node.

​
Example: route by document type

Anything that is neither B2B nor B2C leaves the Other port and lands in the review queue.

​
Authoring a condition

If and Switch use the same condition editor. A condition is a group of rules, and each rule has three parts:
  • Field: the value to compare. Type {{ to autocomplete fields from the upstream node (for example, {{parse.payload.invoiceType}}).
  • Operator: the comparison to apply. The list filters by the inferred field type, so numeric operators stay hidden when the field is a string.
  • Value: the literal to compare against. Hidden for unary operators like is empty.
A condition is not limited to the node directly upstream. Type {{ in a Field or Value box to autocomplete from any ancestor node, so you can compare one node’s value against another’s, for example {{extract.payload.total}} != {{reconcile.payload.expectedTotal}}.

​
Operators

The any and all operators let one rule cover a whole collection, for example “all line-item totals are at least 0”.

​
Condition groups

A single rule is often not enough. A condition can nest groups combined with AND or OR, so you can express “amount over 1000 and (region is EU or flagged is true)”.
  • Match all / Match any: the toggle at the top of a group. All requires every child to match (AND); Any requires at least one (OR).
  • Add condition appends a rule; Add group appends a nested group, so you can mix AND and OR at different levels.
  • NOT negates a group, so it matches when the group is not satisfied.
  • Each rule and nested group can be duplicated or deleted.
Groups can nest several levels deep.

​
Routing failures

A step that fails after exhausting its retries fires only its Error port. The default port does not fire, so a failure never continues down the success path. The Error port is hidden until you need it. Turn on Error output in the node’s properties panel to reveal it, then connect it. Once an edge is attached the port stays visible, and the toggle is locked until you remove that edge. If a node fails and nothing is connected to its Error port, the run fails. To let an optional step fail without failing the run, either connect the Error port somewhere or turn on Continue on fail. See retries for what that flag does and does not do.
The Error port never renders inside a loop body, and neither does continue-on-fail. Whether a failing item stops the loop is controlled by the loop’s own If an item fails setting.

​
Branching versus fanning out

Branching picks a path. Fanning out starts more work. They are different tools:
  • If and Switch send one run down one of several paths. The document is unchanged.
  • Split cuts one document into contiguous page groups and starts a child run for each, for example one upload holding five invoices.
  • Classify decides a document’s type by rules or sample documents, and can fan out per class. Reach for it when the decision needs to read the content rather than compare a field.
  • Filter keeps or drops pages within one document. It narrows a run, it never fans one out.
For most “if the document is X, do Y” cases, If or Switch is the right tool.

​
Tips

  • Give Switch cases meaningful names. The name becomes the port label on the canvas, so a well-named case makes the graph readable.
  • Order matters in a Switch. The first matching case wins, so put the most specific case first.
  • Always connect Other when your cases are not exhaustive. A run that matches no case leaves through Other, and stops there if nothing is connected.
  • Keep conditions simple. For complex logic, compute a flag in an upstream transform or variable node and branch on that.
  • Test each branch with a representative document before activating the workflow.