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.
53 comments
CJ Johnson
Ezgi Filazoğlu I think the part that's causing problems is that Ticket is Created, and Ticket is Updated cannot both be requirements, that's why it's not firing. If you remove "Ticket is Updated", it should be able to fire.The current user piece will make it so this only fires if a ticket is created by someone for themself, which is fine and should be okay.
After a ticket is created, all future updates are "Ticket Updates", but the very first one, is not considered a ticket update, so it's a conflict with "Ticket is Created".
0
Ezgi Filazoğlu
Thank you for this answer @CJ: Ezgi Filazoğlu I think the part that's causing problems is that Ticket is Created, and Ticket is Updated cannot both be requirements, that's why it's not firing. If you remove "Ticket is Updated", it should be able to fire.The current user piece will make it so this only fires if a ticket is created by someone for themself, which is fine and should be okay. After a ticket is created, all future updates are "Ticket Updates", but the very first one, is not considered a ticket update, so it's a conflict with "Ticket is Created". I have one moe question. So what kind of trigger should I create to receive a notification if an end-user makes a comment for ticket. İsn't it "Ticket is Updated"?
0
CJ Johnson
Hi Ezgi,

For my organization, I would make a separate trigger, set up like below to get emails flowing for ticket updates. If we assume your agents set to tickets to pending, and tickets only switch to open when the user replies (which is what happens automatically by default), this would work. It says that if a ticket is updated, and that update changes the status to open, and the update has a comment being added as part of it, email the assignee this template that includes a ticket link and the latest comment formatted in HTML.
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
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
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
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
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
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
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
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 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
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
vincent solitario
Hello Zendesk team,
I'm trying to create a trigger for Auto assign to agent who open the New ticket in our Facebook messenger and it's not working.
This it the thing that we want to accomplish.
-Facebook Messenger New Message/Ticket
-Agent who opens the ticket will automatically assign the ticket to his/her name.
Thank you.
0
Destiny
Thank you for reaching out with your request regarding the automatic assignment of new messages/tickets in Facebook Messenger to the agent who opens them. We understand the intention behind streamlining the process to ensure prompt responses to customer inquiries.
However, after careful consideration, we have determined that implementing an automatic ticket assignment to the agent who first opens the ticket is not feasible at this time. One of the primary reasons for this decision is the potential for accidental ticket openings. Our agents often navigate through multiple tickets to monitor and manage the workflow. There is a risk that an agent might inadvertently open a ticket they are not prepared to address immediately or may lack the specific expertise required for that particular issue.
In such cases, the automatic assignment would leave no room for the agent to close the ticket and allow it to be reassigned to a more appropriate team member. This could lead to delays in response times and a decrease in the quality of service, as the ticket might not be handled by the agent best suited to resolve the customer's issue efficiently.
Additionally, you may want to explore the option of automatic routing, where tickets are assigned to the most available agent within a specified time frame. This approach could help ensure that inquiries are addressed promptly by agents who are ready and able to assist. You can find more information here About Omnichannel Routing
We are committed to providing the best possible service to our customers and believe that maintaining a manual assignment process allows for better flexibility and ensures that tickets are handled by the most qualified agents. We will continue to explore other ways to optimize our ticket management system without compromising the quality of our customer support.
Thank you for your understanding and for bringing this matter to our attention.
1
Ambuj Kumar
Hello,


I created a trigger for webhook to be called on every ticket update and comment is present (either public or private).
But it trigger on firts message only. It doesn't trigger on follow up message in same ticket.
Can you please help me in this issue ?
Condition -
Action -
0
Zaffar Sayed
Hey can anyone help with trigger for automatically assigning tickets to agent in a view while in Play mode Guided mode enable, Thank you.
0
Destiny
Thanks for reaching out. In order to better assist you with your webhook query, I would suggest reaching out to our Support team by initiating a chat in our Messaging channel. Or you can also follow this article on other ways to contact our team Contacting Zendesk Support
Talk soon!
0
Walter
Hi Ambuj Kumar ,
Have you checked the events in the ticket to confirm that the trigger is not being run?
What other conditions exist?
You are only showing those from the “ANY” section. Are there any conditions in the “ALL” section?
Another thing to check is to check the webhook activity. If you are an admin, then you can check https://YOURSUBDOMAIN.zendesk.com/admin/apps-integrations/webhooks/webhooks/ and then click the name of the webhook. Then check the Activity option to see if any of the runs had issues.
0
Ramakrishnan N
Hello,
When a custom field value is changed and the ticket is updated, I want to send a notification to the requester. How can I do it (assuming a Ticket Update trigger would help, but how can I write a condition to check if a value is changed for a specific field; it could be any value earlier, which got changed to another value)?
0
Gabriel Manlapig
HI Ramakrishnan,
Are you using drop-down list, multi-select, and checkbox custom ticket fields? As of the moment, the “Changed” condition operators is only available for condition statements such as Ticket: Status, Ticket: Group, and Ticket: Assignee.
For reference, please see sample screenshot below:

Currently there's no built-in way to do this. Can you add your use case to this Product Feedback thread?
Feature Request: Add "Changed", etc, trigger test for custom Drop-down ticket fields
0
Panashe Nyenya
Hi, I'm currently trying to create a trigger for a specific agent within a group. How do I do this? I only want them to receive email notifications when they are mentioned or tagged etc having trouble doing this
0
Panashe Nyenya
Hi,
I've created Triggers for all the agents in our team for when they send out text messages to our consumers, in each text message sent out the text will contain ‘Hi my it’s (with the agent's name) below is the triggers set up but this does not seem to be working all the time only with certain messages. Please can I have help with correcting the trigger to ensure it applies to any text messages that are replied to so they auto-assign to the original agent that sent the message
0