We're on Jira Service Management Cloud, using JETI (Email This Issue) for both outgoing notifications and incoming mail. The goal: when a JSM ticket needs to go to an external support team who works in Zendesk, we send them an email that creates a ticket on their end, and we want their replies (and ours) to keep threading onto the same ticket on both sides — no duplicates, no cross-wiring.
Despite all of that, Zendesk doesn't consistently understand which ticket a reply belongs to:
So the ID is present and correct, but Zendesk seems to be making its own decision about which thread something belongs to, and we can't see why.
Zendesk's side is much less transparent than JSM/JETI — no clear logs or mail-handler visibility to understand what it's actually keying off, or why it "forgets" a thread after using it correctly once.
Open to any idea, even partial or "have you checked X" — happy to share more detail on whatever's useful.
Thanks for reading, Steeve
Hi @Steeve P_ ,
The numeric value #11111 is not a Zendesk email-threading reference. Putting it in the subject or body does not identify the ticket. Zendesk normally uses In-Reply-To/References headers or its encoded ticket token.
First, reply from JETI's Emails tab using Reply or Reply all on the actual Zendesk message instead of sending a new notification from a public JSM comment. Check the raw email received by Zendesk: In-Reply-To should contain a Message-ID already associated with #11111.
This distinction matters because JETI's Cloud documentation states that previous Message-IDs are not copied into the References header on outgoing mail. A public-comment notification can therefore create #22222, and subsequent messages can follow that newer header chain regardless of the number shown in the subject.
If the team must keep using public comments, have the Zendesk admin include [{{ticket.encoded_id}}] in the first outbound notification. Extract and store that value in JSM, then place the same bracketed token in every JETI outbound body. Test this with a fresh ticket pair because the existing chain already contains references to #22222.
If JETI's Reply action still does not preserve the original Message-ID, raise it with the app vendor; subject templating cannot compensate for missing thread headers. Email This Issue app and support
Hi Germán,
Thanks for your fully detailed answer.
It took me a while to reply, as I was testing your suggestions.
The second option worked. In fact, my contact on the other side confirmed that the ID shows up in the very first email they send, confirming they received our message.
I did run into an Email This Issue quirk along the way (it could parse the ID but wasn't writing it back into the issue), but opened an issue to META-INF...we'll see if they got a solution.
I ran a few manual tests, inserting the ID into my custom field directly to check, and everything went through fine.
Thanks again — you definitely saved me hours of searching.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.