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.

Four ways the single-field setup falls short

One custom field, on one project, covers one request at a time. It stops holding up in a few predictable ways:

• The custom field only gets filled in when someone remembers. The next ticket gets filed without it, and that customer never hears back, not because the rule failed, but because there was nothing for it to read.
• Requests don't all arrive through one channel. One lands as a line in a call transcript, the next as a Slack message, the next as 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 people at the same account raise one bug through three different channels, a single "Requester email" field holds one of them, and the other two are silently dropped from the notification.

Instead of patching Jira Automation further, teams add a layer that reads requests independent of any one field. Modem covers that category. 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. Once the linked issue resolves, you can ask the agent for the people attached to that topic, however many there are, and it drafts a follow-up for each, in the original thread where Modem can write to it (Slack, Discord, Intercom, Pylon, or Plain), instead of a generic Jira notification they'd need an account to see. Approving and 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.