Ticket triggers are business rules that run immediately after a ticket is created or updated and automatically perform actions if specified conditions are met. For example, a ticket trigger can be used to notify the customer when a ticket has been opened.
Triggers are composed of conditions, which are the qualifications needed for the trigger to fire, and actions, which are performed when those qualifications are met. See Anatomy of a trigger). In other words, if the conditions are true, then the trigger will perform the actions.
There is a set of standard ticket triggers that you can use in addition to creating your own triggers. Admins and agents in custom roles with permission to manage business rules can create ticket triggers.
Essential facts about ticket triggers
- The order of your ticket triggers and categories designates the order in which they're fired. It's important that triggers and categories are arranged in the appropriate order to match the intended workflow.
- The ticket event log only records the actions applied to tickets by triggers if they result in a net change in ticket field values. If a trigger runs and fires, but results in no change to the ticket, it isn't logged in the event log.
- You can have a maximum of 7000 active ticket triggers. This includes all standard and custom ticket triggers that are active.
- To help you manage large numbers of ticket triggers, they can be organized into categories.
- Ticket triggers run in the order they are listed on the Triggers page in Admin Center. This is important because actions applied by one trigger can affect how other triggers run and fire for a ticket.
- Agent access to ticket triggers varies by plan and permissions.
- On Enterprise plans, agents in custom roles with permission to manage triggers can view the list of triggers and view, add, edit, and delete individual triggers. Agents in custom roles without this permission can't access the list of triggers and have read-only access to individual triggers.
- On non-Enterprise plans, agents, light agents, and contributors can't access the list of triggers and have read-only access to individual triggers.
Understanding when ticket triggers run and fire
Every time a ticket is created or updated, all of your ticket triggers run in a cycle against that ticket in the order the triggers are listed. A ticket trigger fires and updates the ticket if its conditions are met during the cycle. A cycle is the entire process of a ticket being checked against all your ticket triggers.
If a ticket trigger updates a ticket during the cycle, the cycle starts over. All the ticket triggers run again, except any ticket triggers that have already fired and updated the ticket. This means a ticket could loop through the ticket trigger list several times before all of the triggers have either updated the ticket or been skipped because conditions were not met. (See the image below.)
A ticket trigger might run (that is, be checked) several times during a cycle, but it never fires (that is, take action) more than once in the same cycle because the trigger isn't checked again after it fires. And a trigger doesn't fire at all during the cycle if the conditions are not met.
Because the ticket trigger cycle starts over every time a trigger fires, actions in ticket triggers can affect one another. A ticket update by one trigger might cause another trigger, where conditions were not previously met, to be true and fire. So the order of your triggers is very important.
The importance of specific conditions
When building a ticket trigger, it's important to make your conditions as specific as possible. The Ticket | Is condition is a good way to narrow ticket trigger's scope so that it only runs when a ticket is created or when it is updated, but not both. Without this condition, ticket triggers run everytime any ticket is created or updated. This can lead to unnecessarily long processing times for the trigger cycle and unintentional automated actions occurring.
Commonly, the Ticket | Is | Created condition is used to route newly created tickets based on initial criteria, while Ticket | Is | Updated is used to send notifications. When used in combination with other nullifying conditions, such as Tags | Contains conditions or Priority | Is not, the Ticket | Is condition can help ensure your ticket triggers are only running and firing when you want them to.
It's also important to watch out for ticket triggers that undo or modify an action contained in another ticket trigger. This can cause conflicts and lead to unpredictable behavior. For example, if one trigger assigns tickets based on the channel from which it was received, and another assigns tickets based on the presense of tags. If a ticket meets the criteria for both triggers, the last one that fires in the cycle is the assignment the ticket will ultimately have. However, because the actions in one ticket trigger can affect whether a ticket meets the conditions for another trigger, it's not always easy to predict the order in which your triggers will fire for a given ticket. Therefore, it's important to avoid defining conflicting triggers and to use nullifying actions and conditions, such as adding a tag and then creating a condition around the precense of that tag, to minimize conflicts.
Creating ticket triggers
Ticket triggers are business rules that run immediately after a ticket is created or updated and automatically perform actions if specified conditions are met. There are standard ticket triggers, which you can modify, and you can create additional triggers.
You must be an admin or an agent in a custom role with permission to create triggers.
The following video gives you an overview of how to add triggers:
Automating notifications with ticket triggers [2:02]
- In Admin Center, click
Objects and rules in the sidebar, then select Business rules > Triggers. - On the triggers page, click the Ticket tab.
- Click Create trigger.
Alternatively, you can use the options menu icon (
) to Create trigger below the selected trigger or Clone and modify a copy of the existing trigger. - Enter a Name for your trigger.
Use a consistent naming convention to help you recognize similar types of triggers.
- (Optional) Enter a Description for your trigger.
You can provide details about what the trigger does. You'll be able to search for triggers based on description.
- Select an existing Trigger category for your trigger or create a new one.
- Click Add condition to set up the trigger to meet All or Any conditions.
Conditions are the qualifications needed for the trigger to fire.
- Select a Category, Field operator, and Value for each condition you add.
The field operator determines the relationship between the condition and the value. For example, if you select the field operator "Is", your condition will need to be equal to the value. Different conditions will contain different field operators.
See Building trigger condition statements.
Note: It is recommended to keep your trigger statements simple. The more complicated a trigger is, the harder it will be to troubleshoot and maintain. - Click the Add action to set the actions that occur when trigger conditions are met.
- Select Category and a Value for each action you add.
- Enter the action information.
Depending on the action you select, you will enter different information. For example, if you select the "Type" action, you'll need to select a ticket type.
If you're configuring an email notification action, see Understanding how to format email notifications. - Click Create trigger.
New triggers are automatically set to active. If you want to create an inactive trigger, click the arrow next to Create trigger and select Inactive.
Your new trigger is added to the end of the list of triggers.
Note: Each business rule must be less than 65kb.
You can reorder the list of ticket triggers or edit any ticket trigger.