Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

JSM ↔ Zendesk email threading via JETI

Steeve P_
Contributor
July 16, 2026

Context

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.

What's in place and working

  • A manually-triggered JSM automation sends the first email based on a template. Works fine — creates a ticket on their Zendesk side.
  • JETI's Incoming Mail handler is active and processing replies (a few permission/display quirks along the way, but mail is getting through).
  • A custom field in JSM stores their Zendesk ticket ID, extracted by JETI via regex from the incoming mail and written back automatically — this works when JETI doesn't hit a permissions issue.
  • Our reply templates include that Zendesk ID in the subject once it's known (also tried putting it in the body). Also works, technically.

The problem

Despite all of that, Zendesk doesn't consistently understand which ticket a reply belongs to:

  1. Our automation sends the first mail → creates ticket #11111 on their side.
  2. They reply → correctly lands back on our JSM ticket. Good.
  3. We add a public comment on the JSM ticket → mail goes out fine, Zendesk ID included in the subject → but Zendesk treats it as a new request and creates ticket #22222.
  4. We reply again → this time Zendesk links it to #22222, even though the reference in the subject (and tested in the body too) still points to #11111.

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.

Where we're stuck

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.

Looking for

  • Has anyone run into this pattern before (JETI or otherwise) with Zendesk on the receiving end?
  • Any known Zendesk mail-threading behavior we might be missing?
  • Possibly a simpler way to handle this whole exchange — it needs to stay simple, since a support team (not Jira admins) uses it day to day.

Open to any idea, even partial or "have you checked X" — happy to share more detail on whatever's useful.

Thanks for reading, Steeve

1 answer

1 accepted

1 vote
Answer accepted
Germán Morales
Community Champion
July 17, 2026

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

Steeve P_
Contributor
July 17, 2026

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.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
TAGS
AUG Leaders

Atlassian Community Events