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.
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
Widening one Jira automation rule stops being the answer here; what teams put in place instead watches the engineering tools directly, independent of which one holds the actual fix. Doing that across trackers is what Modem is 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, you can ask the agent to draft a follow-up for every requester attached to it, for a person to approve and send. Modem can send replies itself only in Slack, Discord, Intercom, Pylon, and Plain, so portal and email replies go out from your team. Modem is what we sell, and it does nothing you cannot do by hand at low volume. 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 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.