CC Functionality & Notifications
RespondidaIf a client emails in a support ticket and CCs an agent, if that agent is also assigned to that ticket, they do not receive the assignee notification (which is critical because it links to the ticket in Zendesk). Would it be possible to reverse this behavior? To not email the CC notification so that the assignee notification can go out per normal? Or would it be possible to add CCs to the conditions so we have more flexibility for pursuing the desired behavior? Something like sending out the CC notification only if the CC does not equal agent.
Thanks!
-
Hi Justin!
What you have observed is expected behavior. When the ticket assignee was also CC'd on the ticket reply, the trigger Notify assignee of comment update will no longer fire on the ticket. This is due to the suppression rule set to prevent the scenario where a user receives multiple emails for the same update. You can read more on this in the article Why didn't a trigger fire for the CCd user?
-
Hi, Joyce,
This is a slightly different scenario. If the client emails in a support ticket and in the primary email (not a reply) they also CC me, I only get the direct email from them and a notification from Zendesk that a ticket has been made on my behalf (which is unnecessary for CCs anyways). What I'd prefer is that the assignment notification "Notify assignee of assignment" is the notification I receive instead, because it contains important information including a direct link to the ticket. I think it would be relatively easy to fix this with a CC is/is not an agent condition. However, I'm changing our "Notify requester and CCs of received request" notification to just "Notify requester of received request" in the hopes that will fix the suppression rule.
-
Hi Justin,
I created test tickets to replicate the behavior of the trigger notification suppression rule.
When a ticket is created and the ticket assignee is CC'd on it, the trigger "Notify assignee of assignment" is automatically suppressed. This is because the ticket assignee already received the message in their inbox from the recent email therefore the email notification action on the said trigger will no longer work.
Only the trigger "Notify requester and CCs of received request" is exempted from the email notification suppression rule. This is due to Zendesk has an inborn system rule that suppresses comment data placeholders in this trigger. Because of the placeholder suppression, users are automatically prevented to receive multiple emails from the same update. See more about this here: Understanding placeholder suppression rules
I'm afraid that changing the "Notify requester and CCs of received request" notification to just "Notify requester of received request" will not bypass the trigger notification suppression rule. At this point, the agent will have to check their assigned tickets to view the important details on them.
-
I fully understand. I was asked to put something here as a feature request, but perhaps I put it in the wrong place.
-
Hi Justin,
You have posted in the correct place and conversations with a high level of engagement ultimately get flagged for product managers to review when they go through roadmap planning.
-
I also struggle with this problem. Users CC me when they create a ticket. Our notification is to the group, of which I am a member. Your suppression rule prevents me from getting the new ticket notification from Zendesk. This is a problem because I cannot respond via email to update the ticket. I have to go into the Zendesk portal to make an update. In my role I much prefer to respond by email.
There really should be a way to turn this off if we want it and are OK with receiving duplicate emails. In fact, since you already know that the CC'd person is a member of the group and you're going to the trouble of suppressing emails, why not just strip that person out of the CC? Although we try to educate the users not to CC us on tickets, it's not really their fault. The ticket system should be smart enough to clean this up automatically.
Por favor, entrar para comentar.
6 Comentários