How to Link a Jira Service Management Request to the GitHub PR That Fixes It
You can't do it by typing the JSM ticket's own key into the pull request. Atlassian's GitHub integration, the one that populates a Jira issue's Development panel with branches, commits, and PRs, is built and documented entirely around Jira Software issue keys. Atlassian's own setup docs describe referencing a key like JRA-123 in a branch name, a commit message, or a pull request title, and the development-information docs repeat the same requirement. Neither page mentions a Jira Service Management request. A key like SUP-3390 typed into a PR title isn't confirmed to do anything at all.
What actually works is a two-hop chain, and only one of the two hops runs through GitHub. First, the customer-facing request gets linked to a Jira Software issue, the way engineering actually tracks the fix. Second, the branch, commit, and PR reference that Jira Software issue's key, not the request's. The PR shows up on the engineering issue's Development panel, in full, with its open/merged state and everything else that panel tracks. It never touches the request the customer can see. Getting from "the PR merged" to "the requester found out" is a separate step, one that has to be built on top of this, not assumed to come free with it.
One PR, one fixWhy the request's own key doesn't work
Jira Service Management requests use the same PROJECT-123 key format as every other Jira issue, which is exactly what makes this mistake easy to make. A support engineer who's watched a Jira Software ticket's Development panel fill in automatically has every reason to expect the same thing from a request key that looks identical.
The smart commits feature, which is the older half of this same connective tissue, settles the question more directly. Atlassian's smart commits documentation describes commands that "transition work items to any status defined in the software space workflow," and frames the whole feature in terms of Jira Software issues from top to bottom. The GitHub for Jira listing on the Atlassian Marketplace names Jira Cloud, Compass, and Rovo as what it connects to. Jira Service Management doesn't appear in either place. That's not proof the mechanism is blocked outright, since Atlassian doesn't say that either, but it's reason enough not to build a support process on a request-key reference nobody at Atlassian has committed to supporting.
The link that does the actual work
The connection that's documented and reliable is a plain Jira issue link, the same feature covered in Atlassian's linking issues documentation. Pick a link type such as relates to, connect the request to a Jira Software issue in a different project, and that's the whole mechanism. That page is also direct about what linking doesn't do: it lists the available link types and confirms issues across different projects can be connected, but nowhere does it describe linking as syncing status. Two linked issues sit next to each other in each other's issue views. Neither one updates the other automatically. A separate guide on this site walks through the create-and-link mechanics end to end, including why moving the request into the dev project instead of linking it breaks the customer's portal access: how to convert a Jira Service Management ticket into a development issue without losing the thread.
Put the two pieces together and the path runs like this. Link the request to a Jira Software issue, then reference that Jira Software issue's key, not the request's, in the branch and the PR. The Development panel on the Jira Software issue now shows the real PR state. The request shows a relates to link and nothing about the PR itself.
SUP-3390 sat on "In Progress" for two weeks
Milltide Software sells scheduling and records software to veterinary practices, and Dimitri Kovalenko runs operations at Cascabel Veterinary Partners, one of its customers. In late October he filed SUP-3390 through Milltide's JSM portal:
Dimitri, in the portal: Recurring appointments are duplicating themselves every time a tech edits one, not just creating the edit. We've got four clinics seeing double-booked slots because of this.
Junko Arakawa, who triages Milltide's service desk, reproduced it within the hour and confirmed it as a real defect in the recurrence logic, not a training issue. Rather than moving SUP-3390 anywhere, she created ENG-771 in the engineering project with a description written for engineers, and linked it back to SUP-3390 as relates to. Anwar Siddiqui picked up ENG-771 the next sprint, branched ENG-771-recurrence-duplication-fix, and opened a pull request titled "ENG-771: stop duplicate write on recurring appointment edit." Jira's Development panel on ENG-771 picked it up immediately, first as an open PR, then as merged three days later when Anwar's review went through.
Nobody had wired anything to tell Junko that. Two weeks after filing, with the portal still showing "In Progress," Dimitri emailed asking whether SUP-3390 had fallen through the cracks. Junko checked ENG-771 directly, saw the merged PR, confirmed the fix had shipped in Tuesday's release, and replied to Dimitri from the original ticket. The fix had been done for four days by the time she looked. Nothing about SUP-3390 itself, including the relates to link sitting right there on it, had told her that.
The gap: nothing tells Junko a linked issue moved
Junko's workaround, opening the linked engineering issue by hand whenever a customer chases a request, holds up fine at small scale. Three problems show up as the number of open links grows:
- Nobody looks until asked. A customer has to notice the silence and chase before anyone thinks to check the Development panel on the linked issue.
- The habit doesn't scale with volume. Ten open links means ten Development panels a triager would have to remember to revisit, on no particular schedule.
- One fix can cover more than one request. If a second clinic had also filed a request for the same recurrence bug, nothing about ENG-771's Development panel would have surfaced that a second, unlinked ticket needed the same update.
What Modem changes here
This is the point where checking a Development panel by hand for every open link stops being a system. Modem reads your connected Jira Service Management requests and your connected GitHub repos side by side, and per Modem's own description of the GitHub integration, "when a PR merges, Modem matches it back to the topic and suggests who to follow up with." That match doesn't depend on which key ended up in the PR title or whether an engineer remembered to use the Jira Software issue's key instead of the request's. Every requester attached to the topic, not just whoever happens to be the request's Reporter, gets a drafted follow-up queued for a person to send.
Disclosure: this is our product. The problem it's closing isn't unique to Modem's pitch for it, it's the same one this guide has been describing by hand, a merged PR that nobody propagated back to the person who asked for it. The single-Jira-project version of keeping a customer updated on linked work, including the automation rule that covers it and the one that doesn't, is covered in how to notify a JSM customer when linked engineering work is done.
Below a handful of concurrent linked issues, checking the Development panel by hand when a customer asks costs nothing and works. Revisit it once that check turns into a standing part of someone's week instead of an occasional favor.
Fix the key format before you fix the automation
Write down, in whatever doc your triagers already use, which key format goes where. The request key stays on the request, and the Jira Software issue's key is what goes in the branch name and the PR title. That single distinction is what makes the Development panel populate at all. It won't get the merge back to the requester by itself, but it's the piece that has to be right before anything downstream of it can be.
