Suite | Team, Growth, Professional, Enterprise, or Enterprise Plus |
Support | Team, Professional, or Enterprise |
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.
- On non-Enterprise plans, ticket triggers are visible to agents, including light agents and contributors, but can only be edited by admins. On Enterprise plans, triggers are visible only to agents in custom roles with permission to manage 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.
53 comments
Gab
I created a ticket on your behalf and will send it to you via email so we can discuss your concern there.
Thank you!
0
Wolf Hilbl
Hi Gab,
this option is not available, neither in triggers nor automation.
We can only add Agent Accounts within the trigger or automation creation menus.
Kind regards
0
Gab
You can definitely add a non-agent as a requester as this will prompt you to add the user's name and email address and will be added as an end-user. In CC, a non-agent can also be added. However, if you are referring to adding a non-agent as a follower, I'm afraid this is not possible as followers can only be internal users (e.g. your agents and other support staff are your internal users, also called team members).
More information can be found here: About CCs and followers
I hope this helps.
0
Wolf Hilbl
Hi, is there a way to add a non Agent as Requester or in CC?
We would like to add additional requesters to Tickets.
Kind regards Wolf
0
Arianne Batiles
Hi PAUL STRAUSS,
I created a ticket on your behalf, and I’ll continue to assist you from there. Kindly check your email for updates. Thank you!
0
Paul Strauss
I'm attempting to create a trigger that will set a custom checkbox field on the requester based on the existence of a ticket tag. However, when I test this with existing tickets, it is not triggering. Any suggestions as to what might be wrong with my logic? See below:
0
Hiedi Kysther
Hi D.Fitz,
This would require deeper investigation. I've created a ticket on your behalf so we investigate this issue together. Kindly check your email for more information. Thanks!
0
D.Fitz
We're going crazy trying to figure this one out.
Aiming to run a trigger when a macro is applied. The macro adds an Internal Comment, two tags and assigns the ticket to a group. This should then send a templated email to the customer (currently cut off, but it's just an 'email user' action).
For some reason, this just doesn't work. All of the criteria are matched and Zendesk 'counts' the trigger as having run, but the email just doesn't send.
What are we doing wrong?
0
Noly Maron Unson
Hi Cory,
This should work as long as the trigger updates the custom field directly, meaning it contains the said action in the trigger itself. Multiple triggers can run on a single event/cycle. If the trigger that updates the custom field value is above in the trigger order than the one that notifies the webhook, then they should be able to run in the same event (creation event).
The only reason why this will not work is if the trigger that changes the field value is not the one directly changing the custom field value but is using a Webhook to update the ticket via API. The changes in the custom field value using this method will not occur in the same event where the trigger fired but will create another event that will fall under the "Ticket is Updated" condition.
This is also not a workflow that we recommend/support since it usually causes race conditions.
0
Cory Waddingham
I want to have a trigger that sends a notification to a webhook on certain conditions, but only when the ticket is created, not updated. But there's another trigger that has to run first that updates some fields on the ticket, and that field is part of the first trigger's conditions. I want to make sure the notification trigger runs only when the ticket is first created.
For more context, we have different tiers of customers, and we want to call PagerDuty when a sev1 ticket is opened by one of those tiers but not others. But the customer tiers are updated by a different trigger, which calls a webhook to a cloud service to get their tier information and updates a custom field with that. The trigger that updates the plan tier information runs before any others, but then the ticket shows as Open, not New. Will any tickets that depend on the ticket being Created, not Updated, still run in this case?
0
Sign in to leave a comment.