Getting Started with Ticketing Automation Rules

Ticket automation rules enable you to automate repeatable, consistent actions, such as automatically assigning a ticket to a group, changing its priority, and applying a workflow. Automation rules can reduce the time technicians spend processing tickets. For example, if a technician assigns 20 similar tickets to the same group every week, you can create a rule to automatically assign tickets that match those criteria to the appropriate group.

In this article, we'll cover:

• What Are Automation Rules?
• How Automation Rules are Evaluated
• Configuring Automation Rules
  • Create a New Automation Rule
  • Configure the Automation Conditions
  • Configure the Automation Actions
  • Available Automation Actions
• Example Rules
• Automation Rule Best Practices
• Common Issues and How to Resolve Them

What Are Automation Rules?

Automation rules are pre-configured processes that automatically perform actions on tickets when specific conditions are met. They can significantly reduce manual ticket processing time by handling repetitive tasks such as assigning tickets to groups, adjusting priorities, and applying workflows.

Each Ticketing application has its own set of automation rules, which function as a preconfigured series of steps applied when a ticket is created or modified.

Key Components:

• Evaluation Order - Determines the sequence in which rules are processed (lowest to highest)
• Conditions - Criteria that must be met for the rule to execute (based on ticket field values)
• Actions - Changes applied to the ticket or actions taken when conditions are met
• Stop on Match - Optional setting to stop processing further automation rules when this rule matches

When Automation Rules Apply

Automation rules can be configured to run:

• On ticket creation - After a ticket is created
• On ticket modification - Each time a ticket is altered in any way
• Both - On creation and any subsequent modifications

How Automation Rules are Evaluated

When a ticket is created or modified, TeamDynamix evaluates automation rules in a specific sequence:

1. Capture ticket state - The system records all current field values at the moment the ticket is created or modified
2. Process rules in order - Rules are evaluated from lowest to highest numbered evaluation order
3. Check conditions - Each rule's conditions are compared against the captured ticket state
4. Execute actions - If conditions match, the rule's actions are performed
5. Stop or continue - If "Stop on Match" is enabled, evaluation stops; otherwise, it continues to the next rule

The evaluation order determines the sequence in which the rules are looked at for a match, from lowest to highest. Multiple rules can be configured for the same field, with different actions for different values. For example, one rule might apply to tickets with Priority = High, and another to those with Priority = Medium. The action would execute for whichever of the two rules matched the value in the ticket's Priority field.

Note that multiple rules can run against the same ticket during a single triggering event.  Meaning if rule 1 and rule 5 both match to the ticket's conditions, both rules can potentially be applied.  See more on conflicting rules below. 

If a rule is set to "Stop on Match", this means that if this rule's conditions are met, no rules after it will be evaluated.  For this reason, we suggest that you carefully apply "Stop on Match" to rules that supersede all other actions.  

Example Rule Set

Here is an example set of rules illustrating evaluation order, criteria, and actions:

• Rule 1, evaluation order 0 – If the Requestor is in group "VIP", route ticket to senior team members to service the ticket; stop on match to avoid any other action.
• Rule 2, evaluation order 1 – If the Priority is equal to Low, apply the Level 1 SLA
• Rule 3, evaluation order 1 – If the Priority is equal to Medium, apply the Level 2 SLA.
• Rule 4, evaluation order 1 – If the Priority is equal to High or Critical, apply the Level 3 SLA.
• Rule 5, evaluation order 100 – If the Service is equal to New Account, assign to Workflow Account Provisioning Workflow and notify Identity and Access group.
• Rule 6, evaluation order 200 – If the Classification is Incident or Service Request, assign the ticket Responsibility to group "Helpdesk"
• Rule 7, evaluation order 200 - If the Service Category is "Network Support", assign the ticket Responsibility to group "Network Team"

Two or More Rules with the Same Evaluation Order

If you have two or more rules with the same evaluation order, the rules will be evaluated in alphabetical order.  When viewing the rules in your system without filtering, they will be listed top to bottom.  That visual layout is exactly how they will be evaluated.  It is suggested to break out evaluation order into blocks of evaluation to keep it clear where groupings of actions live.  In our examples above, we are using the following structure:

• 0 = Critical "Stop on Match" rules; no standard actions should apply (extreme exceptions)
• 1 = Extremely generalized rules; rules that should apply to most/all tickets (e.g. SLA assignment)
• 100 = Assignment of Workflows and Task Templates
• 200 = Responsibility routing rules

Multiple Rule Matching

 It is possible for multiple rules to match on the same ticket, and all rules be applied.  This is extremely helpful as it means you can program your rules in chunks.  As shown in the example structure above, you can set up levels of rule functionality such as SLA assignment, Workflow assignment, and Responsibility routing and have them work harmoniously so you do not need to program a rule for every specific situation.  It is important, however, to understand Matching Conflicts.  

Matching Conflicts

When more than 1 rule applies to a ticket, the system will queue up all the potential actions.  All actions with no competition will be applied to the ticket.  However, if there is conflicting action, those individual actions will be compared against their rules evaluation order first, then their alphabetical order. For example:

• Ticket 234876 is created with a Low Priority, Incident Classification, and was requested through the Service Category of "Network Support"
• The Low Priority will match to Rule #2, the action here is to apply Level 1 SLA
• The Classification of Incident will match to Rule #6, the action here is to assign ticket Responsibility to the group "Helpdesk"
• The Service Category will match to rule #7, the action here is to assign the ticket Responsibility to the group "Network Team"
• Rule #2's actions (apply SLA Level 1) have no conflicts and will proceed
• Rule #6 and #7, however, have conflicting action to assign Responsibility to different groups
• The system will evaluate the order of the rules and find that, while they have the same evaluation order value (200), rule #7 is alphabetically higher and thus farther down the list
• Rule #7's action will win and the ticket Responsibility will be assigned to the group "Network Team" along with Rule #2's SLA assignment.

NOTE:  Only conflicting actions are negated, NOT entire rules.  Meaning in our example here if rule #6 also were taking another action besides assigning ticket Responsibility that action COULD still be applied.  For example, let's look at a slight change to rule 6 (in bold):

• The Classification of Incident will match to Rule #6, the action here is to assign ticket Responsibility to the group "Helpdesk" AND add Task Template "Incident Tasks"
• The Service Category will match to rule #7, the action here is to assign the ticket Responsibility to the group "Network Team"
• The group assignment actions conflict and are evaluated; #7 is higher in the sort list and wins = ticket is assigned to "Network Team"
• BUT, the action to add the Task Template "Incident Tasks" is not in conflict with anything and that part of rule #6 still succeeds and the ticket is also given the Task Template

Automation Criteria Use the Ticket's Values at the Start of Rule Evaluation 

If an automation rule changes a value in a ticket, subsequent automation rule criteria will continue to evaluate against the original ticket value.

Consider this scenario:

• Ticket 123 is created with Priority set to "Low," and Responsible set to "" (i.e., responsible is blank)
• Automation Rule #1 has the criteria: "if Priority is Low" then "set responsible to Group X"
• Automation Rule #2 has the criteria: "If responsible is Group X" then "set SLA to Group X SLA"

In the above scenario, ticket 123's Automation rule #1 matches and sets the Responsible value to Group X.  Automation rule #2 DOES NOT match.  Even though this rule evaluation loop is going to set the Responsible value to "Group X", the tickets values at the start of this evaluation loop did NOT have the matching "Group X" value and will not match. 

If, however, Rule #2 allowed match on Modification or Both, then the rule could potentially match later in its life cycle.  For example if the ticket is updated from New to In Process and the Group X is still responsible from being set by rule #1 at creation, then the rules would get triggered again and this time the inbound trigger DOES have the "Group X" value present and rule #2 could match and apply the SLA. 

Configuring Automation Rules

Create a New Automation Rule

To create a new rule:

1. Open the Automation Rules configuration page:
   • Ticketing Application Admins: In Work Management, go to the Ticketing application > gear icon > Admin > AI and Automation > Automation Rules
   • Global Admins: In TDAdmin, go to Applications, select the Ticketing application > AI and Automation > Automation Rules
2. Click the +New button.
3. On the New Automation Rule page, enter a Name that indicates what the rule does.
4. Choose a value for Applies To (Create, Modify, Both)
   • Consider carefully when the rule should apply. 
5. Enter the Evaluation Order.
6. If you want the automation to stop running when this rule is processed, leave the Stop on Match box checked. To continue processing rules, uncheck it.
7. Enter a brief Description of how the automation rule affects tickets.
8. Click Save.
9. On the newly created Automation Rule Detail page, click the Edit button.
10. Click the Active checkbox if you want this rule to start taking action in your system
11. Click Save

Active automation rules will not take effect until at least one condition is specified. Thus, a rule must be Active and have at least one configuration rule before it is evaluated when a ticket is created.

Configure the Automation Conditions

To set up the conditions that must be met for the rule’s actions to be executed on the ticket:

1. On the Automation Rule Detail page, click the Edit button.
2. Under Automation Conditions, in row 1, search for and select an attribute in the Column field.
3. Choose an Operator from the dropdown if needed.
4. Select one or more Values that must be matched in the new ticket.
5. Repeat steps 2-4 for each condition to be applied. Note that by default, each row in the condition list acts as an AND function, and the criteria in all the rows must be true for the automation rule's conditions to be met.
6. Click the Show Advanced button to enter an Advanced Filter Expression. The advanced filter lets you broaden the rule criteria.  The system defaults to "AND" logic: 1 and 2 and 3 and 4 and...... ​​​​​​
   • To expand your criteria to include tickets where the conditions are true for any one of the rows, enter “OR” between the condition numbers. Refer to a filtering condition by its number in the list. For example, “1 OR 2 OR 3” means the rule applies to tickets that match any one of the three listed conditions — rather than requiring all three to be true. 
   • The advanced filter also supports using AND and OR in combination. For example, “(1 OR 2) AND 3” means the rule applies to tickets that match condition 3 and at least one of conditions 1 or 2. 
   • You may also include parenthetical nesting if required such as (1 AND (2 or (3 AND 4))) OR ((5 OR 6) AND (7 OR 8))
   • The advanced filter must address all of the configured conditions. Any omitted conditions will not be included when the rule is evaluated. For example, if I have three filter conditions, but my advanced filter only addresses 1 & 2, condition 3 will be ignored when the rule is evaluated.

Configure the Automation Actions

To set up the actions that are triggered when a ticket meets the automation conditions:

1. Select the relevant action(s). See the Available Automation Actions below.
2. Select the appropriate values from the dropdowns and/or lookup fields.
3. When you have selected the actions/values you need for the rule, click Save.

Note that while it is possible to configure all actions, in practice, you will typically select only a few for a given rule.

Available Automation Actions

All actions provide the option to replace existing values with those specified here, except Notify People and Notify Groups.

• Assign To - This will take effect even if a responsible resource has been specified elsewhere. To prevent this behavior, include the conditions "Unassigned is true" and "Group Unassigned is true" to ensure that only items that lack a responsible assignee will be affected.
  • You can opt to Replace Existing Assignment and Notify New Assignee
• Change to Impact - Select an Impact value to assign to tickets that meet the conditions
• Change to Urgency - Select an Urgency value to assign to tickets that meet the conditions.
• Change to Priority - Select a Priority value to assign to tickets that meet the conditions.
• Assign to SLA - Select an SLA to assign to tickets that meet the conditions.
  • Specify how to handle existing SLAs if already assigned to the ticket. 
  • Specify whether to base the SLA deadline on the current date or the ticket creation date.
• Apply Task Template - Select a task template to apply to tickets that meet the conditions. A task template applies only once per ticket through automation rules, so a rule that runs on Modify or Both does not create duplicate tasks.
  • You can opt to delete any existing tasks.
  • Specify whether to base the ticket tasks' deadline on the current date, ticket creation date, or ticket start date.
• Assign to Workflow - Specify a workflow to enroll the ticket in. If a ticket is assigned to a workflow via an automation rule, it will be reclassified to the Ticketing application's default classification unless it is created as a parent ticket. 
  • Specify how to handle existing workflows if already assigned to the ticket. 
• Notify People - Select individuals to notify when a ticket meets the conditions. 
• Notify Groups - Select groups to notify when a ticket meets the conditions.

Example Rules

Automation Rule Best Practices

Evaluation Order Strategy

• Leave gaps between numbers - Use increments like 10, 20, 30, or 100, 200, 300 to allow for future insertions. Don't worry about using large numbers - you could even use 1000, 2000, 3000.
• Cluster by function - Group related rules together such as:
  • 100-199: Priority and urgency rules
  • 200-299: SLA assignments
  • 300-399: Group assignments
  • 400-499: Workflow applications
• Generic Rules Earlier in Evaluation - Place catchall rules earlier to ensure no gaps
  • For example, set your first ticket assignment rule (Evaluation order: 200-209) to route to tier 1 or a general "Helpdesk" to avoid any missed tickets
  • Set more specific group/person assignments farther down the list (Evaluation order: 210-300); allowing the specific rules to supersede the more general statements without having to apply stop on match liberally
• Stop on Match rules order Zero - Place critical exception rules before more general rules, and use "Stop on Match" on specific rules to prevent generic fallback rules from also executing.
  • For example:
    • Rule 0: If Requestor is in Group "VIP" → Assign Ticket to "Senior Technicians"  (Stop on Match = Yes)
    • Rule 200: If Responsible is blank → Set to Service Desk (Stop on Match = No)
  • Now, if a VIP ticket comes in:
    • Rule 0 matches, sets to "Senior Technicians", and stops evaluation
    • Rule 200 never evaluates
  • If a generic ticket comes in:
    • Rule 0 doesn't match
    • Rule 200 catches it and sets it to Service Desk

Using 'Stop on Match' Effectively

• Use Sparingly - While in theory you could set "Stop on Match" for every rule, it will prevent you from allowing multiple rules to apply and result in many hyper-granular rules.  You will need to review all uses of "Stop on Match" to make sure they're appropriate.
• Use for exclusive conditions - When only one rule should apply (e.g., priority-based assignment). I.e., use "Stop on Match" when you have mutually exclusive scenarios in which you want only one outcome to occur.
• Review regularly - When adding new rules, verify "Stop on Match" settings don't prevent needed automation.

Naming Conventions

• Use descriptive names that indicate the rule's purpose
• Include the trigger condition in the name (e.g., "High Priority - Notify Manager")
• Consider prefixing with evaluation order for easy sorting (e.g., "100 - High Priority Assignment")

Common Issues and How to Resolve Them

Issue: Rules Don't Execute as Expected

Cause: Incorrect evaluation order or Stop on Match configuration

Solution: The most common issue with automation rules is that tickets are not processed as intended. This is usually the result of conflicts arising from an incorrect evaluation order and the application of "Stop on Match." Review the evaluation order and verify "Stop on Match" settings. Remember that rules evaluate against the original ticket state, not values changed by previous rules.

NOTE: All actions taken by a matched rule will be listed in the Ticket Feed, making it easy to identify what rules matched and what actions were taken.

Issue: Multiple Rules with Same Evaluation Order

Cause: Rules with identical evaluation orders are processed alphabetically

Solution: Assign unique evaluation orders to ensure order of processing.  Or if you MUST keep a matched evaluation order, add numerical listing to the names ("1. I want this rule to happen first", "2. I want this rule next")

Issue: Subsequent Rules Don't See Previous Changes

Cause: All rules evaluate against the ticket's state at the start of processing

Example: If a ticket is created without a Responsible value and Rule 1 sets Responsible to "Group A" based on Priority = High, Rule 2, with the condition "Responsible is blank", will still match because it evaluates the original blank state

Solution: Order rules carefully, set intentional evaluation orders, and use "Stop on Match" strategically to prevent conflicts. Remember that even if an automation rule changes a value in a ticket, subsequent automation rule criteria will continue to evaluate against the original ticket value.