Question
I have set up a specific email address as a target that receives email notifications when an update is made to a ticket. When the recipient of that target replies to the email notification, a new ticket is created, rather than having their reply threaded to the original ticket. I would expect their reply to be added as an entry to the original ticket that the notification was sent from.
Why do replies to email-target notifications create a new ticket? How can I ensure customer email replies are added to the first ticket instead of creating a new ticket?
Answer
The target notification system is not designed to thread to an existing ticket and it is expected behavior that a new ticket would be created.
To allow this end user's email replies to thread to the original ticket (instead of creating a new ticket), you will want to stop using targets as your notification method. Instead, you should CC the end-user to your ticket so that they receive the CC notification. If they reply to that notification, their reply is added to the ticket as a public comment.
See Configuring CC permissions and notifications for more information on how you can customize your CC notification settings.
Alternate Solution
Ontec has authored a paid app in our Marketplace that allows you to forward entire ticket conversations (including private comments) to any external email. When the recipient replies to the forwarded email, their comment gets threaded to the original ticket as a private comment.
11 Comments
Hello,
I don't agree with this statement:
"The target notification system is not designed to thread to an existing ticket and it is expected behavior that a new ticket would be created".
It creates strong confusion for email receivers - how can they decide if they can replay to received notification w/o creating new ticket?
We are currently adding warning, like 'Please do not replay', but still sometimes this is ignored and we have to struggle with tickets created by accident.
The best would be to have option to configure behavior for email targets. Either general setting for Zendesk instance or individual one for each email target.
Regards,
Piotr Szlazak
Thanks for the feedback, Piotr.
Hi,
I applied small workaround - using appropriate placeholder I'm adding encoded ticket id to the subject of notification pushed using email target:
[{{ticket.encoded_id}}]Please note that square brackets are mandatory.
This way Zendesk will recognize to which ticket, received email should be added.
Regards,
Piotr Szlazak
<Edited by Zendesk to remove an outdated link>
I am surprised at this statement too - "The target notification system is not designed to thread to an existing ticket and it is expected behavior that a new ticket would be created."
As the target notification is added to the existing ticket history, I would absolutely have expected the reply to update the existing ticket rather than creating a new one.
I don't know how feasible adding customers as CCs on their own tickets by automations using targets is, but thankfully a workaround has been found and shared by another customer (to call out, it'd be nice if Zendesk were able to share these tips when answering the question rather than relying on customers finding a way for themselves).
Separately, (I can't seem to access the link Piotr provided above - is this locked? If so, can ZD provide summary of the details/conversation it contained? Thanks!
Hi Kim!
The link Piotr provided was to a 3-year-old Product Feedback thread; that post has since been archived, which is why you're not able to access it. I've gone ahead and removed the link from Piotr's comment.
As far as the information contained in that thread, one of our Product Managers explained that one of the ways we identify incoming tickets is by checking in-reply-to and references headers for our encoded id. If that encoded id is present, the incoming message is added to the corresponding ticket.
Ah thanks for that Jessie
Jessie,
I'd suggest that Piotr's workaround be added to the main Email Target articles that Zendesk has provided, including the one at the top of this page and perhaps this one: https://support.zendesk.com/hc/en-us/articles/203660866-Notifying-External-Email-Addresses
The ability to forward tickets (besides CC) and allow the ticket to be updated via response to that forward seems to be highly desired by Zendesk customers, based on all the similar threads about it.
I had to dig more than necessary to find this solution, but am happy I found it among the comments here.
Hi Dave,
Most likely this hasn't been added to our documentation because this workflow is not supported by us. That being said, I agree we could make this information readily available to users in need of the same functionality. I'll see if I can spin up a Community Tip that includes this workflow and provide a link here to help provide visibility.
Thanks for sharing this with us!
Brett,
That would be awesome and, I think, greatly appreciated by the community.
Thanks for the swift follow up!
We also see this problem with regular triggers (not just targets) configured to send email to "The requester" if that requester replies back from some other email system that formats their emails. (Such as an email management system). We also need a supported way to ensure there's an ID embedded in the body of an email and not the header, in order to link an email reply to an existing ticket, and not create a new one.
So the question is, is this a supported flag to add to a Trigger email body to ensure replies link it to an existing ticket? If not, we need one. More and more systems are being implemented by clients to handle email replies, and these are not going into existing tickets because they're re-writing the headers or modifying the subject line subtly.
[{{ticket.encoded_id}}]
Hi there,
While it's not a supported workflow, I did create a community tip as mentioned above that goes over setting this up: Allow email target responses to thread into existing ticket
Appreciate you taking the time to share this feedback and I'll be sure to pass it along to our product managers.
Cheers!
Please sign in to leave a comment.