Switch Node
Multi-path routing node that executes different paths based on value matching with support for complex data types
Switch Node
The Switch node provides multi-path routing in your workflows. It evaluates a value against multiple cases and executes the corresponding path when a match is found. It supports deep equality comparison for objects and arrays.
Configuration
Input Schema
| Field | Type | Required | Description |
|---|---|---|---|
switch | JsonValue | Yes | The value to compare against cases |
cases | Case[] | Yes | Array of case objects with matching values |
default | string[] | No | Array of node IDs to execute if no case matches |
Case Object Schema
| Field | Type | Required | Description |
|---|---|---|---|
id | string | Yes | Unique identifier for this case |
case | JsonValue | Yes | Value to match against switch input |
then | string[] | Yes | Node IDs to execute on match |
Output Schema
| Field | Type | Description |
|---|---|---|
output | JsonValue | The original switch value |
Basic Usage
# Status-based routing
- id: order_router
type: switch
input:
switch: "{{ order.status }}"
cases:
- id: pending
case: "pending"
then: ["validate_payment", "check_inventory"]
- id: confirmed
case: "confirmed"
then: ["prepare_shipment"]
- id: shipped
case: "shipped"
then: ["track_package", "notify_customer"]
default: ["log_unknown_status", "manual_review"]Advanced Examples
# HTTP status code handling
- id: http_status_router
type: switch
input:
switch: "{{ response.status }}"
cases:
- id: success
case: 200
then: ["process_data", "cache_result"]
- id: created
case: 201
then: ["process_created", "send_confirmation"]
- id: not_found
case: 404
then: ["log_not_found", "try_alternative"]
- id: server_error
case: 500
then: ["log_error", "retry_request", "notify_admin"]
default: ["handle_unexpected_status"]Perfect for handling API responses, error codes, or any numeric categorization where different values require different processing paths.
# User role and permission routing
- id: permission_router
type: switch
input:
switch: "{{ user.role }}"
cases:
- id: admin_case
case: { "type": "admin", "level": "super" }
then: ["admin_dashboard", "system_management"]
- id: manager_case
case: { "type": "manager", "department": "sales" }
then: ["sales_dashboard", "team_reports"]
- id: user_case
case: { "type": "user", "verified": true }
then: ["user_dashboard"]
default: ["access_denied", "redirect_login"]Use object matching for complex conditions where multiple properties must match exactly. Supports deep equality comparison for nested objects.
# Feature flag routing
- id: feature_router
type: switch
input:
switch: "{{ user.features }}"
cases:
- id: beta_features
case: ["beta", "experimental", "advanced"]
then: ["beta_dashboard", "experimental_features"]
- id: premium_features
case: ["premium", "advanced"]
then: ["premium_dashboard"]
- id: basic_features
case: ["basic"]
then: ["basic_dashboard"]
default: ["default_features"]Match exact array configurations for feature flags, permissions lists, or any scenario where array order and content matter.
Use Cases
Route based on different response types:
- id: api_response_router
type: switch
input:
switch: "{{ api_response.type }}"
cases:
- id: user_data
case: "user"
then: ["process_user", "update_profile"]
- id: product_data
case: "product"
then: ["process_product", "update_catalog"]
- id: order_data
case: "order"
then: ["process_order", "update_inventory"]
default: ["log_unknown_type", "generic_processor"]Perfect for microservices architectures where different services return different data types that require specialized processing.
Handle different content formats:
- id: content_processor
type: switch
input:
switch: "{{ file.type }}"
cases:
- id: image_case
case: "image"
then: ["resize_image", "optimize_quality", "generate_thumbnails"]
- id: video_case
case: "video"
then: ["compress_video", "extract_frames", "generate_preview"]
- id: document_case
case: "document"
then: ["extract_text", "generate_summary", "index_content"]
default: ["unsupported_format", "notify_user"]Essential for media processing workflows where different file types require completely different processing pipelines and tools.
Route based on deployment environment:
- id: env_router
type: switch
input:
switch: "{{ env.NODE_ENV }}"
cases:
- id: development
case: "development"
then: ["dev_config", "debug_logging", "mock_services"]
- id: staging
case: "staging"
then: ["staging_config", "limited_logging"]
- id: production
case: "production"
then: ["prod_config", "error_logging", "monitoring"]
default: ["default_config"]Critical for deployment workflows where different environments require different configurations, logging levels, and service integrations.
Best Practices
- Use meaningful case IDs: Make them self-documenting
- Order cases by likelihood: Put most common cases first
- Always provide a default: Handle unexpected values gracefully
# Good: Clear case organization
cases:
- id: success_response
case: 200
then: ["process_success"]
- id: client_error
case: 400
then: ["handle_client_error"]
- id: server_error
case: 500
then: ["handle_server_error"]
default: ["handle_unknown_error"]
# Avoid: Unclear and incomplete
cases:
- id: case1
case: 200
then: ["node1"]
# Missing default case- Be explicit with types:
"5"vs5are different - Use deep equality for objects: Switch node handles this automatically
- Consider null/undefined cases: Include them explicitly if needed
# Good: Explicit type handling
cases:
- id: string_zero
case: "0"
then: ["handle_string_zero"]
- id: number_zero
case: 0
then: ["handle_number_zero"]
- id: null_case
case: null
then: ["handle_null"]Critical for avoiding subtle bugs in production workflows.
- Limit case count: Too many cases can impact performance
- Use simple values when possible: Complex object matching is slower
- Consider using multiple switch nodes: For complex nested logic
# Good: Simple value matching
switch: "{{ user.status }}"
# Consider restructuring if you have 20+ cases
# Use nested switches or separate logic nodes insteadIntegration Patterns
- id: fetch_data
type: http
input:
url: "{{ api.endpoint }}"
- id: status_handler
type: switch
input:
switch: "{{ fetch_data.output.status }}"
cases:
- id: ok
case: 200
then: ["parse_response"]
- id: unauthorized
case: 401
then: ["refresh_token", "retry_request"]
default: ["handle_error"]Perfect for handling different HTTP response codes and routing to appropriate error handling or success flows.
- id: content_classifier
type: ai
input:
prompt: "Classify this content: {{ content }}"
- id: classification_router
type: switch
input:
switch: "{{ content_classifier.output.category }}"
cases:
- id: spam
case: "spam"
then: ["delete_content", "log_spam"]
- id: appropriate
case: "appropriate"
then: ["approve_content", "publish"]Ideal for content moderation, sentiment analysis routing, and AI-driven decision workflows.
# First level: User type
- id: user_type_router
type: switch
input:
switch: "{{ user.type }}"
cases:
- id: premium
case: "premium"
then: ["premium_feature_router"]
- id: basic
case: "basic"
then: ["basic_feature_router"]
# Second level: Premium features
- id: premium_feature_router
type: switch
input:
switch: "{{ request.feature }}"
cases:
- id: analytics
case: "analytics"
then: ["premium_analytics"]
- id: export
case: "export"
then: ["premium_export"]Essential for complex hierarchical routing with multiple decision layers and nested logic flows.
Troubleshooting
Debugging Tips
# Add logging to debug case matching
- id: debug_switch
type: switch
input:
switch: "{{ debug.log('Switch value:', switchValue) || switchValue }}"
cases:
- id: debug_case
case: "expected"
then: ["log_match_found", "continue_flow"]
default: ["log_no_match", "investigate_value"]The Switch node is powerful for creating complex routing logic that can handle multiple scenarios with clean, maintainable case-based organization.
Last updated on