Zendesk has a variety of business rules that can be used to automate record updates and notifications across products. Triggers are business rules you define that run immediately after a record, such as a ticket, is created or updated and automatically perform actions if specified conditions are met. This article explains the different types of Zendesk triggers and essential facts about them.
Types of Zendesk triggers
Triggers are managed separately by Zendesk product.
The following trigger types exist, organized by Zendesk product:
-
Ticket triggers: The first and most common type of trigger, running any time a ticket is created or updated. There are several standard ticket triggers that Zendesk provides to help you get started with your Support workflows.
Although ticket triggers are traditionally thought of as only applying to email tickets (including tickets submitted through web forms and APIs), tickets are also created for live chats, messaging conversations, and calls. Ticket triggers support a "Ticket channel is {channel}" condition that allows you to select most of the Zendesk channels. Because of this, it can be helpful to think of chat and messaging triggers as a subset of ticket triggers that just happen to be managed on a separate page in Admin Center.
See Creating ticket triggers for automatic ticket updates and notifications.
- Object triggers: Run any time a record is created or updated for the specified custom object. Requires you to activate and create at least one custom object.
-
Chat triggers: Run when a selected event occurs. When creating a chat trigger, admins must specify a single event that causes the trigger to run. There are several standard chat triggers that Zendesk provides to help you get started with your live chat workflows.
Managed on the Chat dashboard: Admin Center > Objects and rules > Business rules > Chat triggers.
-
Messaging triggers: Messaging triggers function the same way chat triggers do. When creating a messaging trigger, admins must specify a single event that causes the trigger to run. There are several standard messaging triggers that Zendesk provides to help you get started with your messaging workflows.
For some accounts, messaging triggers are managed in Admin Center > Objects and rules > Business rules > Messaging triggers. If you don't see this page, your messaging triggers are still created and managed on the Chat dashboard: Admin Center > Objects and rules > Business rules > Chat triggers.
- Sales triggers: Run when a user-specified event occurs.
Essential facts about Zendesk triggers
This section distills some essential facts about triggers as a whole. These are explained in greater detail in the documentation. See Triggers resources.
- Triggers are created from conditions and actions. Conditions set the qualifications needed for the trigger to fire, and actions represent what will be performed when those qualifications are met.
- Triggers always run, or check the conditions, immediately after the qualifying event happens. For ticket and object triggers, qualifying events are record creation and updates. For chat, messaging, and sale triggers, the qualifying event is defined by an admin when configuring a trigger.
- The one exception is ticket triggers don't run or fire on tickets after they are closed. However, ticket triggers can fire when a ticket is being set to closed, except when the ticket is automatically closed by the system after 28 days.
- Changes that automations make to tickets can cause triggers to run. Configure triggers and automations with the understading that changes made by automations can impact triggers and vice versa. See About automations and how they work
- Triggers only fire, or apply their actions, if the trigger's set conditions are met.
- Actions applied by one ticket trigger can affect how other triggers run and fire for a ticket. However, other types of triggers run simultaneously without this looping behavior.
- Triggers, like all business rules, must be smaller than 65 KB.
Anatomy of triggers
Triggers are comprised of two parts: conditions and actions. You combine these to create ‘if’ and ‘then’ statements. If the record contains a certain set of conditions, then the actions make the updates to the record and can send notifications. Chat, messaging, and sales triggers also require an admin to specify the event that must occur for the trigger to run.
Conditions
Condition statements are the "if" part of a trigger. They're structured as a condition (sometimes called category), an operator, and a value.
The available condition options vary by type of trigger. For ticket triggers, messaging triggers, and chat triggers, there are predefined lists of supported conditions. For object triggers, the supported conditions depend on the custom object's fields.
There are two types of conditions – all conditions and any conditions. In practice, all of the all conditions must be true in order for the trigger's conditions to be met, while one or more of the any conditions must be true in order for the trigger's conditions to be met. For ticket triggers and object triggers, you can use a combination of all and any conditions. However, for chat and messaging triggers, you must choose between using all and any conditions.
Actions
Action statements describe what happens when a trigger's conditions are met. These are the "then" parts of a trigger. When we say a trigger fires, we mean it's applying the actions.
Action statements are structured as an action and a value.
Similar to conditions, the available actions vary by type of trigger. A predefined list of supported actions are available for ticket triggers, messaging triggers, and chat triggers. For object triggers, there are some predefined notification actions, but the rest of the available actions depend on the custom object's fields.
Run events
When we say a trigger runs, we mean the trigger's conditions are evaluated and, if met, the specified actions occur. Ticket triggers and object triggers run automatically any time a ticket or a custom object's record, respectively, is created or updated. However, chat, messaging, and sales triggers only run when a user-specified event occurs. When creating one of these triggers, an admin must select the run event from a drop-down.
55 comments
Brandon (729)
Hey Clarice Matt
In this case, you'll need to update your macro actions to ADD tags, not SET tags.
Hope this helps!
Brandon
0
Rebecca Katz
Our triggers are categorized into groups, will the run order still be from top to bottom of the whole list, or is it top to bottom within each group?
For example:
Category 1:
trigger 1a
trigger 1b
Category 2:
trigger 2a
trigger 2b
Will triggers 1a and 2a run together or will 2a run after 1b?
Thanks!
0
Brandon (729)
Hey Rebecca Katz,
The Triggers will run from top to bottom regardless of category (1A,1B,2A,2B). This is why I recommend using the SANE method featured in this post. Hope this helps!
Brandon
1
Rebecca Katz
Perfect thank you again!
0
Gabriel
I hope all is well. Thinking about the scenario that you have described, if the ticket meets the condition of multiple triggers, all the triggers will fire. Note that every time a ticket is created or updated, all of your triggers run in a cycle against that ticket in the order the triggers are listed. However, I must add a personal note here and say that the best practice would be not to rely upon the order that the triggers are fired. Consider adding more conditions and make each trigger unique for each routing in this case. To help you, please check the list of trigger conditions and actions.
I hope this helps!
0
Leandi Muller
Hi Zendesk,
I'm having a hard time with one of my triggers - if anyone can shed some light please?
What I'm trying to achieve:
1. Ticket is created via form
2. Based on a specific selection match
3. Send an auto-response to the requester email and place the ticket into a solved status
4. IF the end-user responds to the email
5. Open the ticket in Zendesk assigned view for a support agent to assist client
What is happening is, that even if the end-user responds - the trigger fires off the auto-response and solves the ticket again so the end-user is stuck in a loop.
How do I solve this issue please?
TIA
0
Brandon (729)
Hi Leandi Muller -
It sounds like maybe what's happening is the original ticket is being moved via an automation from solved > closed. Once closed, the ticket can't be reopened, so any response will create a net new ticket (which will get caught by the first Trigger).
To avoid this, you could extend the window a ticket stays solved, so the original ticket will just reopen. Alternatively, you could condition the first Trigger to say "Channel" is not "Closed Ticket."
Hope this helps!
Brandon
0
Ashish
Hi Zendesk, I want to add a trigger to auto-assign new or open tickets ( which are not already assigned) to an agent based on ticket's latest comment ( while someone is referring it to an agent by adding a @ character).
For example - End user or CCed person or Other light agents comments on the ticket via Zendesk or via email " @Mike please look into this matter". So based on @ {{ticket.assignee.name}} , ticket should be assign automatically to that agent ( Mike).
I have added this line in a trigger but it is not working.
Please provide your support on this.
Thanks,
0
Leon Harris
Is there a way to edit the dropdown fields for a trigger? It is easy with forms. Why the restriction with triggers?
0
Nikolay Kolev
Hello,
We are testing the HubSpot - Zendesk integration, especially the one created by Zendesk.
I have an issue that I am curious if I can solve through the triggers.
When a new ticket is created and the contact is already in the HubSpot system, I want the flow to remain the same. The ticket is noted in the profile through one of the triggers. However, if there is not an existing contact in HubSpot is there a way for the ticket to enter HubSpot without generating a new profile? Might be like a task or HubSpot ticket or something else.
Thank you!
0
PAUL STRAUSS
Can anyone think of a reason that a newly-created Text field would only allow "Present" and "Not Present" as the values for a trigger condition? I need to be able to set the trigger condition based on the value stored in the field, not just whether it exists or not.
This is driving me nuts:
1
Dainne Kiara Lucena-Laxamana
Hi PAUL STRAUSS,
For custom text ticket fields, it is expected that it would only show options "present" & "not present" for trigger conditions. More information can be found here: Using custom ticket fields in business rules and views
0
Yvonne P.
We switched to Zendesk a little over a year ago now - a lot has happened since :) We have grown by 3 brands, with multiple groups, of course all that meant loads of new triggers for routing tickets, as well as along the way trying to automate as much as we can.
Now a couple of weeks ago, we were finally able to automate our clean brand separation, by adding a new workflow of triggers/tags etc. It seems that there is now some conflict between the new workflow and some of our old-workflows ..... long story short: is there a best practice recommendation on how to audit your trigger/workflows set ups once/twice per year?
I know I can check how triggers fire, and come across individual cases were we can tweak things here and there. But I would like to perform a once/twice per year overall audit on our set up, to make sure nothing is falling of the radar.
Hope this makes sense. Wasn't able to find anything on this online so far. Maybe someone here has some advice. How do you regularly make sure that your set up is 100% up to date and working properly on all ends?
0
Mike Jones
Does anyone know how "greater than" works in the context of setting a trigger condition using the Status field? If i set it as Status Greater than On-Hold will it work for both the Solved and Closed statuses?

0
Brandon (729)
Mike Jones - You are correct - that is exactly how that feature worked. Similarly, less than solved is new, open, pending and on-hold. It is worth noting though, that closed tickets cannot be actioned.
0
Nayla McCarty
Good Day!
What is the best way to approach this if I want this trigger to fire when the ticket is created OR updated? Would I need to create two separate triggers? TIA!
0
Trista Garner
I have set multiple triggers to navigate the action I'm trying to roll out. I need the conditions that will trigger an email to be sent to the assignee when a ticket is REASSIGNED to them from one user to another. The initial trigger of the ticket being assigned is active and working, but when it is reassigned to a different user, they aren't getting an email. Thank you for your help!
1
Brandon (729)
Hey Nayla McCarty - For this you'd most likely need two Triggers. You can technically remove Ticket is Created and just use Ticket is {new open pending on-hold} or Ticket Status category is less than solved, but the best practice here would be to break it out into two.
Trista Garner - Your conditions should be as follows:
Ticket is Updated
Assignee changed
Action: Notify Assignee
Hope this helps!
0
Helen Forrester
Triggers, like all business rules, must be smaller than 65kb
What does this mean in terms of the number of conditions? And if I have too many conditions can I simply create additional triggers if they are 'any' conditions?
Thanks.
0
Gab
The statement "Triggers, like all business rules, must be smaller than 65kb" focuses on the size limit for the overall definition of a trigger (or any other business rule) in Zendesk. This size constraint includes all aspects of the trigger's definition, such as the number of conditions and actions, as well as the length of any text used within them.
In practical terms, this means that the combined textual content of the trigger's conditions, actions, and any descriptions or comments must be less than 65 kilobytes in total. A kilobyte (kb) is roughly equivalent to 1,024 bytes, and since text is generally stored using one byte per character, a 65kb limit translates to roughly 65,000 characters.
Here’s what this implies for the number of conditions in a trigger:
To give an example, if an average condition string takes up 100 characters (including field identifiers, operators, and values), then you could theoretically include up to around 650 such conditions within a single trigger. However, in practice, conditions can be more complex, and other components of triggers like actions and descriptions must also be accounted for within the 65kb limit.
In Zendesk, if you approach the 65kb limit for a trigger, you may need to optimize your existing business rules by:
Monitoring the size of your business rules is important to ensure they remain functional and within Zendesk's guidelines. If you run into the size limit, Zendesk will alert you when you try to save the trigger, and you'll need to modify it to decrease its size.
I hope this clarifies your concern.
0
Frank Roberts
I arrived at this article because of the recent appearance of a notice at the bottom of each trigger. Does this mean that the system has detected a possible trigger loop? If not, is there a tool that will detect a loop in my trigger logic? The notice text is below:
Ticket triggers loopEvery time a ticket is created or updated, all of your triggers run in a cycle, firing and updating the ticket if the conditions are met. That means one of your triggers could update your ticket and restart the cycle again, looping through the trigger list several times.Learn about the ticket trigger cycle
I eagerly await your response.
0
Hiedi Kysther
Hey Frank Roberts
You got a good question here. The notice is a general reminder about the possibility of creating loops with Zendesk triggers. It doesn't automatically mean that your specific trigger is causing a loop. It's just a friendly reminder to be mindful of how triggers can interact with each other and possibly create cycles if not set up correctly.
Hope this helps!
0
Maricar Paraiso
Question, how to audit triggers -who created it, who edited, who modified? when was it created, modified or edited? I do not see it in any help article. Thanks!
0
Hiedi Kysther
Hi Maricar Paraiso
To audit your Triggers, you can utilize the Triggers API. This will provide you with information on when the trigger was created and last updated. If you need to know who created or last updated a trigger, we will have to check our logs. Please keep in mind that our logs are only accessible for the past 30 days.
Hope this helps!
0
Gabi
Consigo criar uma gatilho de quando o agente alterar o status para “pendente" e após de 20 minutos sem o retorno do cliente esse ticket alterar para resolvido e enviar a mensagem dentro do mesmo ticket?
0