maestro
latest
false
Maestro user guide
- Introduction
- Getting started
- Building with Maestro BPMN
- Understanding Maestro BPMN modeling
- Opening the modeling canvas
- Modeling your process
- Aligning and connecting BPMN elements
- Autopilot for Maestro (Preview)
- Process Repository
- Implementing a simple BPMN process
- Implementing a complex BPMN process
- Debugging
- Simulating
- Evaluations (Preview)
- Common implementation scenarios
- Building with Maestro Case
- Introduction to Maestro Case
- Maestro BPMN vs. Maestro Case: when to use case management
- The Maestro Case lifecycle: from event trigger to app experience
- Build your first case with Maestro Case
- Build a Maestro Case with a coding agent (preview)
- Defining case keys (system vs. external)
- Establishing task I/O and write-back contracts
- Exit rules and early stage termination
- Modeling primary and secondary stages
- Triggering a case from Data Fabric
- Implementing stage-level personas and permissions
- Setting SLAs and automated escalation rules
- Configuring a rework loop (re-entry)
- Configuring and testing the Case Manager Agent (preview)
- Case Manager input and output contract
- Maestro Case component dictionary
- Building with Maestro Flow
- Maestro Automate
- Integrations
- Operating
- Monitoring
- Optimizing
- Reference information
Switch node for routing flows to multiple paths based on ordered case conditions.
What it does
Routes a process to one of multiple paths based on ordered conditions. Takes the first match.
When to use this vs Decision
| Use Switch when... | Use Decision when... |
|---|---|
| You have three or more outcomes | You have exactly two outcomes |
| You're routing by multiple distinct conditions | The condition is a simple yes/no |
| You need a default/fallback branch |
Configuration reference
| Field | Required | Default | Description |
|---|---|---|---|
| Cases | Yes | 2 empty cases | Ordered branch list. Each case has a handle label and a JavaScript expression; the first truthy expression is taken. |
| Include default | No | true | Whether to add a Default branch that is taken when no case expression matches. |
Writing case expressions
Each case expression uses the same JavaScript environment as the Script and Decision nodes:
// Case 1 — high priority
$vars.ticket1.output.priority === "high"
// Case 2 — medium priority
$vars.ticket1.output.priority === "medium"
// Case 3 — low priority (or use Default to catch everything else)
$vars.ticket1.output.priority === "low"
// Case 1 — high priority
$vars.ticket1.output.priority === "high"
// Case 2 — medium priority
$vars.ticket1.output.priority === "medium"
// Case 3 — low priority (or use Default to catch everything else)
$vars.ticket1.output.priority === "low"
More specific conditions should appear first. A broader condition higher in the list will match before a more specific one below it.
Examples
Example 1 — Route by HTTP status code
| Case | Expression | Branch |
|---|---|---|
| Success | $vars.httpRequest1.output.statusCode === 200 | → process response |
| Not Found | $vars.httpRequest1.output.statusCode === 404 | → handle missing resource |
| Default | (fallback) | → handle unexpected error |
Example 2 — Route by string value
| Case | Expression | Branch |
|---|---|---|
| Approved | $vars.form1.output.status === "approved" | → continue process |
| Rejected | $vars.form1.output.status === "rejected" | → notify rejection |
| Pending | $vars.form1.output.status === "pending" | → wait for review |
| Default | (fallback) | → handle unknown status |
Related pages
- Decision node — for exactly two branches
- Variables and data flow —
$varssyntax and expression patterns - Error handling — handling failures vs conditional branching