Switch control
A Switch chooses the next step by comparing variables from the trigger, incoming data, or earlier steps. Use it when an action’s Success and Error outputs are not enough: for example, to route an agent response for manual review or choose a response based on a reported value.
A Switch follows only the first matching route. It does not run several branches or repeat the workflow for each item in a list.
Configure a Switch
- Open a playbook in Automation Studio. Add Switch from the Control palette tab and connect the preceding step to its input.
- Select the Switch. Optionally set its Label to describe the decision.
- Under Bindings, click Edit. Add the source fields you want to compare from Available Sources, give each a Variable name, and click Apply. See Set up bindings.
- Give the first route an Output name, such as
Needs review. - Choose All conditions (AND) or Any condition (OR) in Match.
- For each condition, select a bound Variable, Value type, and Operator. Enter Value when the operator needs one. Values are literal comparisons; this field does not render Jinja templates.
- Use Add condition or Add route as needed. Drag the handle in a route’s header to change its priority; it works when the route is expanded or collapsed.
- Connect the named outputs, Fallback, and Error to their next steps, then save the playbook.
Each Switch supports 1–20 routes, each containing 1–20 conditions. Output names must be unique, contain 1–100 characters, and cannot be Fallback or Error. Renaming or reordering a route preserves its connections. Deleting a connected route asks for confirmation and removes its connection.
How routes are evaluated
Routes are checked from top to bottom. Put more specific routes before more general ones when both could match the same data.
| Output | Selected when |
|---|---|
| A named route | Its condition group matches. Later routes are not checked. |
| Fallback | No route matches. |
| Error | A comparison encounters missing data, an incompatible type, or an invalid date. Later conditions and routes are not checked. |
Within a route, All conditions (AND) stops at the first condition that does not match. Any condition (OR) stops at the first condition that matches. Conditions skipped this way cannot cause an error. There is one condition group per route; groups cannot be nested.
A Switch does not retry failed comparisons. Connect Error to an action that reports or handles unexpected data when that is useful.
Comparison types
The selected variable determines which types and fields the editor can offer. For a dynamic source added through Advanced source path, choose the value type explicitly.
| Value type | Comparisons |
|---|---|
| String | Equals, does not equal, contains, does not contain, starts with, ends with, empty or not empty. Comparisons are case-sensitive. |
| Number | Equals, does not equal, greater than, greater than or equal, less than, less than or equal. |
| Boolean | Is true or is false. |
| Date/time | Equality and ordering. Use ISO 8601 with a timezone, for example 2026-09-14T09:00:00Z. |
| Array | Empty or not empty, contains or does not contain a scalar member, and length comparisons. Member type sets the type for membership comparisons. |
| Object | Empty or not empty. Use a binding to a particular field for other comparisons. |
All types also offer Exists, Does not exist, Is null, and Is not null. Values are not automatically converted: the text "10" is not the number 10, and "true" is not a boolean.
Optional or missing values
Exists matches a present field even when its value is null. Does not exist matches an absent field. Is null matches an explicit null; Is not null requires a present, non-null value. Both null tests return false for an absent field.
Other comparisons require a present value of the selected type. Missing or null data selects Error, including when using Is empty: empty text, arrays, and objects are different from null or absent fields.
To compare an optional value safely, use All conditions (AND) and put Is not null before the comparison on that same variable. If the field is absent or null, the route does not match and the second condition is skipped. A present value of the wrong type still produces Error.
Compare lists
For an array variable, Collection comparison lets you compare the Whole value or compare its items:
| Collection comparison | Meaning | Empty array |
|---|---|---|
| Whole value | Compare the array itself, such as its length or whether it contains a value. | Depends on the operator. |
| At least one item | Match when an item satisfies the comparison. | No match. |
| Every item | Match when all items satisfy the comparison. | Match. |
| None of the items | Match when no item satisfies the comparison. | Match. |
For item comparisons, select an Item field, or use Item itself for lists of simple values. Then choose the item’s value type, operator, and expected value. Custom item field supports fields that are not listed by the selected source. Nested collection comparisons are not supported.
For example, bind the Pushes list from a Push Config Stack step. Select At least one item, choose its Status field, and compare it with the string fail to route when a push failed. The Switch chooses one branch for the complete result; it does not execute a branch per resource.
Item comparisons stop as soon as the result is known. A missing or non-array collection produces Error; an invalid item encountered before the result is known can also produce Error. To require a non-empty list where every item matches, use an AND group with an array-length condition before the Every item condition.
Example: route an agent response
Suppose an agent is instructed to include the literal text manual review when it needs a human decision:
- Connect Run Agent → Success to a Switch.
- In the Switch’s bindings, select Run Agent → Agent response and name the variable
agent_response. - Name the first output
Needs review. Add a String condition:agent_responseContainsmanual review. - Connect Needs review to an Approve control.
- Connect Fallback to the next step for responses without that text, and Error to an action that reports an unusable response.
This is a literal, case-sensitive text test. Configure the agent’s instructions accordingly. Handle the Run Agent action’s own Error output separately if the action cannot produce a response.
Data and run outcomes
A Switch forwards its incoming data unchanged on every output. It does not replace that data with the matched value or the selected route name. Later steps can bind to the same earlier results.
An unconnected named output or Fallback displays Ends run and preserves the incoming run outcome. Successfully evaluating a Switch does not turn an earlier failure into a successful run. An unconnected Error ends the run as Failed. A successful action on a connected error branch can recover the run; another Switch alone cannot clear the failure.
Inspect a routing decision
Open the run from Automate → Runs, then select the Switch in replay. The Inspector shows the chosen output and each condition’s Match, No match, Error, or Not evaluated result, with value previews. Not evaluated means an earlier route or condition already determined the result.
If Fallback was unexpected, check route order, letter case, and expected values. For Error, check the recorded variable, type, and whether the field was absent or null. Run history preserves the labels and conditions used for that execution, even after you edit the playbook. See Runs.
Permissions
Creating or editing a Switch requires app.automation.write and the Automation license feature. Viewing its configuration and run evidence requires app.automation.read.