Automation Rule Floods the Notification Scheme

The automation rule has only a trigger and no conditions, so every transition to Escalated runs the full action set. A bulk transition of 60 issues produces 60 rule executions. Each execution adds a comment and sends an email. The notification scheme then notifies the Escalated watchers group on each comment, so each comment can generate additional notifications. That multiplication explains 240 emails: rule emails plus notification-scheme emails, possibly with multiple watchers per issue.

Duplicate comments have several plausible causes. If the rule has multiple triggers or the transition fires more than once (for example, a bulk operation plus a workflow post function), the rule can execute repeatedly. If the rule's action is configured to run on the parent or on linked issues, the same issue may be acted on twice. Also, automation rules can re-trigger themselves if the action causes a transition that matches the trigger; here the comment action should not, but a misconfigured branch could.

Design flaws: (1) no condition to limit scope (e.g., only issues of a certain type or priority); (2) no guard against bulk execution, such as a check on the number of issues or a throttle; (3) notification amplification through the notification scheme, which should be reviewed separately from automation; (4) no idempotency check to prevent duplicate comments. The fix is to add conditions, consider a scheduled rule with batching, and align notification settings so automation and the scheme do not both notify the same audience.

The rule's logic conflates "no update" with "inactive". An escalated issue awaiting a customer reply may have no Jira updates precisely because the team is waiting, so the rule closes a legitimately open item. The redesign should add a condition that excludes statuses representing waiting states, such as Escalated or Awaiting Customer, and should check the last comment direction if possible (for example, whether the last comment was from the customer or the team).

Before changing the rule, gather data: (1) how many issues were closed by the rule in the last 90 days, and how many were reopened afterward; (2) the status distribution of closed-by-rule issues; (3) whether the "no update in 30 days" measure uses the updated date, which changes on any edit including automation comments, so the rule may be measuring the wrong thing; (4) whether any closed issues had open customer correspondence.

Redesign: add a JQL condition excluding waiting statuses and excluding issues with a linked open request; run in a dry-run mode first (log matches without transitioning); require a comment before closing so there is an audit trail; and consider a two-stage approach where the rule first sets a "Pending Closure" status and closes after a further grace period if no response. This reduces the risk of closing active work and gives the team a chance to intervene.

Treat the two systems as distinct channels with distinct purposes. The notification scheme handles event-driven notifications to project stakeholders (e.g., watchers, groups) based on issue events. Automation handles process-specific messaging. When both target the same audience, volume multiplies and ownership blurs.

Practical separation: (1) Audit the notification scheme and remove broad group notifications for comment events where automation already notifies the relevant people, or narrow them to specific roles. (2) In automation, send notifications to explicit, narrow recipients (the manager, the assignee) rather than groups, and include a clear subject or marker so recipients can filter. (3) Avoid having automation add comments that trigger scheme notifications to large groups; if the comment is for audit only, consider whether it needs to notify anyone. (4) Use a dedicated notification scheme for the project if it differs from organizational defaults.

Then document the resulting matrix: event, recipient, channel, and owner. Test with a single issue transition and count emails per recipient. This makes future changes reviewable and prevents the "who sent this?" problem. The judgement point is that automation is not a substitute for notification configuration; each should have a defined audience and the overlap should be intentional.