Triggers are business rules you define that 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.
This article contains the following sections:
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.
- To help you manage large numbers of triggers, triggers can be organized into categories.
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 into 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 anysection, 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.
73 Comments
Can I set triggers when an article is created with a certain label?
Triggers do not run or fire on tickets after they are closed. However, triggers can fire when a ticket is being set to closed
What does it mean "set to closed"?
what is the maximum number of conditions(ANY/ALL) we can have for a trigger??
Do the triggers run in sequence from top to bottom?
@Suzie,
I don't think triggers on the Support account will run on Guide articles. That's an interesting thought though. I hope you post that with your reasoning in the Product Feedback area.
@Jiju,
"Set to closed" is when a ticket goes from Solved to the uneditable Closed status via automation.
@Carol, yes Triggers run in order top to bottom.
@Suhas, I am not sure what the max is but I've had dozens of conditions in triggers with no issue.
How can I set a trigger to send only once?
@Albert,
I might need more information to give a better answer, but usually a way to do that is to add these conditions to your existing trigger that you only want to fire once:
And Ticket does not contain this Tag: tag123
Perform these actions:
Add Tag: tag123
This way, when the trigger fires off the first time, it adds tag123. When it goes to run on that ticket again for whatever reason, it sees "tag123" on the ticket and DOES NOT FIRE.
I hope this helps!
Please feel free to give more details of what you're trying to achieve if this doesn't do the trick.
-Heather
Is there any way to add all Email notifications that are part of a Trigger to the ticket as an internal note automatically instead of manually? It's quite inconvenient to have to switch to 'Events' to see all the correspondence that has been sent to customers.
Put the content of the email in the message and it will be posted as a private comment
Is there some way to create a trigger that is a field in the the submission form?
It can be done through the API if it is a form on the website. If it is a zendesk ticket form then all the ticket fields (custom/system) are already in the trigger conditions. For text fields also there is an option of present/not present.
Suhas,
Thank-you for your prompt reply! I am not well-versed in Zendesk, so please forgive what might be very elementary questions.
The form I am referring to is the Submit a Form that our users will see on our Knowledge Base page. I do not see any Triggers available like those you describe. Is that because I have an Essentials subscription?
Thanks!
I believe that could be the issue but still if you have the option of tags then you can tag your tickets and create an automation/trigger based on that condition. Or the comment text but I'm not sure about what exactly is available in the essential plan.
Note: On Essential, you have a limited selection of conditions and actions to choose from when creating or editing triggers.
Lastly,I would recommend you to take a look at the API documentation as it is possible to edit tickets using this. Also look into extensions -> Targets to find more options to edit tickets
Michael, not sure whether this will help, but there seems to be some category confusion here. To be absolutely explicit -- no, there's no way that you can put a trigger into a form, because a form contains fields, and a trigger is not a field. Rather, a trigger is a rule, and you can define a trigger which responds to changes in a field (a.k.a to a "condition"), e.g. responds to the contents of a form when it is submitted.
I don't understand this point 'Triggers, like all business rules, must be smaller than 65k'. Can you clarify
Hi Heather,
That rule refers to a back-end process, a rule definition that includes meta characters and how we translate the rule conditions into code. It's rare to have a customer exceed this rule, but if you have any issues, let us know!
Hi,
How do I configure the triggers to not send notifications if we get an email from an email address that is for example noreply@example.com?
Best regards,
Óðinn Thor
Hi Óðinn Thor Harðarson,
I would suggest you add a tag (no_email or something similar) to users like that, which get passed on to any tickets created by those emails. Then go into your triggers and add the condition Tags Contain None Of The Following no_email
That should do the trick!
The caution is that you have to know the emails first, but even if you add the tags as you go along you should get to your objective in no time.
Is it possible to export a list of current triggers, along with their related conditions and actions?
Hey Luke,
You'll want to use the Support API to pull a list of your triggers along with their conditions/actions.
Hope this helps!
Is there a maximum number of triggers that can be set up?
Nevermind. I found the "Unlimited Triggers allowed" statement. :)
Thanks for the update Jen :)
Glad you were able to find the answer!
Are field values re-evaluated in each trigger during a single cycle? Let's say I have a name field which contains "John" and two triggers, both of which have an action to update the ticket with a comment containing the value of the name field.
so, trigger 1 fires, and updates the ticket with "John". This trigger also then changes the value of the name field to "Jane".
then trigger 2 fires (within the same cycle). When this trigger updates the ticket will it re-evaluate the value of the name field, this writing the comment "Jane", or will it use the value that it already had in memory for the name field as part of this cycle and update the ticket still with "John"?
Hi Lawrence,
In all the time I've used Zendesk, I've only known it to use the current value of a field. My suspicion is that in the scenario you're describing, Trigger 2 would "re-evaluate" the field and not use the original value.
That said, if you're using a trigger with notify target, there is a slight delay, and you might get inconsistent results.
All of that said, I'd test the heck outa this to ensure it works as you expect! :D
Hi Lawrence,
I investigated this in September 2012, both by experimentation and by information from ZD Level 2 support, and have not been aware of any changes since that time, either in the performance of our 200+ triggers nor in any subsequent documentation from ZD, so I would think that my summary from then would still be true:
"Trigger flow is not exactly as documented, nor as it appears in the ticket’s event log. All conditions are frozen at the beginning of a pass through the triggers. The triggers are executed in the order listed, but the actions are just queued up until all triggers have been checked. Then fields are modified according to queue order. Then if any fields were modified, another pass through all triggers is made."
My same 2012 summary also included the following question:
What is not yet clear is exactly when the placeholder values in notifications are set. Is it per pass, or at the end of all trigger passes?
This refers to the additional fact that no notifications are actually sent until after all possible passes through the triggers have been finished, i.e. until the values of all fields have stabilized. (So if pass 1 triggers an action "send notification", but there are 3 passes, then the notification won't actually be sent until after pass 3.) I *think* that the answer is that this notification's placeholders are set at the time that the notification is sent, not when the notification action is triggered, but I never received an answer on this and never did the experiment to find out, since the answer did not actually affect our workflow as far as I know.
Hope this helps.
Lawrence, a separate point:
> two triggers, both of which have an action to update the ticket with a comment containing the value of the name field.
Just to be clear and avoid future confusion -- Triggers can't actually update ticket comments, unless you are doing so via a "target" which uses the API to set a comment (vulnerable to race conditions, i.e. fragile, thus unsupported).
If that's really what you are doing, then as Heather said "test the heck outa this". Again, as with notifications, the question would be when the placeholder values in the target action are actually set.
Please do let us know what you learn!
What is the easiest way to create a trigger to email the Salesforce Account owner when a case is created? The account owners are not Zendesk users.
Please sign in to leave a comment.