Summary

The Routing node evaluates a field in the workflow payload and sends execution down a different path depending on what it finds. This guide walks through placing a Routing node, defining output ports, configuring routing rules, and connecting each branch to its downstream steps.

The steps

1
Open the workflow in the Workflow Editor
Navigate to Workflows in the sidebar. Click the workflow you want to add branching to. From the detail page, open the Workflow Editor.
The editor opens in its three-panel layout: the Node Palette on the left, the canvas in the center, and the Properties Panel on the right (visible when a node is selected).
If you are adding a Routing node to an existing workflow, the current graph loads on the canvas. Identify the point in the graph where you want the branch to occur: the node whose output should be evaluated, and the two or more downstream paths that should follow.
Do this
- Click Workflows in the sidebar.
- Click the workflow name to open its detail page.
- Open the Workflow Editor.
- Identify the branch point in the existing graph, or plan the branch point for a new workflow.
Example
A team has a content classification workflow: Start, then Agent Interaction (classifies content into a category field), then End. They want to branch after the Agent Interaction node so that different content categories route to different downstream agents. They open the workflow in the editor and identify the Agent Interaction node as the branch point.
Best practice
- Only Admin and Curate roles can open the Workflow Editor and save versions. If you do not see the editor option, ask your administrator to assign you one of these roles.
- The editor does not auto-save. Make changes deliberately and click Save Version when you are ready to commit. There is no confirmation prompt for unsaved changes, and navigating away will lose your work.
2
Drag a Routing node onto the canvas
In the Node Palette on the left, locate the Routing node. It is listed with a purple color and a GitFork icon. Grab its grip handle and drag it onto the canvas, positioning it at the branch point in your workflow.
When you release the mouse, the Routing node appears on the canvas with its default label "Routing". It has a target handle (top circle, receives incoming edges) and a source handle (bottom circle, sends outgoing edges).
If you are inserting the Routing node between two existing connected nodes, delete the existing edge between them first: click the edge to select it, then press the Delete key. The two nodes are now disconnected and ready to be rewired through the Routing node.
Immediately after placing the node, click it to open the Properties Panel and change the Label to something descriptive, such as "Route by Category" or "Branch on Risk Score". The default label "Routing" is not informative when a workflow contains multiple Routing nodes.
Do this
- Find Routing (purple / GitFork icon) in the Node Palette.
- Drag it onto the canvas at the branch point.
- If inserting between two existing nodes, click the edge between them and press Delete to remove it first.
- Click the node to open the Properties Panel and update the Label to a descriptive name.
Example
The team drags a Routing node onto the canvas between the Agent Interaction node and the End node. They delete the existing edge between those two nodes, then click the Routing node and rename it "Route by Content Category" in the Properties Panel.
Best practice
- Place the Routing node visually between the upstream node and the downstream branch destinations. The canvas is freeform, so layout is for readability, but a clear left-to-right or top-to-bottom arrangement makes the graph easier to follow for future editors.
- Use one Routing node per branch decision. If you need to make two independent decisions (for example, branch on category and then branch on risk score), use two Routing nodes in sequence rather than trying to encode both decisions in one node's port criteria.
3
Connect the upstream node to the Routing node
Hover over the source handle (bottom circle) of the node that runs immediately before the branch point. The handle highlights when you hover over it. Click and drag from that source handle to the target handle (top circle) of the Routing node. Release the mouse over the target handle to create the edge.
An animated line appears connecting the two nodes. Execution will flow from the upstream node into the Routing node, where the branching logic will be evaluated.
Connections must always go from a source handle (bottom) to a target handle (top). You cannot connect source-to-source or target-to-target. If the connection does not form, confirm you are starting from the bottom of the upstream node and releasing on the top of the Routing node.
Do this
- Hover over the source handle (bottom circle) of the upstream node.
- Click and drag to the target handle (top circle) of the Routing node.
- Release to create the edge.
- Confirm an animated line connects the two nodes.
Example
The team hovers over the bottom handle of the Agent Interaction node, drags to the top handle of the "Route by Content Category" Routing node, and releases. An animated line now connects them. Execution will flow from the agent into the Routing node.
Best practice
- If the handles are small at the current zoom level, zoom in using the + button in the controls overlay or the mouse wheel before connecting. Precise handle targeting is easier at higher zoom levels.
- After connecting, click the edge to confirm it is selected and visually traces the correct path. If it connects the wrong nodes, delete it and try again.
4
Configure output ports and routing rules
Click the Routing node to open the Properties Panel. Locate the Routing Configuration section and the Input / Output Ports section. These two sections work together: Routing Configuration lets you describe the branch logic, and Input / Output Ports lets you define the named output ports that edges will connect to.
For each branch you want to create, define an output port. Each port represents one possible execution path. Give each port a descriptive name that reflects the condition it represents, such as high_risk, low_risk, or category_news, category_opinion.
For each output port, configure its routing rule. A routing rule specifies four things:
- Field: the field in the workflow payload to evaluate. Reference the field by its name as it exists in the workflow data at the point the Routing node runs.
- Operator: the comparison to apply to the field value.
- Value: the value to compare against.
- Priority: the order in which rules are evaluated when a workflow instance reaches this node. Lower numbers are evaluated first. The first rule whose criteria are met determines the execution path.
Rules are evaluated in priority order. If no rule matches, execution follows the default port (the port with no rule, or the port configured as the fallback). Design your port set to include a default or catch-all port to handle cases where none of the specific rules match.
Do this
- Click the Routing node to open the Properties Panel.
- Open the Routing Configuration section.
- Open the Input / Output Ports section.
- Define one output port for each branch destination.
- For each port, configure the routing rule: Field, Operator, Value, Priority.
- Add a default or catch-all port to handle unmatched cases.
Example
The team's Agent Interaction node writes a category field into the workflow payload. They define three output ports on the Routing node: category_news (rule: category equals "news", priority 1), category_opinion (rule: category equals "opinion", priority 2), and default (no rule, catch-all, priority 3). Instances where the agent returns "news" will follow the first port; "opinion" will follow the second; anything else will follow the default.
Best practice
- Always include a default or catch-all port. If a workflow instance reaches the Routing node and no rule matches, execution may hang if there is no fallback path. A default port connected to an End node or a notification step ensures every instance has somewhere to go.
- Use priority numbers with gaps (10, 20, 30 rather than 1, 2, 3) so you can insert new rules between existing ones later without renumbering the entire set.
- Keep the field reference consistent with how the upstream node writes it. If the Agent Interaction node writes content_category, the routing rule field must be content_category, not category or contentCategory. A mismatch will cause the rule to never match.
5
Connect each output port to its downstream node
With the output ports defined, connect each port to the appropriate downstream node. Each port represents one branch, and each branch must lead to a downstream node (and ultimately to an End node).
To connect a specific output port to a downstream node, drag from the Routing node's source handle for that port to the target handle (top circle) of the downstream node. If the Routing node has multiple output ports, each port has its own source handle or is selectable when you initiate a connection from the node.
Repeat for each output port until every branch has a downstream connection. Then ensure each branch path eventually reaches an End node. A branch that does not reach an End node may cause instances to hang at runtime.
If the downstream nodes for some branches do not yet exist on the canvas, drag them from the Node Palette now. Common downstream targets for a Routing node:
- Agent Interaction nodes for branches that require different AI processing.
- Human Review nodes for branches that require human judgment.
- API Call nodes for branches that trigger external actions.
- End nodes for branches that terminate the workflow immediately.
Do this
- For each output port on the Routing node, drag an edge to the appropriate downstream node.
- Confirm every port has a connected outgoing edge.
- Confirm every branch path eventually reaches an End node.
- Add any missing downstream nodes from the Node Palette before connecting.
Example
The team drags two Agent Interaction nodes onto the canvas: "News Processing Agent" and "Opinion Processing Agent". They also have an existing End node for the default path. They connect the category_news port to the News Processing Agent, the category_opinion port to the Opinion Processing Agent, and the default port to the End node. Both agent nodes connect to a shared End node after they complete.
Best practice
- Use Information nodes (indigo / Info icon) to label each branch on the canvas. Place an Information node next to each outgoing edge from the Routing node and annotate it with the condition it represents. Information nodes do not affect execution but make the graph self-documenting.
- After connecting all ports, use the Fit View button to zoom out and review the full graph. Confirm the branching structure is visually clear and all paths lead to End nodes before saving.
6
Save the version and test each branch
Click Save Version in the top-right corner of the editor. The editor serializes the full graph into a new immutable workflow version. The previous version is preserved.
After saving, test the branching by triggering workflow instances with payloads that satisfy each routing rule in turn. For each test instance:
1. Trigger the instance with a payload that should satisfy one specific routing rule.
2. Monitor the instance in the Instances section to confirm it follows the expected branch.
3. Repeat for each output port, including the default catch-all.
If a branch does not route as expected, return to the Workflow Editor, click the Routing node, and review the routing rule for that port. Check the field name, operator, value, and priority. Correct the rule, save a new version, and test again.
Do this
- Click Save Version in the top-right corner.
- Trigger a test instance with a payload that satisfies the first routing rule.
- Confirm the instance follows the expected branch in the Instances section.
- Repeat for each output port, including the default catch-all.
- If a branch misfires, review the routing rule in the Properties Panel, correct it, save a new version, and retest.
Example
The team saves the version, then triggers three test instances: one with category: "news", one with category: "opinion", and one with category: "feature" (an unrecognized value). The first two route to the correct agent nodes. The third follows the default port to the End node. All three branches are confirmed working.
Best practice
- Test the default catch-all branch explicitly. It is the branch most likely to be overlooked during testing and the one that matters most when unexpected data arrives in production.
- Each Save Version creates a new version. If testing reveals a problem, fix the routing rule and save again. The previous version remains available if you need to roll back.
- Document the routing logic in the Routing node's Description field or in an adjacent Information node on the canvas. Future editors should not need to reverse-engineer the rule set from the port configuration alone.

What the Routing node does and why it is logic-only

The Routing node is one of DAVE's ten workflow node types. Its purpose is conditional branching: it evaluates the workflow payload at runtime and sends execution down one of several outgoing paths depending on which routing rule is satisfied first.

It is described in the DAVE documentation as a logic-only node. That means it does three things and only three things:

It receives execution from an upstream node.
It evaluates its output port criteria against the current workflow payload.
It sends execution to the downstream node connected to the first matching port.

It does not create a task. It does not invoke an agent. It does not call an API. It does not pause the workflow for human input. It is purely a routing mechanism, and that constraint is intentional: by separating routing logic from functional steps, the Routing node keeps the graph readable and the branching logic auditable.

This separation is the key design principle. Without a dedicated Routing node, branching logic would have to be embedded in functional nodes (agents, API calls, human review steps), mixing concerns and making the workflow harder to understand and modify. The Routing node gives branching logic its own node, its own label, and its own place in the graph.

A Routing node can have any number of output ports. Each port has a routing rule. Rules specify a field, an operator, a value, and a priority. Rules are evaluated in priority order: the first rule whose criteria are met determines the execution path. If no rule matches, execution follows the default port.

When to use a Routing node and when a different node is better

Use a Routing node when you need to branch execution based on data that is already in the workflow payload. The most common cases:

After an AI classification step

An Agent Interaction node classifies content and writes a category, label, or score to the workflow payload. A Routing node reads that field and sends execution to the appropriate downstream agent, review step, or output path. This is the canonical use case: the agent decides, the Routing node routes.

After a human decision that produces structured output

A User Interaction or Human Review node collects a decision from a human and writes it to the workflow payload. A Routing node reads the decision field and branches accordingly. This is useful when the human decision is one of a defined set of values (approved, rejected, escalated) and each value requires a different downstream path.

After an API call that returns a status

An API Call node calls an external service and maps a status field from the response into the workflow payload. A Routing node reads the status field and branches on success, failure, or specific error codes.

When not to use a Routing node

Do not use a Routing node when the branching decision requires human judgment. If a human needs to evaluate the content and choose the path, use a Human Review node: its Approve, Reject, and Request Changes decisions are the branching mechanism, and the task record provides the audit trail. A Routing node is for decisions that can be made by evaluating a field value, not for decisions that require a person.

Do not use a Routing node to replace an Agent Review node. If you need an AI to evaluate content quality and pass or fail it, Agent Review is the right node: it invokes an agent, applies defined criteria, and produces a pass/fail result. A Routing node does not invoke an agent: it only reads fields that already exist in the payload.

How routing rules work: field, operator, value, priority

A routing rule is the condition attached to an output port on a Routing node. When a workflow instance reaches the Routing node, DAVE evaluates each port's rule in priority order and routes execution to the first port whose rule is satisfied.

Each routing rule has four components:

Field

The field in the workflow payload to evaluate. This must match the exact field name as it exists in the payload at the point the Routing node runs. If the upstream Agent Interaction node writes a field called risk_level, the routing rule field must be risk_level. Field name mismatches cause rules to never match, which means execution falls through to the default port or hangs if no default exists.

Operator

The comparison to apply to the field value. The specific operators available are configured in the Routing Configuration section of the Properties Panel. Consult the in-product panel for the full list of supported operators for your workflow version.

Value

The value to compare the field against. For a rule that checks whether risk_level equals "high", the value is "high". Values are matched against the field content as it exists in the payload at runtime.

Priority

The order in which rules are evaluated. Lower priority numbers are evaluated first. When two rules could both match the same payload, the one with the lower priority number wins. Use priority to express specificity: more specific rules get lower numbers (evaluated first), and broader or catch-all rules get higher numbers (evaluated last).

Default port

A port with no rule, or configured as the default, is the fallback: execution follows it when no other rule matches. Every Routing node should have a default port. Without one, an instance that matches no rule may hang at the Routing node with no outgoing path to follow.

Who can build and modify branching workflows

Building and modifying workflows in the Workflow Editor requires one of two roles. DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by your administrator.

Action	Admin	Curate	Others
Open the Workflow Editor	Yes	Yes	No
Add / remove nodes (including Routing)	Yes	Yes	No
Connect / disconnect edges	Yes	Yes	No
Edit node properties and routing rules	Yes	Yes	No
Save a new version	Yes	Yes	No

Create, Use, Reporting, and Financial roles cannot access the Workflow Editor. The editor link is not visible to these roles.

If you need to add or modify a Routing node but do not have the required role, ask your administrator to assign you the Admin or Curate role.

Frequently asked questions

What happens if no routing rule matches?

If a workflow instance reaches a Routing node and no output port rule is satisfied, execution follows the default port if one exists. If no default port is configured and no rule matches, the instance may hang at the Routing node with no outgoing path. Always include a default or catch-all port to prevent this.

Can a Routing node have more than two output ports?

Yes. A Routing node can have any number of output ports. Each port has its own routing rule and connects to its own downstream node. Use as many ports as your branching logic requires.

Can I chain Routing nodes?

Yes. The output of one Routing node can connect to the input of another. This lets you make sequential branching decisions: branch first on category, then branch on risk score within each category. Keep the graph readable by naming each Routing node clearly and using Information nodes to annotate the logic.

Does the Routing node appear in the audit trail?

Yes. Every node execution is recorded in the workflow instance record, including Routing nodes. The audit trail shows which port was followed for each instance, making it possible to verify that branching logic behaved as expected for any given run.

Can I use a Routing node to merge branches back together?

A Routing node is designed for branching, not merging. To converge multiple branches back to a single path, connect the outgoing edges from multiple upstream nodes to the target handle of a single downstream node. The downstream node will execute when execution arrives from any of the upstream branches. You do not need a Routing node to merge: any node can receive edges from multiple upstream nodes.

What is the difference between a Routing node and an Agent Review node?

A Routing node evaluates fields that already exist in the workflow payload. It does not invoke an AI model. An Agent Review node invokes an AI agent to evaluate content against defined criteria and produces a pass/fail result. Use a Routing node when the decision field is already in the payload. Use an Agent Review node when you need an AI to make the evaluation.