How to Notify a JSM Customer When Linked Engineering Work Is Done
Jira Service Management ships one automation flow for this, and it only covers the case where the engineering work lives in another Jira project on the same site. Reaching a second Jira project means turning that single-project rule into a multi-project or global one, which takes a permission most people building service desk automations don't have. Reaching engineering work tracked in Linear or GitHub instead of Jira means the native rule has nothing to trigger on at all, because it only fires on Jira issue events.
What JSM's own tooling actually covers is narrow: a resolved issue becoming a customer notification, automatically, inside a single project. Everything past that one project, and everything outside Jira entirely, needs either a second rule with elevated scope, a webhook someone builds and maintains, or a layer that watches the engineering tools directly instead of routing through Jira's own trigger set.
The flow JSM gives you by default
Every JSM service space used to ship with a pre-built automation called "Update Jira linked work items" (Atlassian also names it "Update when a linked work item changes" in its own automation recipe documentation). It comments on the customer's request when a linked engineering issue changes status, and Atlassian's own docs say it can be extended to close the request automatically or send the customer a notification when the fix lands.
The catch: that specific flow is legacy. Atlassian's documentation flags it as relevant only to "service spaces created before August 30, 2021." If your JSM project is newer than that, you won't find it, and you build the equivalent yourself with current Jira Automation: trigger on either the JSM request or the engineering issue, then branch into whatever's attached to it (a sub-task, a parent, another linked issue) with the related work items condition Atlassian built for exactly this.
Either version, old or current, does the same job inside one project: watch a status field, act when it changes, write back to the linked ticket. That's a real, working answer for the common case, and it's free.
Where one project stops being enough
The trouble starts the moment "linked engineering work" means more than one Jira project. Atlassian's own automation documentation is direct about this: "In order for a flow to work with a work item in another project, it must be a multi-project or global flow to execute in the projects the work item is in." A rule scoped to your JSM project, watching for a linked issue in a different Jira project, needs to be rebuilt with that wider scope.
Wider scope isn't just a dropdown. Per Atlassian's permissions documentation for automation rules, a project-scoped rule can be built by any admin of that project, but a multi-project or global rule requires the site-wide "Administer Jira" permission. The support lead who owns the JSM project rarely holds that permission, so the fix for "our engineering team splits work across three Jira projects" usually means filing a request with whoever runs Jira admin for the org, not editing a rule yourself.
And if the engineering work isn't in Jira at all, wider rule scope doesn't help, because scope only changes which Jira projects a rule can reach. A team running Linear for its own sprint work, or tracking fixes as GitHub issues, has no Jira event for a JSM automation to watch. Atlassian's fix for exactly this gap is the Incoming Webhook trigger, meant for firing a Jira flow "by sending a web request from another system." It works, but someone has to build the webhook call on the Linear or GitHub side, keep its payload matched to what the Jira flow expects, and maintain it when either side changes its API.
The sync-timeout ticket at Kelter Systems
Micah Sowerby is the platform lead at Kelter Systems, a logistics-scheduling customer of a workforce-management SaaS vendor. Kelter's dispatch board kept losing its overnight sync, so Micah filed a request through the vendor's JSM portal:
Micah, in the portal: The overnight route sync has failed three nights running. Dispatch has to re-pull the board by hand every morning before shift start. Ticket SUP-2118.
The vendor's engineering team doesn't run a Jira Software project. They track their own sprint work in Linear. The support engineer who triaged SUP-2118 opened a Linear issue for the sync job's retry logic and pasted the JSM ticket key, SUP-2118, into the Linear issue's description, because that was the only way to make the two records findable together later. Nothing on either side updates the other automatically; the key is there so a human doing a status check can search for it.
Ten days later, an engineer closes the Linear issue after shipping a fix. Nothing fires. The JSM ticket sits in "Waiting for support" until someone happens to check the Linear board, notices the fix shipped, searches JSM for SUP-2118, and replies to Micah by hand. The automation rule the vendor already has, the modern replacement for "Update Jira linked work items," never had anything to watch, because the resolution event happened in a tool it doesn't read.
Four ways this breaks in practice
- A second Jira project needs a permission the JSM team doesn't have. Multi-project and global automation scope both require site-wide "Administer Jira" rights, so crossing project lines means a ticket to Jira admin, not a rule edit.
- A non-Jira tracker gives the native flow nothing to trigger on. Linear and GitHub issues resolving doesn't fire a Jira automation event, no matter how the rule is scoped.
- The webhook workaround is its own maintenance job. An incoming webhook from Linear or GitHub into Jira Automation works, but someone owns keeping the payload shape, the auth, and the trigger condition correct as both sides change.
- One resolved issue can map to several requesters. Pasting one ticket key into one Linear issue bridges that one JSM ticket. Every other requester who reported the same underlying problem, through a different ticket or a different channel, has no key pasted anywhere and never gets connected to the fix.
Replacing the pasted ticket key
This is the point where teams stop trying to widen one Jira automation rule and instead put something in place that watches the engineering tools directly, independent of which one holds the actual fix. That's the category Modem is built for. It reads your connected Jira Service Management projects for customer requests, and separately watches Linear issues, GitHub pull requests, and any other Jira projects your engineers use, matching the request to whichever one actually carries the fix without a pasted ticket key or a cross-project automation rule doing the connecting. When that linked work resolves, wherever it lives, every requester attached to it gets a drafted follow-up in the channel they originally used, portal, Slack, or email, queued for a person to send. We build Modem, so weigh that against the alternative of asking Jira admin for wider rule scope on its own merits. The single-Jira-project version of this same problem, including the custom field a lot of teams start with, is covered in how to notify a customer when the Jira issue they care about ships.
Below a few dozen customer-linked issues a month, and especially if engineering stays inside one Jira project, none of this is necessary yet. Revisit only when the manual searching in a Linear or GitHub tab starts eating someone's actual week.
Start with the one project you can reach today
If your engineering work is still inside Jira, even a second project, build the branch-on-linked-work-items rule this week and request multi-project scope from whoever administers Jira for your org; that's a same-day fix once the permission lands. If the fix regularly lands in a tool JSM was never going to see, the honest move is deciding now whether a webhook someone maintains is worth it, or whether it's time for something that reads the engineering tools on their own terms. The step before this one, turning a JSM request into a linked engineering issue in the first place without breaking the customer's thread, is covered in how to convert a Jira Service Management ticket into a development issue without losing the thread.
