Match
The Match action evaluates an ordered list of conditions and runs one set of nested actions. It runs the first branch whose condition evaluates to true. If no branch matches, it runs the fixed Default branch.
When to Use This Action
Use Match when:
- Several conditions are mutually exclusive
- The order of conditions determines priority
- Each condition needs its own sequence of action steps
- You want a default path when no condition matches
Do not use Match when every true condition should run. Match stops evaluating after the first true expression.
How It Works
- The action evaluates branch conditions from top to bottom.
- When a condition evaluates to true, the action selects that branch and stops evaluating later conditions.
- The action runs exactly the selected branch's nested actions.
- If no condition matches, the action runs Default.
- Nested actions store their results directly in the same available data used by the surrounding workflow.
An empty matching branch still counts as the selected branch. It completes successfully and does not continue to later branches or the default.
Configuration
| Field | Description |
|---|---|
| Branches | Ordered branch definitions. Click Add Branch to insert a branch immediately above Default, then use the arrow controls to change conditional branch priority. |
| Condition | Required condition configured with the same expression builder used by ordinary action steps. |
| Actions | Nested actions to run when this branch is the first match. Each action uses the result namespaces available in the surrounding workflow. |
| Default | The final expandable branch. It always stays at the bottom and cannot be removed or moved. Leave its action list empty for a successful no-op. |
Working with Nested Actions
Selected child actions can read and update the same email, custom, global, input, output, and other data available to the Match action's surrounding workflow context.
Actions run in order within the selected branch. Each action can read values written by earlier actions in that branch. Match does not create an isolated namespace or collect child results into a separate object.
For example, if the first child action stores a ticket in custom.ticket, the next child action and later workflow steps can use {{custom.ticket}}.
Match does not have a Store the results in variable field and does not return a parent result. Configure result variables on the nested actions that produce them.
Example: Create a PSA Ticket Based on Alert Priority
Use Match to create one of three ticket configurations from a monitoring alert: a Critical ticket, a High ticket, or a standard ticket for everything else. Each branch contains its own ticket-creation action, but only one branch runs for each alert.
Before Match, make the alert's priority available to the workflow. For this example, assume an earlier step stores it in custom.alertPriority with values such as Critical or High. Use the field and values your alert source actually provides.
- Add a Match action and click Add Branch twice to create two conditional branches above Default.
- Configure each branch using the table below. Use the Condition expression builder to compare the alert priority with the expected value.
- In each branch's Actions list, add the ticket-creation action for your PSA. Configure the customer, title, description, and other required fields, then choose that branch's ticket priority and queue.
| Branch | Condition | Ticket configuration |
|---|---|---|
| Branch 1 | custom.alertPriority equals Critical | Create a ticket with your PSA's critical priority and send it to your urgent-response queue. |
| Branch 2 | custom.alertPriority equals High | Create a ticket with your PSA's high priority and send it to the appropriate support queue. |
| Default | No condition | Create a ticket with your standard priority and queue for every other alert priority. |
Choose the equivalent priority and queue values configured in your PSA. You can also give each ticket configuration a different title or description, such as a Critical alert: title prefix in Branch 1.
Keep the ticket-creation actions inside the branches, not after Match. A Critical alert runs only Branch 1's ticket action; a High alert runs only Branch 2's ticket action; any other priority runs only Default's ticket action. Match does not create all three tickets.
If later steps need the created ticket, configure all three ticket actions to store their results in the same variable, such as custom.ticket. Steps after Match can then use the selected branch's ticket result without knowing which branch ran.
Test the workflow with a Critical alert, a High alert, and an alert with another priority. Confirm that each run creates exactly one ticket with the expected priority and queue, and check the execution history to see which branch ran.
FAQs
What happens when a condition is incomplete or invalid?
The console rejects an incomplete condition. If a stored generated expression cannot run, Match fails and records the error instead of treating it as false.
Can I leave a condition blank to create a catch-all branch?
No. Every conditional branch requires a condition. Use Default for the catch-all path.
Do retries evaluate the branches again?
No. After Match selects a branch, delayed or retried child actions continue within that branch. Match does not select a different branch.