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, seeStreamlining 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 (seeTriggers 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 intocategories.
Understanding trigger conditions and actions
Triggers contain conditions and actions. You combine these to create ‘if’ and ‘then’ statements (ifthe ticket contains a certain set of conditionsthen行动使更新的机票和选择ionally 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 –allconditions andanyconditions.
Theall条件,你亲bably already figured out, must all be true. If a single condition statement in theallconditions section fails (is not true), the trigger will not act on the ticket.
Additionally at least one of theanyconditions 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 theanysection, it will behave like anallcondition 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 triggersrunin a cycle against that ticket in the order the triggers are listed. A trigger willfireand 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 mightrun(that is, be checked) several times during a cycle, but it will neverfire(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.
46 Comments
HeyClarice Matt
In this case, you'll need to update your macro actions to ADD tags, not SET tags.
Hope this helps!
Brandon
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!
HeyRebecca 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 featuredin this post. Hope this helps!
Brandon
Perfect thank you again!
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 triggersrunin a cycle against that ticketin 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 oftrigger conditions and actions.
I hope this helps!
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
HiLeandi 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
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).
例如,最终用户或cc人或其他闲逛ht 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,
Is there a way to edit the dropdown fields for a trigger? It is easy with forms. Why the restriction with triggers?
Hello,
We are testing the HubSpot - Zendesk integration, especially the one created by亚博.
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!
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.
这是驾驶我疯了:
HiPAUL 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
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?
Does anyone know how "greater than" works in the context of setting a trigger condition using the Status field? If i set it asStatus Greater than On-Holdwill it work for both the Solved and Closed statuses?
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.
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!
Pleasesign into leave a comment.