How to Merge Duplicate JSM Tickets from the Same Customer
You can't merge them, not in the sense of combining two Jira Service Management tickets into one. What you can do, and what Atlassian itself recommends, is link the newer ticket to the original and mark it as a duplicate, then close the newer one and keep working the original. It's a two-click habit rather than a real merge, and it has a real gap. Once the duplicate is closed, a customer who replies to it by email lands a new comment on a dead ticket instead of the live one.
That gap is the whole problem with resubmission. A customer who files "the sync job failed again" on Monday and "why did my overnight import break" on Thursday isn't being difficult, they're describing the same incident in two different moments and don't know it's already a ticket. JSM has no field that says "this is the third time someone's asked about this," so the burden of noticing falls on whoever happens to read both tickets.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThe two-click habit that Atlassian recommends
Open the newer ticket, go to its link menu, and choose "duplicates" pointed at the older ticket, or "is duplicated by" from the older one pointed at the newer. Atlassian's own support staff have confirmed there's no merge function in JSM: "You can't merge tickets. However you can link both issues and mark one as a duplicate of the other," as one team member put it in a community thread on exactly this scenario. Close the duplicate with a comment noting which ticket is now canonical, and add a line to the original noting that a second report came in, so severity isn't lost along with the extra ticket.
Do this every time, not just when it's convenient. The habit only holds if a duplicate never sits open and unlinked long enough for someone else to start working it independently.
Where the linking habit fractures
The failure mode shows up specifically with email-based customers, and the same community thread names it. Once you close a ticket as a duplicate, a customer who replies to that ticket's confirmation email sends their reply into the closed ticket, not the one you actually want them talking to. The thread forks right where you tried to unify it. Portal-only customers seem to hit this less, since they tend to open the original ticket to check status, but anyone working from their inbox will keep replying to whichever ticket they last saw.
The other limit sits upstream of linking. You have to notice the duplicate exists before you can link it. On one Atlassian community thread describing this exact scenario, a JSM admin named Christina Monti described a customer who filed "Need desperate Help" one week and "X isn't working" the next, both about the same outage, with nothing connecting the two beyond the reporter's name. Mikael Sandberg replied pointing her to JSM's built-in similar-requests tool: "There is a feature in JSM that can find similar requests that you could use for this." He added that it's "a manual process currently," something a teammate has to go check rather than something that surfaces on its own. Christina wrote back that the tool "is only looking for similar messaging within the Summary of a ticket," not the full description, per Atlassian's own similar-requests documentation. If the second ticket is titled differently enough, similar requests won't surface it, and a resubmission reworded to sound more urgent is exactly the kind of title change that breaks the match.
When Selin caught the third rewording
At Ashcombe Systems, a fleet-maintenance platform for mid-size delivery operators, support tickets all land in Selin Oakes's queue first. Marcus Feldman, an ops manager at Dunmore Retail Group, filed his first ticket on a Tuesday:
Marcus Feldman: Our vehicle inspection sync stopped updating overnight. Ran fine for months, now the dashboard just shows yesterday's numbers.
Selin worked it, asked for logs, didn't hear back for four days, and the ticket sat in a waiting state. On Saturday, a second ticket arrived:
Marcus Feldman: Inspection data is stale again this morning. This is the second time this week and it's affecting our dispatch decisions.
Different title, more urgency, same underlying sync job. JSM's similar-requests panel didn't flag it, since "stopped updating" and "stale again" don't share enough summary text. Selin only caught it because she recognized Marcus's name in the queue and pulled up his ticket history before replying. She linked the new ticket to the first as a duplicate, added a comment on the original noting "second report from Marcus at Dunmore, escalating," and closed the newer one with a pointer back. A week later a third ticket appeared, again reworded, again from Marcus, and this time a colleague on Selin's team caught it only because Selin had left a note on Marcus's account asking the team to check his ticket history first.
That third catch took a manual note in the margins, on top of the manual link and the manual close. Nothing about the system did it automatically.
Where this stops being a habit you can keep up
The link-and-mark-duplicate workflow holds up fine at low volume, one or two repeat reporters a month, where a teammate can plausibly remember a name and go check. It stops working on three counts as ticket volume grows. Nobody remembers every reporter's history, the similar-requests match on summary text misses anything reworded with intent, and the moment a customer also emails, Slacks a shared channel, or mentions the same issue on a call, JSM has no visibility into any of it, so the duplicate isn't even inside the system you're checking.
This is where JSM's own tools run out of runway: nothing in the product tracks a customer across a ticket, an email thread, and a Slack message at once. Modem exists for that gap. It reads JSM requests, replies, and internal notes the same way it reads Slack messages, emails, and call transcripts, and treats "the sync job failed" and "inspection data is stale again" from the same customer as the same underlying topic even when the wording, the channel, and the day are all different. The duplicate gets folded into one counted topic with both quotes attached, rather than requiring someone to remember Marcus's name. Details on the JSM side of that connection are on the Jira Service Management integration page. We build Modem, so weigh the recommendation with that in mind; below the volume where cross-channel resubmission gets common, the linking habit above is the right amount of process.
If your JSM tickets also need to become separate development issues without breaking the customer's thread, that's a related but different problem, covered in how to convert a JSM ticket into a development issue without losing the thread. And if the question isn't "is this a duplicate" but "how many customers hit this bug," see how to see which customers are affected by a Jira bug, which is the counting problem sitting right next to this one.
The one search habit that closes most of the gap
Write a one-line rule on your team's triage doc. Before replying to any new ticket, search the reporter's name or email across open and recently closed tickets. When you find a match, link it as a duplicate, close the newer one, and leave a comment on the original noting the repeat. That single search habit catches most of what Selin caught by memory, without asking anyone to remember a name.
