Notification Storm After a Group Rename and Scheme Inheritance

Notification schemes reference groups by name/ID at evaluation time, so the rename has two effects:

1. Silent group: the scheme still lists qa-team. After the rename, the old group is now the new empty group - no members. Notifications targeted at qa-team therefore reach nobody. The quality-engineering group has the members but is not referenced by any scheme. Result: everyone who relied on group membership goes dark. This is not a permissions issue; the scheme is intact but points at an empty group.

2. Duplicates: users who are members of quality-engineering and are also individually notified (as Current Assignee, Reporter, or Watcher) would normally get one email - Jira de-duplicates per user per event. Duplicates arise when a user is matched by two distinct notification entries that are not de-duplicated, e.g., they are in both developers and a personally-added entry, or the scheme has the same group listed twice after an edit. The rename itself doesn't create duplicates; a scheme edit that added quality-engineering alongside the old qa-team (or a second identical entry) does. The admin likely added the new group without removing the old one, and some users are in both.

3. PAY unaffected: PAY's scheme was cloned - it is a separate scheme object with its own copy of the entries. The clone snapshot still references qa-team... which is now empty, so PAY should also be affected unless PAY's clone was edited or PAY users are individually notified. The stated fact that PAY users still get mail suggests PAY's scheme was independently updated to quality-engineering, or PAY users are assignees/reporters. This must be verified entry-by-entry, not assumed.

Sequence (avoid making the backlog worse):

1. Pause outbound mail (or set the SMTP relay to hold) so the 9,000-message backlog doesn't grow while you fix configuration. Do not flush yet.
2. Audit every notification scheme that references qa-team or quality-engineering. For each, replace the empty qa-team entry with quality-engineering and remove any duplicate entries (same group listed twice, or a user who is also covered by a group). Use the scheme's entry list; there is no bulk "find references" UI in all versions, so check each of the 30 projects' assigned scheme and PAY's clone.
3. Decide the fate of the empty qa-team group. If a script depends on the name, keep it but document that it must not be used in schemes; otherwise delete it to prevent future confusion. Do not re-add members to it - that would re-create the split.
4. Verify de-duplication: confirm each scheme notifies each user once per event. Jira de-duplicates identical recipients, but distinct entries (group + individual) can still double-send in some configurations; consolidate to group-only where possible.
5. Drain the queue in batches after config is correct, monitoring for errors; purge messages that are now stale (e.g., >24h old) rather than delivering a flood.
6. Prevent recurrence: document that group renames must be followed by a scheme audit; prefer project roles over groups for notifications so membership is managed per project; add a change-management step for group renames.