Portal Community

Example 1: Order Status Routing

Route orders to different processing pipelines based on their current status. Each status maps to a dedicated set of downstream nodes that handle notifications, integrations, and state transitions appropriate to that status.

{
  "node_type": "Switch",
  "node_id": "RouteByOrderStatus",
  "config": {
    "expression": "$var.orderStatus",
    "cases": {
      "pending":  "pendingApprovalFlow",
      "approved": "fulfilmentFlow",
      "rejected": "rejectionNotifyFlow",
      "shipped":  "shippingTrackingFlow"
    },
    "default_port": "unknownStatusAlert"
  }
}

Expected outcome: An order with status "approved" routes to fulfilmentFlow. A status of "cancelled" (an unexpected value) routes to unknownStatusAlert where an ops team notification is triggered.

Example 2: Customer Region Routing

Apply different tax calculations, billing currencies, and regulatory compliance steps based on the customer's geographic region. Each region has distinct legal and financial requirements.

{
  "node_type": "Switch",
  "node_id": "RouteByRegion",
  "config": {
    "expression": "$ctx.customer.region",
    "cases": {
      "UK":   "ukComplianceFlow",
      "EU":   "euVatFlow",
      "US":   "usSalesTaxFlow",
      "APAC": "apacBillingFlow"
    },
    "default_port": "defaultRegionFlow"
  }
}

Expected outcome: A customer with region: "EU" enters the EU VAT calculation flow, which applies the correct VAT rate and generates an EU-compliant invoice. Customers in regions not yet mapped route to the default flow where a manual review is flagged.

Example 3: Support Ticket Priority Routing

Distribute incoming support tickets to the correct team and SLA timer based on assigned priority. Critical tickets require immediate on-call paging; lower priorities join standard queues.

{
  "node_type": "Switch",
  "node_id": "RouteByTicketPriority",
  "config": {
    "expression": "$input.priority",
    "cases": {
      "critical": "onCallPageFlow",
      "high":     "urgentQueueFlow",
      "medium":   "standardQueueFlow",
      "low":      "lowPriorityQueueFlow"
    },
    "default_port": "defaultPriorityFlow"
  }
}

Expected outcome: A ticket with priority: "critical" immediately pages the on-call engineer via PagerDuty integration and starts a 15-minute SLA timer. A "low" priority ticket joins the standard backlog queue with no time-critical escalation.

Example 4: Document Type Processing

Route document uploads to the appropriate OCR extraction and validation pipeline based on the document classification result from a preceding AI classification node.

{
  "node_type": "Switch",
  "node_id": "RouteByDocumentType",
  "config": {
    "expression": "$output.ClassifyDocument.document_type",
    "cases": {
      "invoice":        "invoiceExtractionFlow",
      "contract":       "contractReviewFlow",
      "purchase_order": "poProcessingFlow",
      "delivery_note":  "deliveryConfirmFlow"
    },
    "default_port": "manualReviewFlow"
  }
}

Expected outcome: Documents classified as "invoice" proceed to the invoice extraction pipeline that reads line items, totals, and supplier details. Unrecognised document types route to manual review where a human agent classifies and processes them.

Example 5: Case-Normalised Expression

When source data contains inconsistent casing (e.g., "Pending", "PENDING", "pending"), normalise the expression result using JavaScript's toLowerCase() before matching.

{
  "node_type": "Switch",
  "node_id": "RouteByNormalisedStatus",
  "config": {
    "expression": "$var.rawStatus.toLowerCase()",
    "cases": {
      "pending":  "pendingFlow",
      "active":   "activeFlow",
      "inactive": "inactiveFlow",
      "archived": "archiveFlow"
    },
    "default_port": "unrecognisedStatusFlow"
  }
}

Expected outcome: Whether the incoming status is "PENDING", "Pending", or "pending", the expression normalises it to lowercase before matching, ensuring consistent routing regardless of how upstream systems format enumeration values.