Short definition
A notification scheme in Jira is a named set of mappings from events (Issue Created, Issue Updated, Issue Commented, etc.) to the recipients notified by email. Each project is assigned one notification scheme. Recipients can be roles, groups, individual users, reporter, assignee, watchers, or current assignee. Schemes are reusable across projects, so editing one scheme affects every project that uses it.
Anatomy of a notification scheme
A scheme is a table with events down one axis and recipients across the other:
| Event | Recipients |
|---|---|
| Issue Created | Reporter, Assignee, All Watchers |
| Issue Updated | Assignee, All Watchers |
| Issue Resolved | Reporter, Assignee, All Watchers, Project Lead |
| Issue Commented | Assignee, All Watchers, group: stakeholders |
| Issue Worklog Added | Project Lead |
| Issue Deleted | Administrators |
Each row can have multiple recipients. Recipients can be:
- Roles: Project Role: Developers (every member of that role in the project).
- Groups: group: jira-administrators (every member of the group).
- Specific people: a single user account.
- Reporter / Assignee / Current Assignee / Project Lead - dynamic, per-issue.
- All Watchers - the watcher list.
- Component Lead - the lead of any component on the issue.
When an event fires, Jira computes the union of all matching recipients and sends one email each (deduplicated).
Notification permissions
A recipient who doesn’t have permission to view the issue won’t receive the notification - Jira silently filters them out. This is intentional: notifications shouldn’t be a back-channel for issue content that the recipient otherwise couldn’t see. It also means apparent notification gaps are often permission gaps in disguise.
Quietening a noisy scheme
The standard sequence for reducing email overload:
- Identify the noisiest events. Usually Issue Updated and Issue Commented.
- Audit those events’ recipient lists. Often three or four overlapping recipients lists target the same user.
- Consolidate. Replace per-user entries with roles where possible; remove redundant rows.
- Test with a specific user. Use Jira’s notification helper (admin tool) to show exactly who would be notified for a given event on a given issue.
This usually halves email volume without removing real signal. The remaining noise is genuine - people are participating in lots of issues - and is addressed via per-user email filtering, not scheme edits.
Where bulk-watch fits
The notification scheme controls what triggers email to which recipient list. It doesn’t help an on-call commander quickly subscribe a team to a hot ticket. That’s where Watch It comes in: JQL-based bulk watcher updates, per-component default watchers, and team-based subscriptions that complement the notification scheme instead of fighting it. Same underlying notifications, lighter operational overhead.
Auditing the scheme
Two practical checks:
- Which projects share this scheme? A change affects all of them. Document the intent of each scheme (general / restricted / JSM / regulated) so reviewers know what’s at stake.
- Which events have empty recipient lists? Usually a sign that the scheme was customised at one point but the customisation is now dead weight. Empty rows can be removed for clarity.
See also (Redmoon products)
Common questions
What is a notification scheme in Jira?
A notification scheme in Jira is a named set of mappings from events (Issue Created, Issue Updated, Issue Commented, etc.) to the recipients notified by email. Each project is assigned one notification scheme. Recipients can be roles, groups, individual users, reporter, assignee, watchers, or current assignee. Schemes are reusable across projects, so editing one scheme affects every project that uses it.
Why am I getting so many Jira emails?
Almost always the notification scheme, not your watch list. The scheme may notify the same recipient (you) for many overlapping reasons - assignee, reporter, watcher, role member - so a single update triggers several emails. Audit the scheme's recipient lists and consolidate; this fixes 90% of email-overload complaints.
Can different events have different notification recipients?
Yes. The scheme is a matrix of event -> recipient(s). Issue Created might notify Reporter + Assignee + Watchers; Issue Resolved might also notify Project Lead and a specific group; Issue Commented might only notify Watchers. Each event row is independent, which is what lets fine-grained quietening of noisy events work.
How do I stop notifications for myself on a specific issue?
Remove yourself from the watcher list on that issue. But that only stops watcher-based notifications - if you're the reporter or assignee, you'll still be notified because the scheme also targets those roles. To stop notifications entirely, you'd have to be removed as reporter/assignee, which is usually inappropriate.