Portal Community
What it does: The Switch node evaluates an expression and compares the result (as a string) against a set of configured cases. Each case maps to a named output port. When a match is found, execution is routed to that port's downstream nodes. If no case matches, execution falls through to an optional default port. This enables clean multi-way branching without chaining multiple If Condition nodes.

Key Capabilities

Business Benefits

Business processes frequently branch into more than two paths. An order might have four possible statuses — pending, approved, rejected, or shipped — each requiring a completely different set of downstream actions. Using chained If Condition nodes for this creates a deeply nested, hard-to-read workflow graph. The Switch node solves this with a flat, parallel case structure that maps each possible value directly to the appropriate output path.

When business rules change — such as adding a new order status or a new customer region — the Switch node makes updates straightforward. Add a new case entry to the configuration and connect its port to the new handling nodes. No existing cases are affected, reducing the risk of regressions when extending workflow logic.

The default port provides a safety net for unexpected values. Rather than silently ignoring unrecognised cases, you can route them to a dedicated error-handling or logging path. This is especially valuable when the expression evaluates data from external systems where new enumeration values might be introduced without notice.

Teams that migrate from chained If nodes to Switch nodes consistently report shorter workflow definition files, easier peer review of business logic, and faster onboarding for new developers who need to understand the routing logic.

Use Cases

Route by Order Status

An order management system processes orders in different states: pending, approved, rejected, and shipped. Each state triggers a different set of notifications, system updates, and API calls. A Switch node on $var.orderStatus routes each state to its own dedicated processing path cleanly.

Route by Customer Region

A B2B SaaS platform must apply different tax rules, billing currencies, and compliance checks for customers in different regions: UK, EU, US, and APAC. A Switch node on $ctx.customer.region fans out to four separate compliance and billing paths without any conditional nesting.

Route by Priority Level

A support ticket system routes incoming tickets based on priority: critical, high, medium, and low. Critical tickets page an on-call engineer immediately. High priority tickets are assigned within one hour. Medium and low tickets join the standard queue. Each path has different SLA timers and escalation rules.

Route by Document Type

A document processing workflow receives uploads of varying types — invoices, contracts, purchase orders, and delivery notes. Each document type requires different extraction logic, validation rules, and downstream integrations. Switch on $var.documentType sends each to the appropriate specialist processing pipeline.

In This Guide

Configuration

How to configure the expression, cases dictionary, default port, and understand string matching behaviour.

Input & Output

Dynamic output port structure, what data flows through each port, and how to connect downstream nodes.

Examples

Configuration examples for order status routing, region-based logic, priority levels, and default fallback handling.