Notifications, Email, and Communication Settings
The chain: event → recipients → permission
An event occurs (issue created, updated, assigned, commented, transitioned, deleted). The project's notification scheme maps that event to recipients: Current Assignee, Reporter, Project Lead, All Watchers, a specific user, a group, or a project role. Mail is then sent to everyone on that list who also has Browse Projects. That final check is the most frequently tested fact: a named recipient with no permission receives nothing.
Designing quiet notifications
Notify Reporter and Current Assignee on create and on update, and let watchers opt in for the rest. "Issue Updated" fires on almost every change and is the usual cause of email-volume complaints. Users can adjust their own preferences and watch or unwatch issues, but the scheme itself belongs to the administrator. Notification schemes are attached per project and can be shared across projects.
Traps
- Adding a user to a scheme does nothing if that user lacks Browse Projects.
- Removing someone from a group silently removes their notifications.
- Emails produced by automation rules are configured inside the rule, not in the notification scheme.
- Jira Cloud's outbound mail is managed by Atlassian; there is no SMTP server screen to configure in Jira settings.
- Announcement banners and system messages are separate from notification schemes and reach users at the UI level.
Rule of thumb: debug missing email in order - did the event fire, was the recipient listed, does the recipient have Browse Projects? The third step is the usual culprit.