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:
- Our automation sends the first mail → creates ticket #11111 on their side.
- They reply → correctly lands back on our JSM ticket. Good.
- 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.
- 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