How to notify a customer when the Jira issue they care about ships

There's no built-in Jira feature for this. Two separate threads on Atlassian's own community forum land on the same answer from different angles. One person asking how to notify a linked issue when the main one resolves got pointed at a paid add-on and custom code. Another asking the same thing a different way got a workable answer, but only by building it themselves with a Jira Automation rule.

That second answer is the right one, and it's free. Jira Automation can watch an issue transition to Resolved or Done and fire an email, but it can't send that email to a customer who filed the original request through Slack, a support ticket, or a sales call, because Jira has no field for that person by default. The fix has two parts: put the requester's contact information somewhere the issue can reference, then build the rule that reads it and sends the message. Reporter and Watchers are the wrong tools for either part. Here's why.

Why Reporter and Watchers don't do this

Both fields look like they should work, and neither does, for the same underlying reason.

Jira's Reporter field holds a reference to one existing Jira user, not a name or an email you type in. If the person who wants to hear about this issue doesn't have a Jira seat, they can't be the reporter, and setting the field to whoever happens to be handling the ticket (a support engineer, an account manager) just means that person gets credit for a request that wasn't theirs. Watchers have the identical constraint: you can only add someone who already has an account with permission to see the project. A customer without a login is invisible to both mechanisms, no matter how badly they want to know the issue moved.

This is the same limitation Jira Service Management customers run into from the other direction. A JSM request can carry request participants, people the requester adds to their own ticket who get emailed on updates and can comment, but that only exists inside a service desk project, and only for people the requester manually invites. If the request arrived as a Slack message that a support engineer manually turned into a plain Jira Software issue, there's no participant list to add anyone to in the first place.

The mechanism: trigger on the transition, not the field

Since there's no field to lean on, the notification has to come from an automation rule that doesn't care about Reporter or Watchers at all. The shape of it:

1. Trigger: "Issue transitioned" (or "Field value changed"), scoped to the status changing to Resolved or Done.
2. Condition: restrict it to issues carrying whatever marks a customer-linked request, a label, a custom field, or a link type to a service desk ticket.
3. Action: Send customized email, Atlassian's current automation action, which explicitly supports sending to "email addresses for recipients internal or external to your organization" rather than only Jira accounts. Point it at wherever you stashed the requester's address (the next section covers where that address actually comes from), or pair it with a "Send web request" action posting back into the originating Slack channel instead of email.

That action only works if something upstream put the requester's contact info somewhere the rule can read it. The realistic options, roughly in order of effort: a plain-text custom field on the issue ("Requester email"), a link to the JSM ticket or Slack thread that started it (with a second automation step that looks up the address there), or, if you're further along, a system that already tracks the person independent of any one Jira field.

The scanner bug Dana reported on a call

The scanners on Colderwell Fulfillment's loading dock keep dropping mid-scan whenever the dock wifi hiccups, and Dana Okafor, who runs warehouse operations there, is the one who ends up filing the complaint each time it happens. Colderwell buys its scanning software from a mid-size barcode-scanning SaaS vendor, and Dana raised this particular round on a scheduled account call, recorded in Gong:

Dana, on the call: Our scanners keep timing out on the loading dock wifi and dropping half-entered shipments. It's happened four times this week. Can you fix the retry behavior so it doesn't just drop the scan?

The solutions engineer on the call opens a Jira Software issue, WMS-2118, in the product's own tracker, sets its priority based on the four-times-this-week detail, and pastes Dana's quote and email into a "Requester" custom field the team added for exactly this. Two weeks later, an engineer closes WMS-2118 as Resolved after shipping a retry fix. An automation rule scoped to that field fires "Send customized email" to the address in it, and Dana gets a note the same afternoon: "The scanner timeout issue you raised on the 14th is fixed as of today's release."

Without the custom field and the rule, WMS-2118 closes the same way most fixed bugs do, quietly, with the four dropped-shipment complaint sitting in a Gong recording nobody thinks to revisit.

Four ways the single-field setup falls short

The Colderwell example works because one field, on one project, covered one request. It stops holding up in a few predictable ways:

• The custom field only gets filled in when someone remembers. A different solutions engineer files the next ticket without it, and that customer never gets notified, not because the rule failed, but because there was nothing for it to read.
• Requests don't all arrive through one channel. Dana's came from Gong; the next one might be a Slack message or an email forwarded into support. Each channel needs its own way of getting a contact address onto the issue, and each one is a separate thing that can be skipped.
• The rule is per project, and Jira projects multiply. A team running notification rules across a dozen Jira projects is maintaining a dozen near-identical automations, each one a place for the "which field" or "which trigger status" convention to drift.
• One issue, several requesters. If three different Colderwell employees asked about the same scanner bug in three different channels, a single "Requester email" field can only hold one of them, and the other two are silently dropped from the notification.

This is the point where teams stop trying to patch Jira Automation further and add a layer that reads requests independent of any one field. That's the category Modem is built for. It watches your connected Jira projects for issues and status changes, and separately reads the Slack channels, support tickets, and call transcripts where requests actually originate, matching different phrasings of the same ask to one topic instead of relying on whoever files the ticket to also fill in a contact field. When the linked issue resolves, every person attached to that topic, however many there are and whatever channel each one used, gets a drafted follow-up queued in the thread they originally asked in, ready to send, instead of a generic Jira notification they'd need an account to see. Sending is still a person's call; matching the resolved issue back to every requester across channels is the part that stops scaling by hand. That's also our product, so read the comparison with that in mind. The general mechanics of closing this loop, independent of which tracker you use, are covered in how to notify the exact customer who asked when their feature ships.

Below the scale where that drift matters, a well-labeled custom field and one automation rule per project genuinely is enough. Below a few dozen customer-linked issues a month, don't add a system to solve a problem a field handles fine.

Fifteen minutes gets you most of the way there

Add a plain-text "Requester email" custom field to your Jira Software project, and one automation rule: issue transitions to Resolved, condition on the field being non-empty, action "Send customized email" to that address. That's a fifteen-minute build, and it will correctly notify every requester whose email made it into the field, which is most of your near-term win. The Reporter field's own limits, and what Jira's audit trail can and can't reconstruct after the fact, are covered separately in how to see who actually asked for a Jira epic or story.