JRACLOUD-7266 asks to customise the content of Jira notification emails. Opened in 2005, 1,596 votes, still open. On the Service Management side, JSDCLOUD-4642 has 1,283 votes and JSDCLOUD-2044 has 739, asking for the same thing in different words.
What people want is modest. A notification that says which customer tier the ticket belongs to. A status-change email that includes the comment that came with the transition. An alert that names the field that changed and what it changed from. Jira's notification scheme decides who gets told. It has almost nothing to say about what they are told.
Where the notification scheme stops
- It can map events to recipient groups: reporter, assignee, watchers, a project role, a group.
- It cannot change the body. Layout, fields shown and wording are Jira's.
- It cannot condition on a field value. "Only notify when Customer Tier is Enterprise" is not expressible.
So the moment your requirement contains a field name, you are out of the scheme entirely.
The Automation workaround
Automation rules can send email, and this is where most teams land:
When: issue transitioned → If: JQL matches → Then: send email, with smart
values like {{issue.fields.customfield_10042}} and
{{issue.comments.last.body}} in the body.
It genuinely works. Four things end it:
- It is not Jira's notification. Email sent by Automation bypasses the notification scheme, does not thread with the issue's other mail, and knows nothing about JSM request participants.
- You hand-list recipients in every rule. You rebuild "reporter, assignee and watchers, except whoever did the thing" each time, and the "except the actor" part is the one everybody forgets, so people get emailed about their own edits.
- Rules multiply. One per project per event per variation, each holding its own copy of the HTML, with no way to see them side by side.
- Execution limits. High-volume sites burn their monthly automation budget on notification traffic that was never really automation.
The API most admins have never seen
Jira will send its own notification about an issue, with a body you supply:
POST /rest/api/3/issue/{issueKey}/notify
{"subject": "...", "htmlBody": "...", "textBody": "...",
"to": {"reporter": true, "assignee": true, "watchers": true}}That detail is the whole thing. The message goes out through Jira's mailer, to recipients Jira resolves, and Jira delivers only to people who can actually browse the issue. You are not building a mail sender and you are not maintaining SMTP credentials. You are supplying the body Jira was never going to let you change.
The app
Notification Composer for Jira is a rule builder over that endpoint. Rules match on project, event kind, target status, changed fields, public versus internal comments, and an optional JQL check, so "only when Customer Tier is Enterprise" is a condition rather than a separate rule.
The body is a template over the issue: any field by id or by name, the latest comment, the transition, recent activity. HTML escaped by default with a deliberate raw escape hatch. Recipients resolve as reporter, assignee, watchers, JSM participants, named users or groups, with the actor excluded. Re-delivered events are idempotent, so a replayed webhook does not produce a second email. Every send is logged with recipients and outcome, so "did that go out, and to whom" is answerable.
No SMTP and no egress: the app renders on your site and hands the message to Jira. App details and screenshots.
Written by Abaho Katabarwa at Katabarwa Labs. We build small, single-purpose Atlassian and Azure tools that run entirely inside your own tenant. Questions: support@katabarwalabs.dev.