8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email

8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email

Quick Summary: Blueprint objectives 5.2 and 5.3 cover team-managed notifications and personal notification settings, and both need the same troubleshooting mindset. An email reaches a person only if (1) the project's notification configuration targets them, (2) they can see the issue, and (3) their personal settings don't filter it out. This section covers each layer and ends with a systematic troubleshooting routine.

---

Team-Managed Project Notifications (Blueprint 5.2)

Team-managed projects don't use notification schemes. A project admin (the Administer Projects permission) configures email for that project alone in Project settings > Notifications.

Events You Can Notify On

Team-managed notifications use a fixed list of issue events. Jira can email people when someone:

• creates, assigns, updates, moves, or deletes an issue;
• comments on an issue, edits a comment, or deletes a comment;
• logs work, updates a worklog, or deletes a worklog.

There are no custom events in team-managed projects, because their workflows don't fire events the way company-managed transitions do.

Recipient Options

For each event, you can notify:

Defaults: a new team-managed project sends issue-event emails to the issue's watchers, assignee, and reporter.

Managing the Settings

• Add a notification: Project settings > Notifications > Add notification, choose the event, choose recipients, and select Add.
• Edit: use the row's More actions > Edit to change recipients.
• Remove: More actions > Delete stops emails for that event, which is a quick way to cut noise.
• Deleted roles: if you delete a project role, notifications that target it stop working. The entries stay listed until you remove them manually.
• Sender address: a project can send from the default Jira address or from a custom address that an organization admin has added in Atlassian Administration.

Exam angle: "Notify the Scrum master whenever work is moved" in a team-managed project means adding a notification for the moves an issue event, targeted at a role the Scrum master holds, not editing a notification scheme.

---

Troubleshooting a Missing Notification

Work through the layers in order. Most missing emails are explained by the first three checks.

1. Can the user see the issue?

Jira never emails someone about an issue they can't view. Confirm the user has Browse Projects and, if the issue has a security level, that they're a member of it. The Permission Helper (Settings > System > Admin Helper > Permission Helper) answers this for a specific user, issue, and permission.

2. Does the project's configuration target them for that event?

• Company-managed: open the project's notification scheme and check the recipients mapped to the event that actually fires. A custom workflow transition often fires the Generic Event or a custom event, not Issue Updated.
• Team-managed: check Project settings > Notifications for that event.

3. Did the user's personal settings filter it out?

Personal settings act as a filter on top of the admin's configuration (covered next). Did the user make the change themselves? Did they turn off emails for issues they report or watch?

4. Is the email delayed rather than missing?

Batching can hold an email for 3 to 10 minutes (Section 8.2). @mentions and newly assigned issues aren't delayed.

5. Is delivery blocked?

If Jira sends from a custom domain, check the domain's email authentication (below), then the corporate mail gateway's quarantine. On Free plans, Jira sends at most 100 emails per day, and notifications pause until the next day once that limit is reached.

Atlassian also lets organization admins log in as another user to see that user's notification setup directly, which is helpful when the person can't describe their settings.

Personal Notification Settings (Blueprint 5.3)

Every user can narrow the email they receive from Jira. Blueprint 5.3 asks you to know the options and, above all, the relationship between personal settings and the admin's notification configuration.

Where Users Find Them

Settings (cog) > Personal Jira settings > Notification settings, then the Projects (spaces) and work items section. Users can choose email and in-app notifications separately with checkboxes.

The Email Options for Issue Activity

Users can turn off Send me emails for work item activity entirely, or keep it on and choose which situations should email them:

Because "You make changes" is off by default, people don't get emails about their own edits unless they opt in. That's why "I changed it but got no email" is usually expected behavior, not a fault.

Users can also customize notifications per project (for up to 50 projects) and choose how their emails are grouped (batched).

The Relationship with the Admin's Configuration

Atlassian describes personal settings as a filter on top of the notification settings configured by your admin:

• A personal setting can remove emails the notification scheme (or team-managed settings) would send.
• A personal setting can never add emails the admin hasn't configured. If the scheme doesn't notify reporters for an event, ticking "You're the reporter" won't produce that email.
• Some emails aren't controlled by these checkboxes at all, for example filter subscriptions someone set up, site announcements, and Atlassian account emails.

User Default Settings vs. Personal Settings

Jira admins set user default settings (Settings > System > Default user preferences), such as email format (HTML or text), whether users are notified of their own changes, and whether users automatically watch issues they create or comment on. Those defaults are applied when an account is created. After that, each user controls their own personal settings. The one exception: an admin can force the email format for everyone by applying it, so users can't change it. Chapter 10 covers user defaults in full.

---

Site Outgoing Email Infrastructure & Custom Domains

Jira Cloud sends email through Atlassian's own mail infrastructure. Organization admins can add custom sender domains in Atlassian Administration, and project admins can then choose a custom sender address for a project.

Default Cloud Sender Address

By default, outgoing emails originate from an Atlassian-managed sender address formatted as jira@<site-name>.atlassian.net. While functional, enterprise organizations typically require notifications to appear from their own corporate domain (e.g., jira-notifications@acme.com) to maintain brand consistency and employee trust.

Custom Email Domains: SPF and DKIM Verification

When an organization configures a custom sender address in Jira Cloud, outbound emails are still physically dispatched from Atlassian's cloud servers. If the organization does not authenticate Atlassian's servers in their corporate DNS zone, receiving email systems (such as Google Workspace, Microsoft 365, or enterprise mail gateways) will classify the emails as forged or spoofed messages, quarantining or discarding them silently.

To ensure deliverability, administrators must publish two mandatory DNS records:

Exam Tip: If permissions, the notification scheme, and personal settings all check out, but nobody on the corporate domain receives email sent from a custom address, suspect missing or misconfigured SPF/DKIM records that make corporate gateways quarantine the messages.

Internal Jira Notifications vs. Jira Service Management Customer Notifications

A distinction that often confuses Jira admins is the complete separation between Internal Jira Notifications and Jira Service Management (JSM) Customer Notifications.

+-------------------------------------------------------------------------+
|         INTERNAL NOTIFICATIONS VS. JSM CUSTOMER NOTIFICATIONS           |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ Jira Platform / Jira Software ]     [ Jira Service Management (JSM) ]|
|                                                                         |
|  Engine: Notification Scheme           Engine: Customer Notifications   |
|  Configuration:                        Configuration:                   |
|  - Settings > Issues >                 - Project settings > Notifications|
|    Notification schemes                  > Customer notifications       |
|                                                                         |
|  Target Audience:                      Target Audience:                 |
|  - Licensed Internal Users             - External Portal Customers      |
|  - Software Developers, Admins         - Request Participants           |
|                                                                         |
|  Prerequisites:                        Prerequisites:                   |
|  - Active Jira Product License         - Zero Jira Product License      |
|  - 'Browse Projects' Project Perm      - Customer Portal Account        |
|                                                                         |
|  Email Content:                        Email Content:                   |
|  - Internal technical issue view       - Customer-friendly portal view  |
|  - Shows field diffs, technical keys   - Sanitized; excludes internal   |
|  - Includes internal comments          - Public comments only           |
+-------------------------------------------------------------------------+

Why Notification Schemes Cannot Notify Portal Customers

Jira administrators frequently attempt to add external customers to internal Notification Schemes, expecting customers to receive ticket updates. This fails completely for two structural reasons:

1. Licensing and Permission Boundary: Portal-only customers do not possess Jira product access licenses and are never granted the Browse Projects project permission in company-managed permission schemes. Because they lack Browse Projects, the Notification Scheme engine immediately prunes them from recipient lists.
2. Security & Information Containment: Internal notification schemes transmit raw issue data, technical field changes, and internal work logs. Customer notifications are intentionally processed through a sanitized, customer-facing notification engine that only dispatches customer-visible comments and status milestones.

Managing Customer Notifications in JSM

Customer communications are configured within the specific service project at Project settings > Notifications > Customer notifications:

• Standard rules include Customer request created, Public comment added, Request resolved, and Customer satisfaction (CSAT) survey.
• Templates can be customized with branding and variables such as the request's summary and status.
• Internal comments posted by service agents never trigger customer notifications, preserving internal staff collaboration privacy.