HR Says Nobody Gets the Right Email

Access and notification are two separate objects, and both must be configured.

Being in recruiters grants the permission; it does not subscribe anyone to anything. Four gates, all of which must pass:

1. Notification scheme. The recruiter must be a listed recipient for the relevant event - as a group, a project role, or a single user. Open Project settings → Notifications and add them. Prefer a project role Recruiters over the global group so the project lead controls membership.
2. Permission. A recipient only receives mail for an issue if they can browse it. A person listed in the notification scheme but outside the permission scheme gets nothing, silently - and the reverse is also true, which is the trap here.
3. Issue-level security. If HR uses security levels, an issue the recruiter cannot see produces no email regardless of gates 1 and 2.
4. Personal settings and account state. Their own notification preferences may suppress Comments or their own changes; a new external account may have an unverified or bouncing address. Check User management for a bounce or unverified state.

Do not widen the permission scheme as a fix - it was never the broken half of the configuration.

'Some but not others' points at issue security, personal settings, and the difference between scheme entries and stored watchers - not at a broken scheme.

Separate the causes in this order:

1. Read the scheme row by row. If Project Lead is a recipient for only some events (Issue Created but not Issue Commented, for example), she gets mail for those events only. This is the most common answer and the easiest to check.
2. Issue-level security. Even with Browse Projects and a matching notification entry, an issue in a security level she does not belong to generates no email. Compare her groups and roles against each level in the HR issue security scheme - this alone explains a clean split between 'some issues' and 'others'.
3. Personal settings. 'Do not notify me about my own changes' suppresses mail for anything she edited or transitioned. She will describe those as issues she 'didn't get told about'.
4. Scheme entry versus watcher. The Project Lead entry is resolved at send time and always follows the current role holder. Issue watchers are stored per issue at the moment someone started watching. If the role changed hands recently, older issues carry a stale watcher list - two different mechanisms that produce the same complaint.

Ask for three specific issue keys she expected mail on, then check each against steps 1–4. Guessing from symptoms wastes a week.

There is no digest switch. Be explicit about that first, then reduce the noise at the source.

What does not exist: Jira Cloud's personal notification preferences let a user toggle event types and suppress their own changes. They do not offer a daily or weekly digest of issue emails. A true digest requires an automation rule (scheduled, batched, sending one message) or a marketplace app - and apps are off the table this week.

What you can deliver now:

• Replace the group with a role. Swap hr-team for project role HR Agents in the notification scheme. Membership becomes the project lead's job, and future joiners do not silently inherit HR mail from a company-wide group.
• Cut events, not people. Restrict the Issue Commented entry to role HR Agents plus Current Assignee and Reporter. That single change removes most of the 600 daily messages. Everyone else opts in per issue by watching it.
• Audit watchers. Autowatch adds a watcher every time someone comments, so recipient lists grow invisibly. Check All Watchers entries and the issue's watcher list before blaming the scheme.
• Interim digest, if truly needed: a scheduled automation rule with a JQL over the last 24 hours that posts one Slack message or one email to the HR channel. It is a summary of activity, not a personalised digest, and it consumes automation allowance - price that in.

Announce the change before it lands. People relying on ambient email will notice the silence, and watching an issue is the self-service control they should be using.