Switch Node

The Switch node routes a workflow down one of several paths based on a list of conditions. Think of it as the multi-way version of the Condition node: instead of a single true/false split, you define an ordered list of cases and the workflow follows the first one that matches.

Overview

Use a Switch node when a single value can take many forms and each form needs its own downstream path:

  • Route a ticket by priority — critical, high, normal, low
  • Send an order down a different flow per region or tier
  • Branch on a status field with a catch-all for anything unexpected
  • Replace a long chain of Condition nodes with one tidy node

How It Works

A Switch node holds an ordered list of cases. Each case has:

  • A label (a friendly name shown on the node and its output)
  • A boolean expression evaluated against the incoming data

When the node runs, it checks each case from top to bottom. The first case whose expression is true wins, and the workflow continues from that case's output only. Cases below the winner are not evaluated.

If no case matches, an optional Default output catches the leftover path. Toggle Default on when you want a guaranteed fallback; leave it off when an unmatched input should simply stop on that branch.

One Output Per Case

Each case is its own connection point on the node, and so is Default. You wire each one to wherever that path should go:

Switch ─ [active]    → Onboarding flow
       ─ [trial]     → Trial reminder
       ─ [cancelled] → Win-back flow
       ─ [Default]   → Log unknown status

A single case can branch to several downstream nodes — just draw more than one connection from that case's output.

Writing Case Expressions

Case expressions are JavaScript, evaluated in the same safe, restricted sandbox used by the Condition node and connection guards. They can read your data but have no access to the host system, so they are safe to run.

Reading the Input

// The whole incoming value
input

// A field on the incoming object
input.value
input.status
input.score

Example Cases

// Case "Active": account is active
input.status === 'active'

// Case "High score": numeric comparison
input.score > 80

// Case "Premium": compare against a stored variable
input.tier === vars['premiumTier']

// Case "Bulk order": combine conditions
input.quantity >= 100 && input.region === 'EU'

Referencing Other Values

Switch expressions can reach beyond the immediate input:

// Environment variables
input.region === '{{env.HOME_REGION}}'

// Any earlier node's output, by node name
input.amount > {{node['Budget'].limit}}

// Workflow variables (from a Set Variable node)
input.amount > vars['threshold']
input.tier === vars['premiumTier']

You can also reference workflow variables with the {{vars['name']}} form inside any text field, and vars['name'] directly inside Code and Condition/Switch expressions.

Ordering Matters

Because the first match wins, order your cases from most specific to most general:

// ✅ Specific first
// Case 1 "VIP":      input.tier === 'vip'
// Case 2 "Premium":  input.tier === 'premium' || input.spend > 1000
// Case 3 "Standard": true   ← acts like a catch-all

// ❌ A broad case placed first will swallow the specific ones below it

If you add a true case at the bottom it behaves like a catch-all; alternatively, turn on the Default output for the same effect with a clearer label.

Common Patterns

Status Routing

// Case "New":        input.status === 'new'
// Case "In Progress": input.status === 'in_progress'
// Case "Done":       input.status === 'done'
// Default:           anything unexpected → review queue

Tiered Thresholds

// Case "Critical": input.amount > 10000
// Case "Large":    input.amount > 1000
// Case "Normal":   input.amount > 0
// Default:         zero or missing → hold

Category Dispatch

// Case "Sales":     input.department === 'sales'
// Case "Support":   input.department === 'support'
// Case "Technical": input.department === 'technical'
// Default:          general inbox

Best Practices

  1. Order specific to general — the first match wins, so put narrow cases before broad ones.
  2. Label each case clearly — labels appear on the node outputs and make the canvas easy to read.
  3. Use Default for safety — turn it on so unexpected values have somewhere to go instead of silently stopping.
  4. Keep expressions simple — a few comparisons each; if a case needs heavy logic, compute a flag in a Code node upstream and switch on that.
  5. Guard against missing fields — use optional chaining (input?.user?.tier === 'gold') when a field may be absent.

Related Topics