Skip to main content

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​

  1. The action evaluates branch conditions from top to bottom.
  2. When a condition evaluates to true, the action selects that branch and stops evaluating later conditions.
  3. The action runs exactly the selected branch's nested actions.
  4. If no condition matches, the action runs Default.
  5. Nested actions store their results in the same variables the rest of the automation uses.

An empty matching branch still counts as the selected branch. It completes successfully and does not continue to later branches or the default.

Configuration​

FieldDescription
BranchesOrdered branch definitions. Click Add Branch to insert a branch immediately above Default, then use the arrow controls to change conditional branch priority.
ConditionRequired condition configured with the same expression builder used by ordinary action steps.
ActionsNested actions to run when this branch is the first match. Each action can use the same variables as the rest of the automation.
DefaultThe 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​

Actions in the selected branch work with the same variables as the rest of the automation. They can read and update email, custom, global, input, output, and any other data available to the Match action.

Actions run in order within the selected branch. Each action can read values written by earlier actions in that branch. Match does not keep a separate copy of the variables or gather the branch's results into one object; anything a nested action stores stays available after Match finishes.

For example, if the first child action stores a ticket in custom.ticket, the next child action and later automation 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 automation. 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.

  1. Add a Match action and click Add Branch twice to create two conditional branches above Default.
  2. Configure each branch using the table below. Use the Condition expression builder to compare the alert priority with the expected value.
  3. 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.
BranchConditionTicket configuration
Branch 1custom.alertPriority equals CriticalCreate a ticket with your PSA's critical priority and send it to your urgent-response queue.
Branch 2custom.alertPriority equals HighCreate a ticket with your PSA's high priority and send it to the appropriate support queue.
DefaultNo conditionCreate 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 automation 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.

Example: Add a Note If an Open Ticket Exists, Otherwise Create One​

Use Match to keep repeat monitoring alerts on one open ticket. Before Match, use API: Query for One Object to look for the specific open ticket and store the result in custom.ticket. A missing result is expected when the alert needs a new ticket, so leave Generate an exception if no results unchecked.

  1. Add a Match action and click Add Branch once.
  2. Set the branch condition to custom.ticket.id is not empty.
  3. In that branch, add API: Create an Object, select the TicketNote entity, and set TicketID to {{custom.ticket.id}}.
  4. In Default, add the action that creates the ticket.
BranchConditionActions
Branch 1custom.ticket.id is not emptyCreate a TicketNote on {{custom.ticket.id}} using the alert subject and body.
DefaultNo conditionCreate a ticket for the alert.

The first alert finds no open ticket, so Default creates one. Later alerts find that ticket and follow Branch 1 to add a note. See Monitoring Alerts to the Right Autotask Account and Ticket for the complete lookup, customer matching, and ticket creation setup.

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.