When you enable CCs, you are allowing internal user (your agents and admins) and external users (your customers or end users) to copy other users when replying to ticket notifications by email. You are also allowing internal users to copy users from the ticket interface.
When you enable followers, you are allowing internal users to "follow" tickets. This means that the follower receives email notifications about updates to the ticket, but their names and email addresses do not appear in email notifications to other people on the ticket. They remain invisible to external end users.
To use CCs and followers, at a bare minimum, you must select the check boxes that enable CCs and followers. However, after that, it's up to you decide how to customize CCs and followers based on your unique situation. You may need to use all of the options described in this article, or only some.
This article includes these sections:
- Availability of the new CCs and followers experience
- Setting permissions for CCs and followers
- Changing the default comment privacy for end user CCs
- Comments by users not explicitly added to the ticket will be flagged
- Using placeholders with CCs and followers
- Changing the requester
For more information about using CCs and followers, see Using CCs, @mentions, and followers.
For a complete list of documentation about CCs and followers, see CC and followers resources.
Availability of the new CCs and followers experience
The new CCs and followers experience is now available to all customers. However, some accounts have the CCs and followers experience by default and others don’t.
Here's are some important things to know about this situation:
-
Accounts with the CCs and followers experience enabled by default
Accounts created in August 2019 or later, and some accounts created in 2019, have the CCs and followers experience by default. If this applies to your account, you can’t use the old CCs experience, and the options for rolling back CCs and followers don’t appear in your account either. However, you can enable and disable CC and follower settings, if needed.
-
Accounts with the CCs experience enabled by default
All other accounts have the old CCs experience by default. If this applies to your account, you will need to migrate using the Set up CCs and Followers button in Settings > Tickets. If you migrate, but run into problems later on, you can rollback CCs and followers, if needed, and keep using the old CCs experience for now.
Setting permissions for CCs and followers
Keep in mind that once you complete initial setup and configuration from Settings > Tickets, you may not be completely done configuring your account for CCs and followers. You may need to complete some additional tasks to further customize CCs and followers, such as customizing your default email notifications to requesters, CCs, and followers and creating business rules for CCs and followers.
Before you set permissions for CCs and followers, we recommend that you review Getting started with CCs and followers for admins, which includes a complete checklist of all of the tasks you may need to perform in order to customize CCs and followers based on your needs.
To set permissions for CCs and followers
- Click the Admin icon (
) in the sidebar, then select Settings > Tickets.
- In the CCs and followers section, select the Enable followers and Enable CCs check boxes.
- Configure the settings you want to use for CCs and followers and then click Save tab.
Setting | Description |
---|---|
Enable followers |
Allows agents to add followers to tickets from the ticket interface. Adds the Followers field to the ticket interface. |
Follower email subject Follower email template Revert to default |
Type the text that you want to include in the subject line and body of email notifications to followers. Placeholders are allowed (see Using placeholders). You can use Revert to default to replace text in Follower email template (but not in Follower email subject) with default text. All of these option are only available when Enable followers is selected. For more information about the follower email template, see Customizing default email notifications to CCs and followers. |
Enable CCs |
Allows agents and end users to add other users as CCs on tickets. Adds the CC line to the ticket interface. |
CCs and followers blocklist |
You can prevent specific users from becoming CCs and followers by entering their email address or domain name into a blocklist. Use spaces to separate the addresses. This option is only available when Enable CCs is selected. |
Enable light agents to become CCs on tickets |
Enables ticket requesters, agents, and existing CCs to add light agents as either CCs or followers on tickets. When enabled, light agents can be copied on tickets form the ticket interface and from ticket notifications. However, light agents are not allowed to add or remove themselves from the CC list—this must be done by another agent who isn't a light agent. Regardless of whether this setting is enabled or disabled, when followers are enabled, light agents can be added as followers, and they can add or remove followers from tickets. |
Enable CCs for end users on Help Center |
Allows signed-in end users to copy (CC) users in these places:
Note: This feature is not available on trial accounts.
|
Automatically make an agent CC a follower |
When an agent is CCed on a ticket via email or the ticket interface, they are also automatically added as a follower.
Note: If the agent is CCed from a ticket form in your Help Center or via the API instead, then they are not also added as a follower.
|
Changing the default comment privacy for end user CCs
By default, if an end user CC replies to a ticket notification from email using Reply (instead of Reply all), the reply becomes a private comment on the ticket. However, if the Make email comments from CCed end users public (not recommended) option is enabled, the behavior changes and the reply becomes a public comment instead.
We don’t recommend using this option because a requester might see content that wasn’t meant for them. For more information about email replies, see Understanding when email replies become public or private comments.
To change the default comment privacy for end user CCs
- Click the Admin icon (
) in the sidebar, then select Settings > Tickets.
- In the Comments section, select this option:
Make email comments from CCed end users public (not recommended)
Note: This setting is only available if CCs is enabled. - Scroll down and click Save tab.
For information about other ways you can change the default privacy of ticket comments, see Changing the default privacy of ticket comments.
Comments by users not explicitly added to the ticket will be flagged
If an unknown user, who was not added to the ticket by the requester or an agent as a CC, updates an existing ticket, the comment is flagged and added to the comment stream as a private note. Most likely the email was forwarded by the requester to an unknown user or to an unverified email account (such as a secondary email address), and then replied to.
The flag brings attention to the potential risk, without affecting the workflow of your end-users and agents. The flag appears as a warning icon beside the first comment in the ticket. The ticket is not flagged in any ticket views. You can hover over the warning flag to get more information.
To handle a flagged comment
- If you are comfortable with the comment, ignore the warning flag and handle the ticket as you normally would. You cannot remove the flag.
- If you want to allow the new user to comment publicly on the ticket, an agent, the requester, or a CC on the ticket needs to add them as a CC.
- If you are not comfortable with the comment, you can raise a concern with your manager or consider temporarily suspending the user.
Depending on the nature of the comment, you might want to raise a concern about the ticket with your manager. Also, you can consider temporarily suspending the user, to prevent them from submitting more tickets, until you can investigate and feel comfortable enough to reinstate the user (see Suspending a user).
Using placeholders with CCs and followers
If you want to list the names and email addresses of CCs and followers in ticket notifications, you can do so by adding these placeholders to your business rules (triggers, automations, and macros):
- ticket.cc_names—Returns the name of CCs on the ticket.
- ticket.follower_names—Returns the name of followers on the ticket.
- email_cc_names—Returns the names of CCs on the ticket.
If you are using the new CCs and follower experience and you are adding or updating your placeholders, we recommend using the email_cc_names
placeholder instead of tickets.cc_names
. They do the same thing, but email_cc_names
is newer.
For more information about CC and follower placeholders and where exactly you can use them, see Creating business rules for CCs and followers and Customizing default email notifications to CCs and followers.
Changing the requester
If allowed by the administrator, agents can change the requester on a ticket. Otherwise, they cannot.
To allow agents to change the requester
- Click the admin icon (
) and then navigate to Settings > Tickets.
- Scroll down the Requester section.
- Select the Agents can change requester check box.
Note: This option only appears if you are using the new CCs and followers experience. If you aren't using the new experience, select the Tickets > CCs > Enable CCs on tickets setting instead.
- Scroll down and click Save tab.
89 Comments
Hi Charles Nadeau,
How do I disable the email notification for 'You are registered as a CC on this request ({{ticket.id}}). Reply to this email to add a comment to the request.'
I will want my users to continue receiving updates from the tickets, but not everyone knows that we are using Zendesk to manage our tickets. These updates somehow confuses them what to do with them.
Edwin
Hey Edwin,
You should be able to edit what shows up in this email by doing the following:
Let me know if you run into any issues :)
Hi Brett,
The default text is always shown. I tried deleting every text and it keeps coming back after I click on Save Tab.
Hey Edwin,
The default text keeps getting re-added to the field I mentioned previously? Any chance you could provide me with a screenshot of what you see on your end when navigating to that page?
Thanks!
This new functionality disables reply-all when the CC is a Distribution List (team email address), and thus prevents effective communication using team addresses.
E.g. I'd CC a team email address for a "side escalation"; one of the team members responds - the comment is flagged - the team and other non-agent CCs misses out on the response as private comments aren't visible to end users.
How do we handle this?
Hi Alex,
We do not support the use of aliases, distribution lists, or Google groups at this time. It may be worth looking into the Side Conversations feature which is part of the Collaboration add-on we have available.
Side conversations are spaces in a ticket where agents can have a side conversation with a specific group of people, or discuss a specific area of concern or course of action.
Hope this points you in the right direction!
> We do not support the use of ... distribution lists ... at this time.
Even though distribution lists are an integral part of email as a communications mechanism - which Zendesk does support, I hope?
Bottom line: this update / change of functionality broke our Zendesk, and no, "Side Conversations" don't fix it. What is the justification for breaking existing functionality that we (used to) rely on?
Hello Alex, having never really played with distribution lists, I'm not fully sure if the flow your method achieved.
It sounds like you may be having problems with the flagging of non-directly cc'ed messages, which was not part of the recent update but one many months ago. This was a security release to prevent unauthorised emails from being able to insert public info into a ticket or other object. This I believe was originally identified as a security risk for other products in the Zendesk family.
On other issues, there are various ways to handle notifications to individuals and groups and it is possible that a suitable solution may be found for the other issues you are facing, however replies from email addresses that are not in the Cc list will be flagged. The only way around that is to add all the emails to the cc field.
Alternatively, since the message is at least present, and presumably you will see this update as the agent, the way we have handled this issue is to copy the message and paste it as a comment quoting them yourself.
If the people in this distribution list were agents, would that work? I have tested that. Create and trigger to notify an agent group and if they reply, does this get flagged?
The workflow that I think you are using could be considered using these other people as support agents, especially if they could publicly reply to customers. This could be used to bypass agent licenses. If you are just notifying them, this can be done with a target, you could invite anyone to email you directly if they are offering you advise etc, or of course reply to add a private comment to the request.
Someone who is directly communicating with the end user and representing your business should really be an agent.
Would be good to understand more how this is used.
@Andrew thanks for jumping in and sharing how you addressed this limitation :)
@Alex as Andrew mentioned, this has been address months ago to address a security issue. The vulnerability would allow an unauthorized person to add themselves to a ticket via email by leveraging an ID known only to ticket participants. This vulnerability did not affect the security of information stored on the Zendesk platform. However, it could have potentially allowed access to external, non-Zendesk services that do not vet specific email addresses, but instead only check the domain name when a user is added.
I realize that this may be an inconvenience for certain workflows but in some cases security becomes a balance against ease of use.
Andrew: sending an email to a team and flagging (preventing from posting) a response from a team member breaks things for us. It doesn't matter whether you think they should be agents: it broke our Zendesk and generally broke an established communication and escalation mechanism in use in the enterprise.
CC-ing 40 people is not an option. Making them all agents is unnecessary and not an option. When one of the team member responds to the ticket but their response doesn't go back to the team (because it got flagged) or because it requires an agent to copy-paste their comment as a public one - this breaks an established communication and escalation mechanism that is in wide use in the enterprise: communicating to teams via their team addresses rather than individual members' ones. Other team members will not know someone responded (unless there's an agent copy-pasting things) and will wonder why and will try responding on their own resulting in confusion, and potentially worse.
Brett: thanks. JIRA doesn't do this, and neither does ServiceNow, to my knowledge. I get it that you needed to patch a vulnerability - all I am saying is that it broke certain parts of Zendesk (and generally, accepted email) behavior that are important to us, all without an apparent option to negate the damage - e.g. by whitelisting a domain or two as an exclusion to the rule, or disabling the rule altogether for our instance.
The vulnerability doesn't apply to our instance as it's not public-facing and generally only for internal users - so the change in behavior is a bit hard to stomach.
Thanks again for chiming in.
@Alex, totally understand where you're coming from! I'm going to bring this into a private ticket to discuss further and see if we can come up with some sort of alternative. You'll receive a follow-up email shortly :)
Hi Brett
I just wanted to add a comment to the recent discussions above, as we also communicate with external business partners via distribution lists. I've raised this an a few different forums.
The individuals in the Dist Lists we have are intended to be set up as Light Agents, but they do not log into Zendesk. If an individual replies by email, recipients on the email (dist list, or as individuals) will receive the comms via email rather than ticket, which is fine. But our issue is when we reply back, it is via internal comment, and if that person is not a light agent, then they will not receive the reply.
We used to be able to recognise if someone was not an agent, as the reply used to be in white public comment. Now as all comments are yellow internal comments, there is no way to easily identify user type unless checking user profile.
With no ability to CC groups from Zendesk, we need to use DLs to ensure comms reach the correct audience. As the distribution lists are created by external parties, they can change members without our knowledge. There has to be a better way to identify users when adding CCs.
Mel
Thanks for sharing Melissa!
I'll pass this feedback along to the appropriate team as you and Alex have provided some great use-cases. I would also recommend cross-posting this in our Support Product Feedback forum to help provide visibility to both our Product Managers as well as other users running into similar roadblocks.
I wish I was able to provide you with an easier alternative at this time but unfortunately I've not been able to find anything on my end to address this :-/
We greatly appreciate you taking the time to share this with us so thank you again!
Is this still being rolled out? We are yet to see this option in our admin area. Thanks
Hi Darren,
Yes this feature is still being rolled out which is why this may not show up on your account yet.
Appreciate your patience and hang in there just a little bit longer :)
Hi there
So we've just had this featured added, however it doesn't appear to work. When I add a CC, they never receive the email.
Does the CC have to be registered as an end user on Zendesk just to receive the email? If so, this means we have to create user each time before we can CC them in. Also if we have to create the user, they also receive an additional email asking them to create a password for a Zendesk account, which knowing our users will not want to do.
Hey Darren,
Have you had a chance to check the Ticket Events to see if the notification was sent out from Zendesk Support?
As for registering the user first, do you have enable anyone to submit tickets toggled on under Admin>Settings>Customers? If this is disabled, then yes the user would need to be added to your account before you can CC them.
Keep me posted!
Hi ,
how can i activate the cc field in the request form? I have checked and enable the cc email fields, but still unable to see it in my request form
Thanks
Hi Brett
I've checked the ticket events and cannot see anything has been sent out. When I go back into the ticket the CC email is no longer there.
I've also checked the Admin>Settings>Customers and can confirm "enable anyone to submit tickets" is enabled.
According to this page https://support.zendesk.com/hc/en-us/articles/203690846-Using-CCs-followers-and-mentions "You can only copy (CC) users that have a user profile in your Support account."
Thanks
When should I expect this to roll out to my instance?
@Ivy, there should be an Enable CCs for end users on Help Center option under Admin>Settings>Tickets. You'll want to make sure this is enabled and that you don't have Only agents can add CC's enabled. I did some testing in my own account and this appears to be working properly. If you're still unable to see this option then I would double check that your Help Center is customized to hide this field.
@Darren, thanks for sharing that! I didn't realize this functionality changed with the new feature. If you're part of the new CC and Follower experience then your end-user would need to first be added to your Support account as a user before they can be CC'd.
@Brad, no exact date of when this will be pushed out to your account but keep your eyes open as it should be fairly soon!
Is this section "CCs and followers" only available after you run the conversion process?
When I add agents as followers, I can see in the Events view that the follower email notification is sent. However, if I add myself (an administrator) as a follower on a ticket, the follower email notification for a public reply or an internal note is not sent. I have read and re-read the configuration steps above but I do not know how to set-up myself to follow a ticket (I am listed as a follower).
Also, the CC: end user that I added as an admin did not receive any Public Replies before the email was set-up as an end user. After I set-up the end user in Zendesk, the end user in the CC: field was notified. The Notify Requester trigger is set to (requester and CC's). The Anybody can submit tickets feature is enabled. Do we have to set-up an end user to be cc'd on a ticket?
According to the article: https://support.zendesk.com/hc/en-us/articles/203662036-Understanding-and-setting-light-agent-permissions-Collaboration-Add-on-
it says light agents can't CC agents or end users other than themselves, except for when they create a ticket. But now with followers features, it seems like they can't cc anyone, even on creation... will this change?
Is there a plan to forcibly withdraw the old cc functionality?
We've tried the new functionality out in our sandbox and have identified a couple of things that mean we don't want to change at the moment.
- CCs aren't available on internal notes, which means we still have to add and remove followers repeatedly if we don't want them to receive every update from the customer (or use side conversations).
- If a Light Agent is cc'd into a comment they only see the public replies and not any internal notes they'd see as a follower
- If either a cc'd Light Agent or the customer hit reply instead of reply all to a comment from the other then that will cut Zendesk out of the loop.
These aren't insurmountable problems but at the moment the effort involved in transitioning isn't worth making the limited benefits.
Hello Adam, it's a configuration option under settings -- users I think.
Check through there anyway. :)
Out of nowhere, our template to alert agents that they have been CC'd or added as a follower is not including the automated message or the ticket number. Only the contents of the email.
It used to say something like this:
"You are a follower on this request (#9710). Reply to this email to add an internal note to the request." and then the contents of the email. The automated portion is gone and I have no idea why. Anyone else seeing this?
I am considering moving to CC and followers but is seems like once you move over, you can't go back. Is that true?
Also, are Light Agents able to add Followers to the ticket?
Hi Katie,
You will have the option of rolling back the CC and Followers change if you wish to do so. More information in the following article: Rolling back CCs and followers
Additionally, light-agents should be able to add and remove followers from tickets.
Let us know if you have any other questions!
Hello,
I've the same issue to remove CCs notification.
How Can I disable CCs Notification? I don't want that they receive the first notification
Please sign in to leave a comment.