This app answers a request that has been open on Atlassian's public tracker for years:
JRACLOUD-7266,
"Ability to customise the content of notification emails", with 1,596 votes.
The gap
JRACLOUD-7266, "customise notification content", was opened in 2005 and has 1,596 votes. On the Service Management side JSDCLOUD-4642 has 1,283. Jira's notification scheme decides who gets told and says almost nothing about what they are told, so the moment a requirement names a field you are out of the scheme and into Automation rules that send their own email, bypassing the scheme and multiplying per project.
What it does
Rules match on project, event kind, target status, changed fields, public versus internal comments, and an optional JQL check.
Templates use any field by id or by name, the latest comment, the status transition and recent activity.
Sent via Jira's own notify API, so Jira resolves recipients and delivers only to people who can browse the issue.
Recipients as reporter, assignee, watchers, JSM request participants, named users or groups, with the actor excluded.
HTML escaped by default, with a deliberate raw escape hatch.
Preview a rule against a real issue and send yourself a test before enabling it.
Every send logged with recipients, outcome and the reason a rule was skipped, exportable as CSV.
Rules the notification scheme cannot express: event, project, JQL and recipients, with enabled and disabled state.The template and its preview, rendered against a real issue, with the subject and body you are about to send.The send log: who received what and when, Jira's response, and why a rule was skipped.
Honest about its limits
Jira delivers to recipients who can browse the issue. A rule that names someone without permission is logged as delivered to the rest, not silently expanded.
The app sends through Jira's mailer rather than its own. That is deliberate and means it inherits Jira's sending identity and threading, not that we can change the from address.
The one write path, honestly scoped: The only write is the notify call that asks Jira to send a message about an issue. The app never edits issues.
Security & permissions
Built on Atlassian Forge: the app runs on Atlassian's own serverless platform inside your
tenant and stores its data in Forge storage.
It makes no external network calls. Every scope it requests, and why:
read:jira-work
issues, fields, comments and changelog to render the message
write:jira-work
the notify call that asks Jira to send
storage:app
rules and the send log, entirely in your tenant
The native feature it builds on
Atlassian's own documentation for what Jira does out of the box, so you can see exactly where the gap is:
No. The app runs on Atlassian Forge inside your own tenant with zero external egress,
which makes it eligible for Atlassian's Runs on Atlassian trust marker.
How is it billed?
Through the Atlassian Marketplace, on your existing Atlassian bill, priced per user like
any Cloud app. The listing has a free evaluation and the exact calculator for your tier.
