In the case of CCs, system ticket rules exist to reduce the number of duplicate email notifications sent to users about a single request and ensure that internal notes remain private. For example, if an agent is a recipient on a group notification but also a CC on the ticket, ticket notifications may be suppressed to prevent duplicates. However, these rules may not completely eliminate duplicate emails—users still might get some duplicate emails.
System ticket rules sometimes suppress actions in business rules. They cannot be changed or overridden and dictate the standard behavior of Support (see About system ticket rules). They can sometimes make it seem like entire triggers and automations failed to fire, or that certain actions failed to execute, but this is not a mistake.
This article includes these sections:
- About business rule action suppression
- Criteria for suppressing CCs notifications
- Requester profiles without an email address
- Understanding how automations affect comment privacy
- Understanding the effects of “Make email comments from CCed end users public”
- Understanding how the Events log is affected by business rule action suppression
Related article:
About business rule action suppression
The Email user + (requester and CCs) action is different from other actions in triggers and automations—it’s designed to send messages to end users in a way that mimics the behavior of regular email, so that end users don’t feel like they are getting impersonal system notifications.
However, this action is suppressed in certain situations (see Criteria for suppressing CCs notifications). If suppressed, the trigger or automation still fires and other actions in the trigger or automation are still executed. Only the Email user + (requester and CCs) portion of the trigger or automation is suppressed.
Criteria for suppressing CCs notifications
The Email user + (requester and CCs) action is suppressed in the following situations:
- A private comment is added to the ticket. The Email user + (requester and CCs) notification is designed for end users. It is suppressed on private comments, and threads will only include public comments. The trigger or automation still fires, and other actions in the trigger or automation are still executed.
- The requester is suspended, has an invalid email address, or otherwise can't receive email notifications. Without a valid requester, the notification will be suppressed, even if one or more CCs have valid email addresses.
- The ticket is updated (not created) by email, and both of the following are true:
- The author of the email is a requester or CC.
- Everyone who would receive the notification already received the email that updated the ticket.
Requester profiles without an email address
Any user that doesn’t have an email address associated with their user profile will not receive notifications under any circumstances. It would be impossible because Support would not know where to send the message.
If the requester on the ticket doesn’t have an email address, the Email user + (requester and CCs) action on triggers and automations is suppressed, and so no email notification is sent out at all. What this means is that, even if CCs on the ticket have an email address in their user profile, they also don’t get a notification.
Understanding how automations affect comment privacy
When an automation with the Email user action fires on a private ticket, these things happen:
- If the user is an admin, agent, or group, an email notification is sent to them. If the user is an end user, no email notification is sent.
- No comment of any kind (public or private) is added to the ticket.
- An event is recorded in the Events log.
Understanding the effects of “Make email comments from CCed end users public”
The Email user + (requester and CCs) action is suppressed in certain situations depending on whether the Make email comments from CCed end users public option is enabled and other criteria have been met. The following scenarios illustrate when this happens.
Scenario 1
This Email user + (requester and CCs) action is suppressed when Make email comments from CCed end users public is enabled and all of these criteria are met:
- The ticket is being updated (not created) via email.
- The author of the email is a requester or CC.
- Everyone who would receive the notification already received the email that updated the ticket.
Scenario 2
The Email user + (requester and CCs) action is suppressed when Make email comments from CCed end users public is disabled and the ticket is being updated (not created) via email, and either of these criteria are met:
- The author of the email is a requester or CC.
- Everyone who would receive the notification already received the email that updated the ticket.
Understanding how the Events log is affected by business rule action suppression
This section explains how the Events log is affected by business rule action suppression.
If Email user + (requester and CCs) is suppressed and the trigger or automation doesn’t include any other actions, no event is recorded in the Events log, even though the trigger or automation fired. When there are no other actions besides the Email user + (requester and CCs) in the business rule, nothing appears in the Events log about the comment. For example:
![](https://zen-marketing-documentation.s3.amazonaws.com/docs/en/ccs_suppression_no_other_actions.png)
If Email user + (requester and CCs) is suppressed and the trigger or automation includes other actions, the other actions are executed. Then, an event about the other actions is recorded in the Events log. When another action exists in the rule after the notification, such as a tag being added, it executes and and both actions show up in the Events log. For example.
![](https://zen-marketing-documentation.s3.amazonaws.com/docs/en/ccs_suppression_including_other_actions.png)
9 comments
CJ Johnson
What does -- mean in this chart? What are these columns representing? Why do some rows include an outcome and others do not? I feel like a bunch of labels are missing or something. I cannot figure out how to interpret this at all.
Does that first row mean if MECFCEUP (Make Email Comments From CC'd End-Users Public) is enabled, and the requester updates the ticket via an email, a trigger that would send the requester and cc's an email notification (example: "Hi, thanks for replying, our datacenter is being swarmed by bees so our reply times are pretty long right now, hang in there!" and keeps the ticket open) would NOT fire the email notification for the trigger, because "Everyone who would receive the notification already received the email that updated the ticket"?
That's the logical conclusion from this chart, but surely that cannot be right.
0
Sabra
Hey CJ! We are working on updating the layout of this article in order to make the information in the table easier to understand.
If you look at each column individually (aside from the first one), the words in each cell of the column is the same. The column is meant to represent the characteristic of the situation. If the cell has a -- in it, then that characteristic does not apply to that situation.
The idea is that you can use the table to compare different scenarios, but it certainly is not the most intuitive!
If looking at the first row, then the Email user + requester and CCs action in triggers and automation is suppressed when:
So, in the example situation that you provided, you are correct: the email notification would be suppressed. If you would like to see this work differently, I would recommend posting your feedback to our Feedback for Support page for our product managers to review and other community members to see.
0
Rickard Läckgren
Hi.
I've been trying to understand this Suppression rule for days now... my case is that I want to use {{ticket.comments_formatted}} when the endusers sends us an email, his/hers reply that a ticket was created should include what they wrote to us. The placeholder works fine when we use "notify when comment" and "notify when solved", also if we create a ticket manually the placeholder works. But when the enduser sends us an email directly they dont get a copy of what the question was.
We dont have helpcenter active right now, we do have "Anyone can submit a ticket" enabled.
What are we missing? The trigger works, its just the placeholder thats not working.
We've also tried using {{ticket.description}}.
0
Dan Borrego
Thank you for your question!
As what you are describing will involve some further investigation, I will need to take a look at your account.
I am creating a ticket for that, and we will move this conversation there.
Thanks for your understanding,
0
Jürgen Wagenbach
Hi
![](/hc/user_images/Wx3Qvtu_EwbFvX5MqNes1Q.png)
We have added a quite simple trigger that an e-mail is sent to the requester when a new ticket is create, see below:
This trigger works quite well in most cases but very sporadically had not been executed. We tried to figure out the reason for that. It seems to be that the trigger is not processed in case the ticket is created by a mail request and the original mail holds the same "From" (= requester) mail address as present on the mail's "cc:" list too. I guess that this is one of Zendesk system's inborn rules which suppresses trigger's execution.
In fact it might not make much sense if a requester puts his own mail address on the cc: list. It just seems to be a fact that some users like to do so. Perhaps to ensure that the mail had been actually sent out by their mail system. They still expect to get a reply by the Zendesk ticketing tool in addition then which is not a fact in case "from" and "cc:" holds identical mail addresses ;-(.
Can you confirm our observed trigger resp. notification behavior is caused by Zendesk's inborn rules?
Thanks
Juergen
0
Dane
Due to this behavior, I'll create a ticket for you. Please wait for my update via email and let's start from there.
Cheers!
0
eecc
Hi.
I created a trigger with Email user+(requester and CCs) Action.
View ticket event, the trigger has been triggered but not sent to CC email,only to requester.
But there is another event, CC notification,The content is set in the Objects and Rules ’s Settings 、It's not the text content I set in the trigger.
The description in "Criteria for suppressing CC notifications" seems to be similar to my phenomenon, but my comment is public and has not been updated via email. I am not sure why it did not work,The trigger was triggered normally, but it was not sent to CC, only to the requester.
Is this because I didn't click on “Set up CCs and Followers” in the Objects and Rules ’s Settings.
The events related to tickets are as follows
Email notification
requester #32096853909785
Trigger cc-and-requester-public-notification
CC notification
CC user #32096853937945
0
Paolo
There might be a few reasons why this is happening. It is best to get in touch with our Support Team so we can look into this further. Please provide the ticket numbers where you experienced this issue. For additional details, you can refer to this helpful article on Contacting Zendesk Customer Support.
Best,
Paolo | Technical Support Engineer | Zendesk
0
Alan Holmes
This suppression “feature” isn't even known to L1 ZenDesk support. Please create a feature request to fix this this issue.
0