To help you get started with triggers, Zendesk Support provides a standard set of ticket triggers with default notifications that are best practices in a typical ticket workflow. You may see these referred to as system triggers or default triggers. You can use the standard triggers as they are or clone them to modify and repurpose.
For information about creating custom ticket triggers, see Creating ticket triggers for ticket updates and notifications.
The article contains the following sections:
- Accessing the Triggers admin page
- Best practices for working with the standard triggers
- 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 signup)
Accessing ticket triggers
You can see all of your standard and custom ticket triggers on the Triggers page in Admin Center.
- In Admin Center, click
Objects and rules in the sidebar, then select Business rules > Triggers.
- Click the Tickets tab.
Best practices for working with the standard triggers
- Do not deactivate all triggers. Triggers are the mechanism that delivers 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 standard trigger, clone it and create a new trigger based on its structure, then deactivate the standard 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 > Ticket | Is | Created: An end user or agent submits a request, which has created a new ticket.
AND
-
Ticket > Status category | Is not | Solved: When created, the new ticket has one of the following statuses (or status categories) applied to it: New, Open, Pending, or On-hold.
AND
-
Ticket > Privacy | Is | Ticket has public comments: The ticket has public comments.
AND
-
Ticket > Comment | Is | Public: The ticket has public comments.
AND
- Ticket details > 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:
-
Notify by > User email | Ticket > (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: When a private comment is added to a ticket, the Email user + (requester and CCs) action is suppressed. Any other actions that may be included in the trigger are still performed, but the email message is not sent. You must add a public comment to the ticket 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 > Ticket | Is | Created: An agent creates a ticket and submits those changes.
AND
-
Ticket > Privacy | Is | Ticket has public comments: A public comment is added to the ticket.
AND
- Ticket details > Current user | Is | (agent): The user who created the ticket is an agent, not the ticket's listed requester.
The following actions occur:
- Notify by > User email | Ticket > (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.
When ALL of these conditions are met:
-
Ticket > Ticket | Is | Updated: An agent or end user updates a ticket, and submits those changes.
AND
- Ticket > Comment | Is | Public: The ticket has public comments.
The following actions occur:
- Notify by > User email | Ticket > (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:
-
Ticket > Comment | Is | Present (public or private): A public comment or internal note must be added to the ticket.
AND
-
Ticket > Assignee | Is not | (current user): The person submitting the comment above cannot be the ticket's listed assignee.
AND
-
Ticket > Assignee | Is not | (requester): The ticket assignee cannot be the ticket requester.
AND
-
Ticket > Assignee | Not changed: The ticket assignee is not changed in the current update.
AND
- Ticket > Status category | Not changed from | Solved: The ticket's status (or status category) 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:
- Notify by > User email | Ticket > (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:
-
Ticket > Assignee | Changed: The assignee listed on the ticket is changed to another individual.
AND
- Ticket > 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:
- Notify by > User email | Ticket > (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:
-
Ticket > 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
-
Ticket > Status category | Changed from | Solved: The ticket status (or status category) is being changed from Solved to another status type.
AND
- Ticket > Status category | Is not | Closed: The new ticket status (or status category) is not Closed.
The following actions occur:
- Notify by > User email | Ticket > (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:
-
Ticket > Group | Is not | - : The ticket is currently assigned to a group; that is, it Is not assigned to no (-) group.
AND
- Ticket > 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:
-
Ticket > Group | Changed: The group assigned to the ticket has changed in any way.
OR
-
Ticket > 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:
- Notify by > Group email | Ticket > (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 > Ticket | Is | Created : An end user or agent submits a request, which has created a new ticket.
The following actions occur:
- Notify by > User email | Ticket > (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 > Ticket | Is | Updated : An agent or end user updates a ticket and submits those changes.
AND
-
Ticket > Update via | Is | Email: The ticket was updated by responding to an email notification.
AND
-
Ticket > Assignee | Is | -: The ticket is not currently assigned to a user; that is, it Is assigned to no user (-).
AND
- Ticket details > 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:
- Ticket > Assignee | Ticket > (current user): The ticket is assigned to the agent making the changes to the ticket.
31 comments
Colina Insurance Limited
Hi. We are using the NOtify Requester of New Proactive ticket trigger, but for some reason the group, an consequently email address, that appears to the requester is not correct. FOr example, if an Agent in group Apples creates a proactive ticket, the requester has a reply to of group Oranges. How can this be fixed? Thank you
0
Lacey Simpson
For our alert "Notify Assignee of comment update", the assignee is also alerted when they have added a new comment to a ticket. Is there a way to stop that from happening?
0
Dave Dyson
HI Lacey,
Have you modified the default version of the "Notify assignee of comment update" trigger? The default version includes the condition "Assignee | Is not | (current user)", which should prevent the assigned agent from receiving a notification email from a comment update that they add themselves: Notify assignee of comment update
0
Lacey Simpson
Hi Dave,
It looks like our trigger must have been updated and that selection was removed. I just added it back, thank you very much!
0
Dave Dyson
Glad I could help, Lacey!
0
Brandon Fischer
I've had some clients reach out and explain that when they respond to an email (thus updating their ticket) they receive an additional email of their own message. This article states the following:
"Notification is suppressed and not sent to the requester or CC if they make a ticket update themselves."
But that does not seem to be the case at this time.
My settings for "Notify the Requester of Comment Update" are the default values.
- Ticket is updated
- Comment is present, and the requester can see the comment
I'm seeing that it is triggering on more recent tickets but when I look back at tickets from months or years ago it does not trigger when a client sends an email updating their ticket.
2
Rick N.
In order to investigate your issue further about triggers , I'll need to take a look inside your account. Right now the Account Assumption feature is disabled, but if you change the account assumption setting to “Enabled” you can grant me temporary access to troubleshoot the issue within your account. Please note that when you change the setting of this feature, all administrators listed on your account will receive a notification email.
If you’d like to enable this, please follow these instructions to access your settings. It would be very helpful if you were able to set access to at least “one week” in the event that this ticket needs more time to be assisted. Once enabled, please respond to this ticket and I'll be happy to help the best I can.
Also could you give me a ticket # which had this trigger fired on this particular situation so I can replicate it too once I got in to your account.
Cheers!
0
Brandon Fischer
Hi Rick,
Apologies for the long delay. I have enabled account assumption, currently set to "one week." This issue has been present for at least the last few months, so any recent ticket should suffice, but you can use #8557 as a reference. In comparison, looking at an older ticket such as #7160 does not show the same "Notify customer of comment update" event when a client send's an email.
1
Simon Wong
Rick N. I am having the same issue that Brandon has. I added the condition 'Current user is not end-user' but this doesn't notify the reporter if a CC update the ticket and vice versa.
1
Maria Hassam
Hello,
I am experiencing the very same issue as mentioned above, by Brian. When using the Notify Requester of Comment Update default settings ( as detailed in this article above), my customers are notified of their own comment.
I added an additional condition, as suggested by Simon Wong: Current user is not end user, and this seems to have resolved the issue. Now the customer doesnt get a separate notification message about their own comment.
I feel the article should be updated above to reflect this user-case.
1
Michael Kirchhoff
I am having trouble with Notify requester and CCs of received request whether they are registered users or not. It does not send an email to requester. It sends too many to the possible agents to accept.
0
Brandon Fischer
SOLVED!
After chatting with Zendesk Support and troubleshooting many variables, we found that the support article above is incomplete. For the "Notification is suppressed and not sent to the requester or CC if they make a ticket update themselves" clause to take effect, you need to add the following to the trigger:
Current user ---- Is not ---- (end-user)
This will not affect when agents update tickets, only when requesters (customers) update the ticket, like by sending an email for example.
1
Michael Kirchhoff
Sorry, but Greek response. Which trigger or triggers needs to be updated? Be more specific. Screen captures preferred. It amazes me that default triggers don't work as planned.
0
Brandon Fischer
The exact name of the trigger might vary depending on if it was renamed from the default "Notify requester and CCs of comment update." For example, my trigger is named "Notify customer of comment update." I often got confused with Zendesk's terminology for assignee, requester, etc., so I just refer to each group as agent or customer.
The easiest way to see which trigger needs to be changed is by clicking on any ticket with an email or message from a customer (or requester). Click on "Events" to see what Zendesk did behind the scenes when the message came in, and you should see something like this:
You'll want to click on the one that triggered the Email notification to [your customer's name]. That's the first trigger in the screenshot above, titled "Notify customer of comment update."
Make sure your trigger looks like the following:
0
Joshua Bentley
I've turned off the default triggers that notify the assignee when the requester replies, but I'd like to continue to receive those email notifications. How can I make it so that triggers like "Notify assignee of comment update" send only to me?
The trouble I've run into so far is that if I change the assignee to me, I get notified with every update I make to the ticket as well as the requester.
0
Chandra Robrock
Hi Joshua Bentley - To do that, you'd create a trigger similar to the "Notify assignee of comment update" trigger. For the action, you would still use Email User. However, instead of selecting Assignee from the dropdown, you'd select your name. Hope that helps!
1
Lisa Colpoys
Hi, we would like to not send out emails to customers/requesters when they update their own ticket (e.g., when they email us). I see that there is a tip in the article - Tip: If you want to prevent requesters from receiving emails about their own comments, you can add the following condition: Requester | Is not | (current user).
I also see that @BrandonFischer added a comment to this article that says to add the condition Current User | is not | End user.
Which is correct? Are these effectively the same?
1
Joshua Bentley
Chandra Robrock - Thank you! But wouldn't that send me an email for any ticket that gets a comment update, not just my own?
0
Lou
Joshua Bentley
Can you provide more detail on what you're trying to accomplish?
As far as not notifying you when you update the ticket, add the condition:
Current user>Is not>Joshua Bentley
0
Joshua Bentley
Lou
Thanks for getting back to me. Here's a breakdown of the scenario:
My team does not use the default trigger that notifies the assignee when a customer replies back. We have too many tickets for that to be useful. But since I don't check my views every day, I do want to receive notice.
TL;DR: I want the system to only notify me when a customer replies to my tickets.
Does that make more sense?
0
Lou
Joshua Bentley
Here is my understanding of what you described:
Depending on the channel the customer uses to update the ticket, your conditions would be something like this:
Assignee is Joshua Bentley
then something like the following:
Does that make sense or am I totally missing it?
0
Michae Almeida
I am also curious about Lisa's question provided below.
Also, I noticed that the placeholder was not the simplified version on the "[Notify] requester and CCs of comment update" trigger. Is that correct?
Hi, we would like to not email customers/requesters when they update their own ticket (e.g., when they email us). I see a tip in the article - Tip: If you want to prevent requesters from receiving emails about their comments, you can add the following condition: Requester | Is not | (current user).
I also see that @BrandonFischer added a comment to this article that says to add the condition Current User | is not | End user.
Which is correct? Are these effectively the same?
0
Zsa Trias
Hello Michae,
Which placeholder were you referring to?
For your question about which condition to use, let me differentiate the two:
Which condition to use would depend on your workflow, as to when you want the trigger to run, they're not exactly the same as defined above.
0
Sebastian Bedkowski
Hello everyone,
So what I'm actually trying to do is to auto-assign the ticket, when the agent will reply to it in Zendesk. I don't want to use the "take it" option, as a lot of the agents are forgetting about it.
The default trigger is not doing it for me, as it works for the email notification, and whenever we make the update to the ticket in the ZD, the ticket stays unassigned.
Is there a way to set the trigger to assign the ticket to the agent if they will make any update on it, internal or public?
I have tried everything I think, status change, ticket update, etc, but nothing works.
EDIT:
Found the way if someone will be looking for it, just set it as below:
1
Prathiba Sugumar
Any advice on this pls?
For Notify requester and CCs of comment update, How to personalise the email based on who is CC'd?
Example: If 2 users are CC'd and 1 user has the email domain abc.com, then the email should contain 'additional' information. If they dont have the abc.com domain in their email, the email should not contain the additional information.
0
Zsa Trias
Hello Sai,
Unfortunately, we do not have a trigger condition that is based on the CC'd users.
If you add these users manually on the CC field, you can probably also add a tag depending on the user you added as CC. Based on this tag, you can use this as a condition as to which trigger would run.
0
vincent solitario
Hi,
I hope you can help me with this for trigger/automation
What I'm trying to achieve is to notify our customer after our office hour.
Example:
Our customer support for email is available only from 8am - 6pm.
Customer emailed us from 06:01 pm to 07:59 am.
In that time frame, we will send an automatic message to the customer that our email support is available only from 08:00am to 06:00pm.
Thank you.
1
Paolo
This article might be helpful for your use case: Modifying a notification trigger to return a response based on business hours.
Best,
Paolo | Technical Support Engineer | Zendesk
1
Rich Lorenzo
A previous version of this article was better because it included screenshots of the triggers, which showed the subject and body of email notifications.
Is there currently any other place to view the entirety of the default triggers, to see exactly the way they are all set in a brand new Zendesk?
0
Audrey Ann Cipriano
Hi @... thank you for your feedback! I have looked and unfortunately couldn't find any other place to view the entirety of the default triggers as our documentations have all been updated, but if you prefer, I can raise a ticket on your behalf and send it to you via email. Let me know what you think! Thanks :)
1