Triggers are business rules you define to run immediately after tickets are created or updated. For example, a trigger can be used to notify the customer when a ticket has been opened. Another can be created to then notify the customer when the ticket is solved.
This article describes the building blocks that make triggers and explains how they run.
For information about creating and using triggers, see Streamlining workflow with ticket updates and triggers. For a list of default triggers, see About the Zendesk Support default 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.
- Triggers, like all business rules, must be smaller than 65k.
About triggers
Triggers can help you manage your workflow and improve your customer satisfaction by automatically performing actions whenever a ticket is created or updated with specified conditions.
Here are some uses for triggers:
- Notifying customers when you're out-of-office
- Sending customer satisfaction score follow-ups
- Routing your priority customers to a specialized support group automatically
- Notifying agents when a problem ticket has reached a certain number of incidents
- Adding and removing tags
- Automatically assign tickets by channel
- Escalating tickets
- Decreasing spam emails and automated responses
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 the 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.
69 Comments
Hey Candice,
The easiest solution here would be to use a combination of triggers and targets to send this email notification to an external user. More information can be found in the following article: Notifying external targets
Let me know if you have any other questions :)
IS this really not possible!?
I would like ta add an Internal comment så that our users see it when they take the ticket.
This information is crucial for how to handel the ticket.
Any condition
Actions
This company is not supported by us, inform customer of this, use Macro.
This seems pretty basic to be honest.
Hey Reine,
Triggers cannot add an internal comment to the ticket, however, if you were to set up a custom ticket field such as a checkbox you could have this field checked if the Organization is supported and unchecked if it's not. I realize this may not be the solution you're looking and if you do need some assistance setting this up let me know!
Cheers!
Hi Zendesk!
I have a trigger that uses a custom webhook (URL Target). I want it to when an agent adds a public comment to the ticket. I've added the condition "Comment is Public".
My trigger fires when the requester and/or the agent comments. I've read the docs and tried several conditions but have had no luck.
What conditions are available to have my trigger execute only when an agent adds a comment?
Hey Bruce,
Try adding a condition for Current user *is* (Agent) to have it only fire on agent comments.
Hey Dan,
That worked! Dunno how I missed this on my own. Thanks for your quick response!
-B
Hi team!
I was wondering how can we customize the trigger of Notifying all agents of received request WITH the exclusion of two agents (that are both admins). What we need is to keep their inbox a bit more clear and tidy.
I have tried to use the condition of Assignee, Requester and Current User IS NOT (name), but I am not sure that actually is the solution.
Thanks
Katerina
Katerina,
Customizing the Conditions will not be able to do it, since Conditions just change when the Trigger runs - you need to customize the Actions that are being run.
The simplest way may just be to keep using the default "Email group" action, but have the specific admins filter their own email using server-side rules based on subject and/or email body, if they have the power to do so in your email system.
Alternatively, if you have the ability to create a group email address (aka Distribution List) in your email system, you could create a new group with all the correct Agents but neither of the Admins as members, then use the Email Target Action instead of the default "Email group" Action. See screenshots and further explanation below:
Above: Default "Email group" Action
Below: "Notify target" Action
(The "Message" can be exactly what would be in the "Email body" in the 'default' way of doing things.)
As for setting up your email target, you would simply go to https://[your subdomain].zendesk.com/targets/new/email_target and fill out which email address you want to send to, as well as what you want the subject to be:
Because the Subject is specified in the Email target and not the Action in the Trigger, you may need to create several targets with the same Email address, e.g. one for ticket has been created, one for ticket has been assigned, one for ticket has been reopened, etc. -- just give each one a descriptive enough title that you can pick it in the "Notify target" Action in your Trigger.
I hope this helps! As mentioned above, doing things this way isn't as simple as telling the admins to filter their own inboxes, but it could also be used for other purposes - most orgs probably have many more DL's defined in their email system than they have Groups in ZD, and you could use those pre-existing Email DL's in various ways as Email Targets.
I love using exclusionary tags for a workflow like this!
Step 1: Add a tag to the user profile(s) that you want to suppress notifications for (ie "DoNotNotify")
Step 2: Add an ALL condition to the trigger: Tags contains none of the following "DoNotNotify"
This should stop notifications from being sent to specific users. Hope this helps!
Brandon
I want to create a trigger that sends out an update if an (external or internal) comment has been added.
But I don't want to send this update when someone just changed the attributes for a ticket (example: set a tag, or changed the priority, etc.)
How can I do that?
Christopher,
I believe the condition you are looking for, besides "Ticket Is Updated", is "Comment Is Present (public or private)":
Usually, "Present, and requester can see the comment" is a better option when your notification is going to be sent to an End User, unless you want to notify the requester even though they can't see the Private note that got added.
If you also wanted to exclude cases where the requester is the one who made the comment, you could add another condition, "Requester Is not (current user)":
Hello!
Short story. I`m using third party add-on, that works perfect in most aspects, but creates too much garbage tags, and I dont want to turn tags off on this add-on, because some of these tags are helpful. So I created a trigger that removes these garbage tags and every day I spend 3-5 mins to update this trigger, adding new tags to trigger to remove. I know it`s not optimal, but it`s not a problem. There are hundreds of tags now in this trigger.
Article says that there is a limit of 65kb. Question: how can I check the size of my business rules?
Hi Aleksandr Bogatiuk,
There is not a way to check in the product the size of the business rule. Eventually an error would stop you if it went past the allotted size. I've been at Zendesk a few years and have seen some massive business rules, but have still never seen one that was too big so it would take a lot of conditions/actions in order for this to occur.
That being said, it sounds like new tags are added all the time but perhaps not all of the old ones are still needed? I would recommend clearing out some of the old tags as you go to keep the size of the trigger under control.
I hope this was helpful - please let us know if we can help further!
Hello,
I'm creating a trigger for whatsapp, which sending a reply notification through whatsapp.
How to add video or image in the reply?
I'm using json body for the editor
Thank you.
Hello Lisa Amanda,
I saw that you already have a ticket with us and it's now assigned to our Whatsapp Messaging experts. Sorry for any delay on that ticket as we are still experiencing a large volume of tickets, and that takes us longer than usual to reply.
If you have additional questions or concerns about this, please follow up there. Thank you! :)
I think this is not covered in the article: Trigger doesn't fire if actions not needed to be performed (ticket is not changed by executing trigger).
Example: I have simple trigger.
Conditions
Status: is not solved
Ticket comment text: contains following string: "test string"
Actions:
Add tag: Test
First run
New ticket, no tags
I add comment: "test string"
Trigger fires!
As result I have tag: test.
Second run
I add comment: "test string"
Trigger DOES NOT fire.
Thris run
I remove trigger "test"
I add comment: "test string"
Trigger fires!
This could be pain, while debugging triggers. I expect if conditions met, trigger's fired.
Hi Pavel Kolpakov -
This is interesting as, since there is no action for the trigger to take, it does not run. Operationally you wouldn't want that trigger to fire but I can see your concern as it relates to debugging your Triggers. Thanks for sharing that piece of information!
Hi, Brandon Tidd
I'm curious how that work. Because if I have trigger that only notifies target. Will ZD know that trigger is actually doing something or it just won't fire it at all?
Since august 12th we have floating issue with triggers. And I can assure that behavior changed, because for several month it worked like charm (we a few 1000 of successfull examples of trigger fires before and not fires after for same string)
Example: Trigger was set to fire when ticket comment contains at least following words: #assign:onboarding
When ticket comment has such string, for example: #assign:onboarding$Pavel Kolpakov it wouldn't fire
Using try and error method I found that excluding colon sign ":" from marcos and from trigger will make it work again.
Just few minutes ago, I found that if I change condition to search for "Contains the following string" (instead contains at least following words) trigger fires again (I think the article above states about space to be delimeter and colon sign ":" will not make it separate word). So before I found that, when I tried to repro issue on other ZD account, I stumbled a few times with such behaviour when ZD just doesn't fire trigger with all conditions met
So in the case of notify target - that trigger should fire every time the conditions are met, as there will be a need to notify the target. When it comes to adding tags, as long as the tag is added no further action is needed so the trigger wouldn't fire downstream. In the case where you have the actions set to add trigger and notify target, the trigger would fire every time because notifying the target is still a unique action. It all comes down to really things. 1) Are the conditions met? 2) Do I have an action item to complete? If even part of #2 is true, the trigger runs. I hope this helps!
We're providing customer support for multiple destinations via one email address, and I've tried to set up the triggers as 'comment text contains none of the following words' and then use the cities that guests will mention in their messages to us to slot these requests into the correct support group. Below is a request we received for Berlin, and although I have a condition in Paris Support Group's trigger as 'comment text contains none of the following words - Berlin' we still get messages that are grouped into this group rather than Berlin's group. I'm sure there's a better way to do this, but we're limited with a generic email that guests often use to reach us. What am I missing?
Hi Jennifer Rowe,
When an agent creates a ticket on behalf of the requester, is it possible to create the trigger to send an out bound email - but have no triggers act upon it?
And if so, what conditions would you need to set?
Thanks
Bart
Sadie Sumner are you sure that your "not Berlin" condition is in the "All of these" section rather than the "At least one of these" section of the trigger conditions? Otherwise, a screen shot of your trigger would help.
Bart
Step 1 -- Detection --I am not aware of any condition for differentiating between a user-created and an agent-created OBO-user. Depending on how your users normally submit forms, you might be able to differentiate between them based on channel (e.g. email vs help center) or forms (user form vs default internal form). If none of those are practical, you could use a checkbox to set a tag and ask your agents to check that box when they submit a ticket OBO user.
Whatever method you use to detect these tickets, I would recommend that you define a trigger whose sole purpose is to detect them and set an appropriate tag, maybe named "do_not_process" or whatever.
Step 2 - suppression. You say "have no triggers act upon it". But clearly you want at least one trigger (the outbound email) to act upon it, so you'll need to define what you mean more precisely. For each trigger that you want to ignore these tickets, you would add a condition: Does not contain tag "do_not_process".
Heya @jonathan march,
Thanks for that - I think I would have to create a condition when agent creates ticket - a tag is added - maybe make it the first trigger so no other triggers fire after.
Main issue for me here is that with hundreds of triggers - you have to go through each one and add this new tag to each trigger so they don't fire.
I was hoping for a solution where creating an outbound ticket wouldn't trigger any other trigger without having to add a tag or similar. Almost like adding the condition that if ticket is created by agent and not requester (end user) no triggers fire.
Bart,
Tagging to Jonathan's reply. Here is how we do it in our instance:
We created a Ticket Field field to allow us, among other things, trigger on how the tickets are generated using a drop down list [also supports reporting on].
The Trigger:
Ticket > Is > Created
Requester > Is Not > assignee
Ticket Field: Ticket Generated By: > [ your drop down list] i.e. how many labels on how/who is generating the ticket. We label how the ticket was created including other back office system automation.
Actions
Email User > (requester)
Email Body: include your message along with any placeholders to automate as much as possible such as ticket ID, ticket title, ticket description........
My Comments:
Since you are Triggering off of Ticket > is > created, it will only fire once. You could also leverage tags to add/delete them as trigger variable, but might be a little overkill for what I understanding as your need.
Then again this approach might not fit your instance.
> Requester > Is Not > assignee
Nice @richard !
> with hundreds of triggers - you have to go through each one and add this new tag to each trigger so they don't fire.
Yep. While I understand why it's not supported (too fragile), I do wish that ZD supported a code-based trigger model so that you could just put all the other triggers inside an if-then-else conditional. (It would also be a lot easier to read and comment.) But it doesn't, so you can't.
On the up-side to this effort: if you put in a general suppression tag condition on all your triggers (as we did, years ago) then you can turn it on not just for this case, but for any similar cases that may arise later, by just adding one new trigger high up to set that suppression tag.
Hi Jonathan March and Richard Dawson,
Thanks guys for all the help. Both great suggestions. I've checked which triggers were firing upon the creation of the ticket and added to those triggers ticket topics that won't fire based on the ticket field - (in this case we're using a macro that adds a ticket topic to our ticket field - and added this as a topic that cannot be present).
In the end lots of good solutions - and will need to think longer term for scalability, which I like based on a new ticket field, but I also like the idea of adding a tag for suppression - which I would simply have to add to new triggers as they get created.
Thank you Jonathan March, I'm going to try and move these to 'meet all of' rather than the 'meet any of'.
We have a standard "email requester" trigger set up for any new ticket received. I created a slightly different version of this for a subset of tickets we receive.
My issue is that the original trigger sends emails to the requester from our general support email address (which is correct), but the new one I created is sending emails to requesters with my personal name attached.
How do I modify the sender name for the email to requesters to reflect our general support name?
Please sign in to leave a comment.