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 and managing triggers, see Creating and managing 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.
- Click the Admin 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.
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.
49 Comments
Can you exclude agents from getting email notifications? I've put in meet all of the following conditions under Notify group of assignment, ex assignee is not Kristine. Put some agents still get email notifications and some get notifications from a week ago? Can you tell me what I did wrong?
Kristine Siim Viftrup, could it be that these agents are receiving cc emails?
If not, could you share a screenshot of your trigger?
Hi
I have a trigger that sends an email when a ticket is assigned. The email the agent receives includes a whole section of the ticket's data that are not in my trigger.
I wonder where does that section comes from.
Can I remove/edit them?
Here is a picture.
Hi Jean,
It is not possible to remove that section as that is default behavior for notifications sent to agents. However, I just wanted to let you know that this is only present in messages that are sent to agents. Your end-users will not see that information on other trigger responses. I wasn't sure if that was a concern of yours but I wanted to clarify that.
I hope this is helpful!
Ben - Thanks for your reply.
I wish I could at least add fields into that section that we consider important. I guess I will add the placeholders I need into my triggers.
how can i deactivate the trigger that sends all emails to the account owner? I understand the trigger for agents receiving the emails but how can i stop the acct owner from receiving all the emails?
Hi Jam -
I suggest to first make sure you really want to deactivate the trigger. Maybe you just need to change the recipients in the trigger's Action.
If you are 100% sure you want to deactivate the trigger go to:
Settings > Triggers
locate and open the target trigger
Click the three little dots at the top right
Click Deactivate.
Hi, there!
It seams notifications are sent to Email group | (assigned group) following Support default language no matter using Dynamic Content. Is that the expected behaviour?
Regards,
Renato
Hi @...,
The language that dynamic content is sent, is based off of the language of the requester on the ticket. When you look at one of the ticket examples where this occurred, is the requester's language set properly and do you have a dynamic language variant for that language?
This document has more: https://support.zendesk.com/hc/en-us/articles/115007231608-How-does-Zendesk-set-a-language-for-a-user-in-Support-
Thanks!
Hello, Ben Van Iten!
Thanks for your reply, but I'm afraid you misunderstood me.
Based on tests performed in here, having agents A, B and C each one with a different language but being part of the same group, no matter ticket requester language neither DC default variant, Email group | (assigned group) always sends DC following Support default language. Changing language of agents A, B and C in order to have the same one, no matter which, Email group | (assigned group) sends DC following this language. Said that, could you or anyone else please confirm this is the expected behaviour?
Regards,
Renato
Hi @...,
I was referring to the language of the requester, not the language of the agent.
Please let me know if you have any further questions on this!
Hello, Ben Van Iten!
I’m sorry to insist.
Part I
Scenario A
Scenario B
Part II
Scenario C
Scenario D
Part III
Scenario E
Scenario F
Based on these test results, having agents A and B each one with a different language but being part of the same group, no matter ticket requester language neither DC default variant, Email group | (assigned group) always sends DC following Support default language.
Is that the expected behaviour?
Regards,
Renato
Hi @...,
Thanks for the detailed explanation. That does not sound expected to me. I am going to turn this conversation into a ticket so our support team can look at the tickets on your side more in depth and determine why this is happening.
Hi, Ben Van Iten!
Thank you very much!
Regards,
Renato
Hi Guys,
I'd like to implement a trigger which will notify only members of specific group of assigned tickets to it.
So scenario, where group is changed to this one, but no assignee.
Any Ideas how to modify Notify group of assignment trigger in order to do this?
Hi Damian Przybyła - Happy to help! Depending on your exact use case, you'll want to modify the Notify group of assignment trigger or create brand new triggers (if you have a few different groups you'd like to get this setup for) similar to the criteria below, with "Group A" being a placeholder for the exact group you'd like to notify.
Conditions - Meet ALL of the following conditions
Group Changed to Group A
Assignee is -
Actions
Email Group Group A
Hope that helps!
Hola, quisiera saber como puedo usar los disparadores para Integraciones de Canal (en este caso Whatsapp)
__
English translation added by Zendesk Community Team via Google Translate:
"Hello, I would like to know how I can use the triggers for Channel Integrations (in this case WhatsApp)"
Hello Servicio al Cliente,
There is a Channel Integrations option under the Channel and Update Via trigger conditions, which might be helpful for what you're doing. You can learn more in this article about the Trigger conditions and actions reference.
I hope that helps!
Quick Tip for Extending Auto-Assignment to First Responding Agent
If you want to automatically assign a ticket to the first responding agent, regardless of the response channel, you might want to remove the Update via: Email rule.
Now, an agent only needs to reply to a ticket, and it will be automatically assigned to him, even if he forgets (or doesn't want to bother) to click the Assign to me link button.
But as I soon found out, the new rule interferes with the use case where one would want to reassign a ticket back to a user's group. The assignment would be reverted and the agent that tried to assign the ticket to the group, gets himself assigned to the ticket instead.
To fix this, add another required rule of Group: Unmodified.
There you have it. Fixed.
Please sign in to leave a comment.