Triggers are business rules you define that run immediately after a ticket is created or updated and automatically perform actions if specified conditions are met.
Here are some uses for triggers:
- Notifying customers when you're out-of-office
- Sending customer satisfaction score follow-ups
- Routing your priority customers into a specialized support group
- Adding and removing tags
- Assigning tickets by channel
- Escalating tickets
This article describes the building blocks that make triggers and explains how they run. You can also watch this video:
What's Good: Business Rules (1:38)
This article contains the following sections:
For information about creating triggers, see Streamlining workflow with ticket updates and triggers.
Essential facts for triggers
We've distilled some essential facts for you about triggers. These are explained in greater detail in our 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 will run, or check the conditions, immediately after tickets are created or updated.
Triggers will only fire, or apply their actions, if the ticket meets the trigger's set conditions.
Actions applied by one trigger can affect other triggers.
- Actions in one trigger can affect the actions in another.
- Triggers do not run or fire on tickets after they are closed. However, triggers can fire when a ticket is being set to closed, except when the ticket is closed by the system after 28 days.
- Triggers, like all business rules, must be smaller than 65kb.
- To help you manage large numbers of triggers, triggers can be organized into categories.
Understanding trigger conditions and actions
Triggers contain conditions and actions. You combine these to create ‘if’ and ‘then’ statements (if the ticket contains a certain set of conditions then the actions make the updates to the ticket and optionally notify the requester or the support staff).
You build condition and action statements using ticket properties, field operators, and the ticket property values. There are two types of conditions – all conditions and any conditions.
The all conditions, as you've probably already figured out, must all be true. If a single condition statement in the all conditions section fails (is not true), the trigger will not act on the ticket.
Additionally at least one of the any conditions must also be true. For example, you might want a trigger to act only on tickets that are submitted from a list of specific email addresses, as in this example:
If either of these conditions is true, the trigger will fire. If you use only one condition in the any section, it will behave like an all condition and therefore must be true for the trigger to fire.
Action statements follow the same format, but rather than testing for conditions to be true or not, actions set ticket properties and send email notifications, as in this example:
Understanding when triggers run and fire
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. A trigger will fire and update the ticket if its conditions are met during the cycle. A cycle is the entire process of a ticket being checked against all your triggers.
If a trigger updates a ticket during the cycle, the cycle starts over. All the triggers run again, except any triggers that have already fired and updated the ticket. This means a ticket could loop through the 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.)
So a trigger might run (that is, be checked) several times during a cycle, but it will never fire (that is, take action) more than once in the same cycle because the trigger is not checked again after it fires. And a trigger will not fire at all during the cycle if the conditions are not met.
Because triggers cycle starts over when a trigger fires, 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, as an action in one trigger might change a ticket property that was changed by another trigger.
I'm sorry, I'm still a bit confused when triggers are evaluated.
Is it when any field is updated/changed?
or only after the ticket has been saved?
Triggers will be checked every time a ticket is created or updated.
When a ticket gets updated, it doesn't matter how big or small the change is, the evaluation would still occur. Updates can happen many ways, a few examples are agents submitting ticket changes to a custom field, or a user replying via an email to a ticket or an API integration changing a ticket status when something happens in another system.
You get to configure your triggers and rules to only take actions when a specific kind of update happens though. Every trigger will still be checked, but only the ones that match the conditions you define will act on the ticket.
Does that help at all?
Sorry, I guess my question wasn't clear.
Let's say I have a trigger set to when the tag "go" is added.
Would the trigger fire as soon as the tag was added to the field?
Or when the agent saved the ticket?
@EricDeLosSantos only when the agent submits the ticket. Until then, the change has not actually been made.
Wondering if anyone can help me understand the difference between these two sets of conditions:
I understand that the first expression states "A ticket must have all 3 of these tags". Does the second expression state something different, or are these effectively the same?
Just want to make sure I have clarity on how ANDs work within conditions :)
You are correct that the first statement means that All 3 tags must be on the ticket.
The second statement means that Tag1, Tag2, OR Tag3 must be on the ticket.
All conditions in "ALL" are "AND"ed together, but some conditions can have their own "OR" property, such as [Tags] [Contains at least one of the following] and [Comment text] [Contains at least one of the following words].
All conditions in "ANY" are "OR"ed together, but it's also important to note that at least one of the "ANY" conditions must be true for the full set of both ANY/ALL conditions to return "true", and for the trigger to run.
IF ((ALL1 AND ALL2 AND ALL3 AND …) AND (ANY1 OR ANY2 OR ANY3 OR …))
Thank you for the speedy response! Since [Tags | contains at least...] has its own OR operator, is it the case that this expression:
is the same as this one? -
Been a while since I brushed up on my symbolic logic so I really appreciate your help!
Those 2 look logically equivalent to me.
The nice thing about using the "contains at least one of the following" within the "ALL" block is that it allows you to have slightly more complicated logic, for example if you wanted any other "ANY" conditions to also be evaluated besides the Tags.
For example if we changed your examples and wanted to check the inbound email address,
Would be different from
The first example would only evaluate "true" when Tag1,2,or3 is present AND the received_at address is 1 or 2.
The second example would evaluate "true" when Tag1,2,or3 is present, OR the received_at address is 1 or 2, even if none of the tags are present.
Thanks a ton, Matt! You've been super helpful. 🎉
Is there a way to email "everyone in the group but the agent when that agent updates a ticket"? We don't need our agents to be emailed about their own updates to a ticket, just to anyone else's update of a ticket in their group.
Unfortunately, there's no way to to that, aside from separately adding notification actions for each agent you do want to include (which would be difficult to maintain over time).
If you'd like, please consider creating a post in our Feedback on the Ticketing System (Support) topic, using our template to format your input. Thanks!
Is there a way to queue talk/chat channels together? Example: I have an agent speaking to a customer on the phone, I want to prevent a chat being presented to that agent until the call is completed (and vice versa - chatting, no call presented). I have tried the 'focus mode' and today during the 'what's new' session I was given the option to look at triggers but I can't see anywhere that I can 'trigger' agent availability when this or that condition is met. Perhaps I'm missing something but hoping to get further clarity on this. Thank you!
Dawn La Branche,
I'm not aware of any triggers that would do what you're looking for... You mentioned you tried Focus Mode. Did that not work for you? What went wrong there?
Hi Heather, thank you for the speedy response.
When 'focus mode' was turned on, I and my team created sample calls/chats to one another and both the types of interactions were presented to the agent at the same time. We tried this with each of us (2 agents and myself as the admin) to learn both what our customers would hear/see as well as the agent workspace experience. So from our experience, nothing changed when turning 'focus mode' on.
Dawn La Branche,
I'm wondering if focus mode ends up turning "on" when the agent accepts one of the interactions. At that point, they shouldn't be presented with a new request from another channel. Want to give that a go?
Hi Heather, we did try that whereby I kept only one agent online in both channels (chat and talk) and then had a new call and new chat happen within 30 seconds of each other. Chat hit the online agent first, then the call hit them about 30 secs after. Unfortunately, both requests still arrived at the agent workspace. We even thought that maybe the agent hadn't assigned them self the chat and therefore, the 'turn on' didn't happen but that didn't seem to change with or without assignment of the chat.
Can a trigger be based on a Sunshine profile or object?
Trigger conditions or actions cannot be built based on Sunshine profiles or custom objects. Can you share a general overview of your use case? I'm interested in seeing if there's another set of Zendesk tools that may help.
I have a case that I would like some feedback on.
For some tickets we want the first replies to be handled with a different trigger, so we can skip the "Re:" in the subject line.
My first thought was to do it like this:
But apparently this doesn't work due to how Zendesk handles this, this is what happens:
Now how can I solve this :)
Hey Óskar Ómarsson,
Happy to help here, you've got a few options:
Option 1: Modify the general trigger to remove "RE:" from the subject.
Option 2: Don't remove the tag and just use the Special Trigger for the duration of that ticket.
Option 3: Create an Automation that removes the tag shortly after the Trigger runs.
> Ticket is less than solved, hours since updated > 1, tags contains special_trigger; remove tag
Let me know if one of those solves for your use case!
We went live with IVR few months ago and now things have gotten really bad within zendesk. Tickets are getting assigned to wrong groups.
Questions I have are these:
1. Once a condition is met, how do I tell zendesk to stop going to other triggers? Right now, it is one after the other and it just doesn't stop.
2. It should only go to the next trigger if the conditions are not met.
In most cases of CRM, software would look for a condition to meet and if it does, it will not go through others, but in Zendesk, it seems that it is FIFO and it will not work if your trigger is set at the bottom.
Any ideas on how to resolve this issue?
Hey Operator AV-1544 -
Thanks for writing in. Triggers do run from top to bottom, with each successful Trigger running 'resetting' and 'rerunning' the entire Trigger set. The image from the article does a decent job of visualizing this process:
What I've seen others do in the case of conflicting Triggers is to use conditions such as a tag or "channel is not voice" to prevent other Triggers from firing on your Talk tickets. Hope this helps!
I have about 25 triggers and each one is set up based on the channels (for example, there is a trigger that says if channel is specific email, route to specific group).
Issue I am running into is the trigger for Voicemail which is supposed to go to 1 group only, but this trigger gets fired for tickets for other triggers. For example, social media trigger is specific and is only for tickets that are coming in from Twitter and Facebook. Unfortunately, what I have seen is that tickets from Social Media get Voicemail triggers get assigned - this happens where the Social Media trigger gets applied, but then right after that, it goes to the next trigger which is Voicemail and it applies that one so the ticket ends up in the wrong group. I want to stop that but have not figured out how to do that.
My social Media trigger is ahead of the voicemail trigger already and configured as below:
Must meet - Ticket is created
Any meet - Channel is Facebook, Twitter, twitter DM
Action - Assign Form X and group SocialMedia
Voicemail Trigger is configured as follow
Must meet - Ticket is created
Any meet - Status is new & Channel is Voicemail
Action - Assign Form X and group Z
Ahh - that makes sense! For your Voicemail Trigger - you are using 'Any' conditions, which mean only one of the conditions has to be true. Because your social ticket is created and new, channel is voicemail is disregarded and the Trigger fires. Moving Channel is Voicemail to Must meet for your Voicemail Trigger should solve for this!
Understood. Thank you. I have made the changes on it. Will monitor it.
Hi Zendesk, I want to add a trigger for those tickets that have no assignee, I wish to add the assignee automatically based on which agent sent a public reply.
Hey Azure Sun -
The ALL Conditions you'll need here are:
Ticket is Updated
Current User Is (Agent)
Assignee is -
Comment is Public
Assignee is (Current User)
*Note: This will prevent an agent from making a public reply while simultaneously assigning the unassigned ticket to another agent (but these actions can be taken sequentially).
Hope this helps!
Is there a planned feature to be able to trigger upon account creation?
AFAIK this isn't something that's planned at this time. I would encourage you to share your feedback in our Feedback - Ticketing System (Support) topic for our product managers to review.
You can also use this template when creating your post :)
I hope this helps!
I am trying to auto tag tickets for tracking, however when a macro is applied to the ticket, the macro tags are overriding the trigger tag. I need both tags to be added to the ticket. Is this possible?
Please sign in to leave a comment.