To help you get started with triggers, Zendesk Support provides a standard set of triggers and mail notifications that are best practices in a typical ticket workflow. You can use these triggers as they are or clone them to make copies that you can modify and repurpose. You can deactivate these triggers if needed. If you reactivate a trigger, it will not retroactively run on past tickets.
You can use the default triggers as they are or you can clone copies to modify. You can also edit default triggers, but it's better to clone them. You can deactivate these triggers if needed
For information about creating triggers, see Creating triggers for ticket updates and notifications.
The article contains the following sections:
- Accessing your triggers
- Default trigger best practices
- Notify requester and CCs of received request
- Notify requester of new proactive ticket
- Notify requester and CCs of comment update
- Notify assignee of comment update
- Notify assignee of assignment
- Notify assignee of reopened ticket
- Notify group of assignment
- Notify all agents of received request
- Auto-assign to first email responding agent (inactive at sign up)
Accessing your triggers
You can see all of your triggers on the Triggers admin page.
- In Admin Center, click the Objects and rules
icon (
) in the sidebar, then select Business rules > Triggers.
Default trigger best practices
- Do not deactivate all triggers. Triggers are the mechanism that deliver email notifications of ticket updates to end-users and agents. If all triggers are deactivated, email notifications about ticket activity will not be sent.
- If you want to alter a default trigger, clone it and create a new trigger based on its structure, then deactivate the original default trigger.
- Consider deactivating the Notify all agents of received request trigger, to avoid clogging your agents’ inboxes unnecessarily. Unless you have a very small team, you probably don’t need to inform all of your agents about every ticket submitted.
Notify requester and CCs of received request
Notifies the requester and anyone who is copied on the ticket via email that their request has been received and has become a ticket. For information on editing the email, see How do I edit the automatic response sent to someone who submits a ticket? in our Support tech notes.
When ALL of these conditions are met:
- Ticket | Is | Created: An
end
user
or agent submits a request, which has created a new
ticket.
AND
- Status | Is not | Solved: When created, the new
ticket has one of the following statuses applied to
it: New, Open, Pending, or On-hold.
AND
- Privacy | Is | Ticket has public comments: The
ticket has public comments.
AND
- Comment | Is | Public: The ticket has public
comments.
AND
- Current user | Is | (end user): The user that last updated the ticket is anyone who is a registered user, but not an agent or an administrator.
The following actions occur:
- Email user | (requester and CCs): The email
defined in this action is sent to the end user or
agent listed as the ticket's requester and anyone
who is copied on the ticket. The requester is
most-commonly the person who submitted the ticket;
however, an agent can submit a ticket
request on behalf of another user, in which
case that user is listed as the requester. Note: The trigger action Email user + (requester and CCs) is suppressed if a ticket update does not include a public comment. The trigger still fires and performs any other actions that may be included in the trigger, but the email message is not sent. You must include a public comment if you want to use this action to send an email message.
Notify requester of new proactive ticket
When an agent creates a new proactive ticket with a public comment, the requester is notified via email. A proactive ticket is a ticket created by an agent on behalf of the requester.
When ALL of these conditions are met:
- Ticket | Is | Created: An agent creates a ticket
and submits those changes.
AND
- Privacy | Is | Ticket has public comments: A
public
comment is added to the
ticket.
AND
- Current user | Is | (agent): The user who created the ticket is an agent, not the ticket's listed requester.
The following actions occur:
- Email user | (requester and CCs): The email defined in this action is sent to the end user listed as the ticket's requester and anyone who is copied on the ticket. This notification is send only once when the ticket is created. After that, other trigger notifications configured in the account apply.
Notify requester and CCs of comment update
When an agent or end user adds a comment to the ticket, the requester and CCs are notified via email. Notification is suppressed and not sent to the requester or CC if they make a ticket update themselves.
When ALL of these conditions are met:
- Ticket | Is | Updated: An agent or end
user
updates a ticket, and submits those
changes.
AND
- Comment | Is | Public: The ticket has public comments.
The following actions occur:
- Email user | (requester and CCs): The email defined in this action is sent to the end user or agent listed as the ticket's requester and anyone who is copied on the ticket. Typically, the person who submitted the ticket is the requester; however, an agent can submit a ticket request on behalf of another user, in which case that user is listed as the requester.
Notify assignee of comment update
Notifies the assigned agent when a comment is added to the ticket. Comments can be either private (internal notes added by an agent) or public (added by an agent or the requester).
When ALL of these conditions are met:
- Comment | Is | Present (public or private): A
public comment or internal note must be added to the
ticket.
AND
- Assignee | Is not | (current user): The person
submitting the comment above cannot be the ticket's
listed assignee.
AND
- Assignee | Is not | (requester): The ticket
assignee cannot be the ticket
requester.
AND
- Assignee | Not changed: The ticket assignee is
not changed in the current update.
AND
- Status | Not changed from | Solved: The ticket's status is not changed from the Solved status in the current update. That is, a solved ticket is not being reopened as part of the current update. However, the ticket status can be changed from any other status (New, Open, Pending, or On-hold) without blocking this trigger. For sending a notification about a reopened ticket, see Notify assignee of a reopened ticket.
The following actions occur:
- Email user | (assignee): The email defined in this action is sent to the end user or agent listed as the ticket's assignee.
Notify assignee of assignment
Notifies the agent who has been assigned to a ticket of the new assignment.
When ALL of these conditions are met:
- Assignee | Changed: The assignee listed on the
ticket is changed to another
individual.
AND
- Assignee | Is not | (current user): The person making this change is not assigning the ticket to themselves. For example, if an agent is viewing a ticket and clicks the take it link, this condition is not met.
The following actions occur:
- Email user | (assignee): The email defined in this action is sent to the end user or agent listed as the ticket's assignee.
Notify assignee of reopened ticket
Notifies the assigned agent of a solved ticket that the ticket was updated with a new comment by the requester and reopened.
When ALL of these conditions are met:
- Assignee | Is not | (current user): The person
making this change is not assigning the ticket to
themselves. For example, if an agent is viewing a
ticket and clicks the take it
link, this condition is not met.
AND
- Status | Changed from | Solved: The ticket status
is being changed from Solved to another status
type.
AND
- Status | Is not | Closed: The new ticket status is not Closed.
The following actions occur:
- Email user | (assignee): The email defined in this action is sent to the end user or agent listed as the ticket's assignee.
Notify group of assignment
Notifies a group when a ticket is assigned to a group to which they belong.
When ALL of these conditions are met:
- Group | Is not | - : The ticket is currently
assigned to a group; that is, it Is not
assigned to no (-) group.
AND
- Assignee | Is | -: The ticket is not currently assigned to an individual user; that is, it Is assigned to no user (-)
...And ANY of these conditions are met:
- Group | Changed: The group assigned to the ticket
has changed in any way.
OR
- Assignee | Changed: The user assigned to the
ticket has changed in any way.
Both of these conditions must be included in this trigger to ensure the notification is sent whether the ticket is assigned to a group or a user before it is reassigned to the new group.
The following actions occur:
- Email group | (assigned group): The email defined in this action is sent to the group listed as the ticket's new assignee.
Notify all agents of received request
Notifies all non-restricted agents when a new ticket is created that has also not been automatically assigned.
When ALL of these conditions are met:
- Ticket | Is | Created : An end
user
or agent submits a request, which has created a new
ticket.
AND
- Group | Is | -: The ticket is not currently assigned to a group; that is, it Is assigned to no group (-).
The following actions occur:
- Email user | (all non-restricted agents): The email defined in this action is sent to all agents, except those who cannot view the ticket based on their permissions.
Auto-assign to first email responding agent (inactive at signup)
Assigns the ticket to the agent when the agent replies to the ticket notification they received by email. You must activate this trigger for it to run.
When ALL of these conditions are met:
- Ticket | Is | Updated : An agent or end
user
updates a ticket, and submits those
changes.
AND
- Update via | Is | Email: The ticket was updated
by responding to an email
notification.
AND
- Assignee | Is | -: The ticket is not currently
assigned to a user; that is, it Is assigned
to no user (-).
AND
- Current user | Is not | (end user): The person making this change is an agent; that is, not an end user (customer).
The following actions occur:
- Assignee | (current user): The ticket is assigned to the agent making the changes to the ticket.
50 Comments
I am having trouble getting my Auto-assign to first email responding agent trigger to activate.
It is currently in my list of active triggers and is not being undone by another one.
Auto-assigning the first person to reply should be a default standard trigger included with Essentials. It's a pretty basic and expected function of any ticketing system.
Auto-assigning the first person to reply would not be welcome, but as long as I can easily defeat that action I suppose it is OK. We would Never use that option.
If I changed some of the conditions to a default trigger and wanted to go back to the original conditions, is there a "reset a default trigger" button
Does the "Notify assignee of assignment" trigger not apply when the agent assigns him/herself?
I don't recall if we customized the Notify Assignee of Assignment trigger, but ours does not notify the agent if he/she assigned it to him/herself because we have the condition in the trigger that nullifies it if the current user makes the change to the ticket:
I can confirm that is the default setting, Heather and Candace. "Assignee Is Not Current User" Mine is that way and has never changed for the years we have used Zendesk.
Frojon
Wonderful! thanks for the help @Frojon and @Heather! Our agents pick up their own tickets from the queue, so it makes sense why this trigger has only been tripped a handful of times.
In your screen shot for "Notify requester of comment update" the placeholder ticket.comments.formatted is no longer showing as an available placeholder in the "available placeholders" section in my account when I am trying to set up this trigger
Is there a list of what the default triggers should look like?
Are the screenshots in this article showing the default triggers?
As a reference in the unlikely event one forgot to clone before changing ;-)
Plus one the reset default trigger option.
Hi Chris,
Fortunately, you've landed on the exact article that will show you what these default triggers should look like :)
The screenshots above list how the triggers are set up when your Support account is created.
If there's a particular trigger you're experiencing issues with please let us know.
Cheers!
Any way to use guide articles links as placeholders in triggers' text?
I'm just looking for a plain hyperlink with text. Nothing fancy.
Such as found in this messaging box I'm using for example.
Thanks!
Is there any good way to notify certain assignees of assignment, instead of all assignees? I understand that we can add the assingees' names to the "meet ANY condition" section, but this is very hard to manage when the list grows longer.
Thanks.
Hi Ping,
Are you saying that not all your assignees want to be notified they were assigned a ticket? I think you're right the only way is to update the Trigger. If you don't want to use the "meet ANY condition" and list the ones that WANT to be notified, I would use the AND conditions to exclude agents that don't want to be notified. This way the default is yes, they would be notified....
Hi Heather,
Thanks so much for coming back to me so quickly. Our situation is that we have around 26 agents (and growing), and about half of them like to be notified while others don't. So either way this would make the trigger look messy, plus I'm not sure if there is a limit on how many conditions can be put there.
Ideally, the trigger could check the value of a custom field of users, e.g. "accept notification" for the assignee.
Thanks.
Hi Ping,
Hmmm, that's a lot of customizing then. I'd say a different way to go about this would be to add a tag to the Agents' profiles that don't want to be notified, something like no_assign_email and then add the condition to your AND condition "Tags..." "Contains none of the following".
That should do the trick! Just remember to modify to your onboarding process/documentation to add or not add the tag to new Agents based on their preferences.
Hi Heather,
Agent tags don't work in my tests as they don't seem to be passed down to tickets.
I tried a different way in the test though, by adding an "allow_assign_email" tag to an agent, and creating an ANY condition of "Contains at least one of the following" to Tag. Is there anything that I missed or did wrong?
Thanks so much.
Hey Ping,
As it turns out, agent tags will not carry over to the ticket unless the agent is the requester of the ticket. I can't think of another alternative other than adding the agent's individual names to the trigger, but as you said, that can be a bit tedious.
The only other alternative I can think of would be to have the agents that don't want to be notified set up an email rule in their inbox that filters out these notification emails.
Let me know your thoughts.
I wish I could delete my last comment. I definitely steered you down the wrong path with Agent tags, it completely slipped my mind that they have to be the requester for my suggestion to work. My apologies!!
Hi Heather,
No worries. What you suggested actually makes sense, only that Zendesk trigger doesn't support conditions on Agent/User tags, which is kind of unexpected.
Hi Brett,
Thanks for the clarification. I guess we would have to find solutions out of Zendesk for now then.
I do wish that some day agent/user tags can be supported in trigger condition. This can be very helpful.
Thanks.
One more question: is there a limit on the number of conditions that can be added to a trigger? I'm not able find a document mentioning it. In my test the trigger seems to accept more than 20 ANY conditions. Thanks.
I am not aware of any limitation. I've used at least 20 trigger conditions myself without issue! Maybe if we stay under the 100 mark we'll be ok? LOL
Got it, thanks a lot Heather :)
I can say that I've had several hundred conditions in a single trigger. The main problem is it gets annoying to update that trigger and the page can be a bit troublesome to navigate. It's been a year since I had that scenario, but it was usable if you had to do it. If your use case is to add email addresses/users in like mine was - the challenge was keeping an eye out for duplicates and keeping the trigger clean.
Rather than having many conditions in a single trigger, I would recommend breaking it up into multiple triggers, each of which has a sane number of conditions and sets the same tag.
Follow these with another trigger, which tests for that tag and does the actual work.
Thanks Dan and Jonathan, and that's why I believe the support of agent tags in triggers could be a better solution. Trigger conditions keep clean and neat, tags are easy to search in views, and no duplicates.
Please sign in to leave a comment.