Setting up a new Zendesk Support can involve many different configuration and customization steps, which may just also introduce you to some support tools and concepts that you may not already be familiar with. I am not going to give a tutorial to set up a new Zendesk Support trial, I am going to focus on a single section of Zendesk Support functionality that many people are initially confused by: triggers.
All new Zendesk Support accounts have eight active default triggers. These triggers are tried and true ways of notifying both the requester and your support staff about the steps involved in creating and solving a ticket. You can think of these triggers are your old hometown best friends, that although they may not share your current interests and fast paced living, they share a heartwarming past with you that gives you the very basics of what you need. They were the triggers that went on an adventure with you so many summers ago to look at a dead body and gathered enough courage to finally stand up to Keifer Sutherland. So think twice before you decide to start with a clean slate and deactivate every system created trigger.
These triggers can be divided into four different categories.
Notify the requester (i.e. your end-user or client) of an action that took place on their ticket:
Notify requester of received request
Notify requester of comment update
- Notify requester of solved request
Notify the assignee (i.e. agent) of an action that took place on a ticket that they are assigned to:
Notify assignee of comment update
Notify assignee of assignment
Notify assignee of reopened ticket
Notifying a group of agents of a new assignment:
Notify group of assignment
Notifying all agents in your account when a new ticket has been received:
Notify all agents of a received request
Trying to figure out what triggers will do and how they will work together is sometimes difficult to do just by examining the conditions they contain. To best illustrate how these default triggers work, we’ll track the lifecycle of an example ticket and see what triggers are activated at each step and discuss why other triggers did not also get involved.
What happens when new tickets are created
First, we start out with our requester sending an email to our support address. This causes two of our default triggers to fire off immediately: Notify requester of received request and Notify all agents of received request .
- Notify requester of received request , fired because a ticket was created and the status was not solved (in other words, it's a new ticket that an agent needs to solve).
Notify all agents of received request , fired because a ticket was created and there was no support group automatically assigned to it. By receiving this notification, an agent can claim the ticket and work on solving it.
Notify group of assignment did not fire since no group was automatically assigned to the ticket
Notify all agents of received request and Notify group of assignment have the mutually exclusive conditions of Group is and Group is not to prevent double notifications from being sent and to cover the email notification if you have a rule to automatically assign tickets to a group.
Updating the ticket with comments
The next step normally involves your agent responding to the ticket and setting the ticket to pending because they may need more information from the requester or they want to see if their proposed solution works for the requester before setting the ticket to Solved.
- Notify requester of comment update is fired and an email is sent to the requester, when the agent updates a ticket with a public comment (visible to the requester), and sets the status to Pending instead of Solved.
Notify assignee of comment update trigger sends out an update notification to your agent when your requester replies to the ticket with a comment, and the ticket is automatically set to Open. This trigger can also fire off if another agent on your team leaves a private comment for the assigned agent. This is because the Comment condition accepts both private and public comments, which enables greater collaboration among your support team.
Solving the ticket
After a spirited back and forth between your agent and requester and the issue is resolved, the agent adds a public comment and sets the ticket to Solved.
- Notify requester of solved request : is used to sent a notification to your requester instead of Notify requester of comment update. It is interesting to note that the mutually exclusive conditions that prevent Notify requester of solved request and Notify requester of comment update from firing at the same time is whether or not the ticket’s status has been changed to Solved. So if your agent leaves another public comment and leaves the status as Solved, the trigger that will notify your requester of the update will be Notify requester of comment update , not Notify requester of solved request trigger .
Reopening the ticket
Finally, your requester then wants to respond to the solved ticket with a thank you or ask an addition question.
- Notify assignee of reopened ticket notifies the assigned agent that a new comment has been added and that the ticket has been set to Open again.
Keep your default triggers!
It’s important to remember that if you disable or delete these default triggers and then do not create equivalent custom triggers, no notifications will be sent out to your requesters or assignees. So go ahead and set up custom triggers that will direct ticket flow and establish business rules to streamline your support team, but keep your old default trigger buddies around, check in on them every once in a while, and don’t let 10 years go by before you discover that a careless administrator took them away forever.
If you need to reset a default trigger, see Resetting default triggers for more help.