Routes Node
Routes Node
The Routes Node is one of the main components of a Spaceflow workflow. It lets you direct flow execution through different paths based on the conditions you define.
What is the Routes Node?
Instead of following a single linear path, the Routes Node lets you build dynamic flows where each execution can take a different direction depending on the data. Use it to:
- Evaluate conditions at a specific point in the flow
- Decide which path the flow should follow
- Handle multiple possible outcomes from a single node
How does it work?
When you add a Routes Node to your flow:
- You define one or more routes (for example, Route 1, Route 2, Route 3).
- For each route, you configure one or more conditions.
- During execution, the system evaluates every condition and directs the flow to all valid routes at once — and, alongside them, to the fallback route.
The node doesn't pick one path: it opens every path that fits.
Node structure
Inside the configuration panel, you'll find the following sections:
Node Name
A text field to identify the node within your flow. Use a clear and descriptive name so it's easy to locate.
Route Conditions
This is where you create and manage your routes:
- Each route (Route 1, Route 2, Route 3…) represents a possible path.
- Click + Add Route to create a new route.
- You can also remove existing routes that are no longer needed.
Fallback Route
The fallback route exists so the flow never stops with an error. Without it, when no condition is met, execution halts with "No condition satisfied and no fallback defined".
A real example of what goes wrong: in a payment flow, the "Bizagi" route and the fallback both pointed to the same task. For every approved payment the system opened two identical tasks — one from the matched route, one from the fallback.
Handling "none of the expected cases"
Since the fallback can't be used to decide, create an explicit route for the empty-field case by comparing against an empty value:
| Route | Condition | Action |
|---|---|---|
| Route 1 | Channel = Email | Send email to the payer |
| Route 2 | Channel = Bizagi | Open a processing task |
| Route 3 | Channel (empty) | Open a processing task |
| Fallback | — | End |
Comparing against an empty value matches a field that was never filled in. That way the "not configured yet" case has its own handling, and the fallback stays what it should be: a safety net.
Practical example
Imagine an approval flow based on the request value:
| Route | Condition | Action |
|---|---|---|
| Route 1 | Value less than $1,000 | Automatic approval |
| Route 2 | Value between $1,000 and $5,000 | Send to manager |
| Route 3 | Value above $5,000 | Send to director |
| Fallback | — | End |
In this scenario the Routes Node opens the path matching the value. The fallback's End is reached too, but since it does nothing, it doesn't interfere.
When to use
Use the Routes Node whenever you need to:
- Create decision points in your flow
- Separate different scenarios into distinct paths
- Automate business rules
- Avoid duplicating entire flows for each variation
Best practices
- Point the fallback at an End node. Never at a task, a write node or an email — and never at a node that is already the target of another route.
- One route, one destination. If two routes lead to the same node and both can match, that node runs twice.
- Name your routes clearly. Use descriptive labels like "Low value" or "High priority" so anyone reading the flow understands each path immediately.
- Always test all paths through the interface, not only through the data: routing mistakes show up as a duplicated task or a task that never opens, and neither produces an error message.
- Check the execution log. The node's result carries
matchedRoutesandnextNodes— that's where you see exactly which paths opened.