There are a few rules that determine whether a reply to a notification sent from email becomes a public comment or a private comment.
A private comment appears in the agent interface as an internal note. Private comments and internal notes are the same thing. This article uses the term private comment to describe these types of comments.
This article includes these sections:
- Checklist: How Support determines comments privacy for inbound emails
- Using "Reply" instead of "Reply all"
- Third party replies to ticket notifications
- Using the Mail API
For more information about using CCs and followers with email clients, see Best practices for using email clients with CCs and followers.
For a complete list of documentation about CCs and followers, see CCs and followers resources.
Checklist: How Support determines comments privacy for inbound emails
Support performs a series of checks to determine comment privacy for inbound emails. These are the checks and the order in which they are performed:
- If the ticket is being updated (rather than created) and the ticket was
identified from the encoded ID in the email, and the author cannot edit the ticket:
- If the author is an agent and is not an assignee, follower, or CC on the ticket, the comment will be private.
- If the author is an end user and is not the requester or a CC on the ticket, the comment will be private.
- If the ticket is being updated (rather than created) and the ticket was not
identified from the encoded ID in the email, and the author cannot edit the ticket:
- The new comment will be suspended (and if/when recovered, it will follow similar rules outlined here from the top).
- If the author is a CC, and the requester was not a direct recipient of the
email:
- If Make email comments from CCed end users public is disabled, the comment will be private.
- If Make email comments from CCed end users public is enabled, but there were recipients other than a support address of the account, the comment will be private.
- If the author is an end user, the comment will be public.
- If the author has a role that can't comment publicly, the comment will be private. (On Enterprise plans, the agent as requester settings override comment restriction permissions.)
- If the Mail API was used with the #note command (for internal note), the comment will be private.
- If Agent comments via email are public by default is disabled, the comment will be private.
- If the ticket being updated is private, the comment will be private.
- If Support determines that the email contains content that was previously part of private comments, the comment will be private.
- If none of the criteria above is met, the comment will be public.
Using "Reply" instead of "Reply all"
When someone replies to a ticket notification from their email client using Reply (instead of Reply all), the reply becomes a private comment (internal note) on the ticket.
For example:
-
By default, when an end user CC replies to a ticket notification using Reply (instead of Reply all), the reply becomes a private comment on the ticket because the requester is not on the reply. CCs are not removed from the ticket. However, if the Make email comments from CCed end users public setting is enabled, the behavior changes and the reply becomes a public comment instead.
-
Follower replies are meant to be seen by agents only and result in an internal comment, regardless of whether Reply or Reply all is used.
-
Assignee replies follow the rules for agents (and the Agent comments via email are public by default setting) that were mentioned earlier in this article, regardless of whether Reply or Reply all is used.
Third party replies to ticket notifications
In some rare cases, your end users may forward ticket notifications to a third party. A third party is someone who isn't the requester or a CC, assignee, or follower on the ticket. This scenario is not common.
If a third party replies to a ticket notification from an email client, these things happen:
-
A warning like the following appears in the ticket interface (click the icon to expand the menu and see the message):
-
The reply becomes a private comment (internal note) on the ticket.
-
The third party is not automatically added to the ticket as a CC.
As a result, agents may need to do these things:
-
If the reply needs to be a public comment, then the agent must manually copy/paste the text into a public comment on their behalf.
-
If future replies from this person need to be public comments, then the agent needs to add them as a CC from the ticket interface.
Using the Mail API
You can also use Mail API commands to make a reply into a public or private comment. By
default the value of the #public
Mail API command is true
,
so the reply will be public. A #public false
command will make the reply
private. Also, you can use the #note
syntax to make a reply into a private
comment. See Using the Mail API to update ticket properties from your
inbox.
38 comments
Paolo
The only way for an inbound email to be set in public is for the end user to be the requester or be added as a CC in the email. Otherwise, the comment will be private.
Best,
Paolo | Technical Support Engineer | Zendesk
0
Max Mittelmaier
Hello, I have following use case:
We're dealing with an organization and send all of our pro-active ticket requests to one address (which on their end is a distribution list to various of their internal people) e.g. "support@thirdparty.com". Whoever picks up our request on their end would then reply with their personal email address "john@thirdparty.com"). This causes that these replies are flagged as Third party replies to our ticket. As these requests go back-and-forth all of their replies get lost in the email thread. This is highly confusing.
There is also no option for us to add all of their people to CC via a trigger. So I'm at a loss to how to deal with this? It's not an option to manually always copy various of their people to CC after the fact.
0
Joyce
With your use case, it is really necessary for your agents to manually add the responder as CC in the ticket for the succeeding responses to appear as a public comment. Zendesk does not have a way to identify the individuals that are part of a distribution list, as those are configured outside our system, therefore responses coming from email addresses that are not explicitly part of the ticket are expected to show as a private comment.
0
Jimmy Rufo
Can someone clarify if a light agent replies all to an ticket email notification, and includes an external requester on the TO/CC line, why Zendesk still marks this as internal note? Is there an enhancement that can signify "Internal to those viewing in the ticket system, but external email was sent". As of right now, others in the ticket chain are confused that responses that were seen externally, only went out internally, which obviously would not be the case in this scenario.
0
JR Lausin
All ticket comments by light agents are private, including the first comment of any tickets they create. So when they reply to an email notification the system will detect them as a light agent and mark this comment as an internal note.
I don't see any update on changing this behavior but please feel free to submit a product feedback on this General Product Feedback topic
Sincerely,
0
Jimmy Rufo
Noted JR Lausin. My comment was more for an indicator to let people know in the UI that the internal note was left via an email reply. Today, I have to look at "View Original Email" to confirm who was sent this email, as it obviously went to more people than whoever is just internally collaborating on the ticket. I can enter product feedback, but I thought I had done so in the past.
0
JR Lausin
I tried to look for the feedback you posted before but I can't seem to find it did you get an update or an email from our dev team regarding this? If not I recommend posting this as a new feedback as I'm pretty sure this will be beneficial to Zendesk users.
Sincerely,
0
Jimmy Rufo
JR Lausin , Done! https://support.zendesk.com/hc/en-us/community/posts/6624825771802-When-Light-Agents-reply-to-a-ticket-email-notification-UI-doesn-t-reflect-if-client-was-contacted
0