nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

"sendNotifications: false" in Automation "Add comment" action has no effect – emails are still being

Stefan Tolksdorf-Cyron

Hi Community! 👋

I hope you can help me out – I'm running into an issue that has me completely stumped, and I'd really appreciate your experience and insights.

Context

We've built several global automation rules in Jira Cloud as part of our GDPR deletion process. These rules run on a schedule (JQL trigger), mark work items for deletion, and leave a comment on each affected issue.

Each rule consists of two actions:

"Edit issue" – sets two custom fields
"Add comment" – leaves a comment informing users that the work item will be deleted in one year

The Configuration – GUI vs. JSON

There's an important distinction here:

"Edit work item" action: The GUI offers an official "Send notifications" checkbox under the advanced options, which I've set to false.

📸 Screenshot 1

"Add comment" action: The GUI does not offer an official "Send notifications" checkbox for this action type. I therefore set sendNotifications: false manually in the exported JSON and re-imported the rule. Jira accepted the import without any errors.

{
  "component": "ACTION",
  "type": "jira.issue.comment",
  "value": {
    "comment": "System Notification: ...",
    "publicComment": false,
    "sendNotifications": false,
    "addCommentOnce": true
  }
}

JSON of the comment action with <em>sendNotifications: false</em>

The Problem

Despite having sendNotifications: false manually set in the JSON of the "Add comment" action, users who are listed in the notification scheme of the affected projects for the "Issue Commented" event are still receiving email notifications.

The rule is intended to be applied initially to approx. 85,000 work items – and then on an ongoing basis to any new items matching the criteria. Preventing an email flood of this scale is absolutely critical for us.

Interestingly, sendNotifications = false on the "Edit work item" action works correctly – no emails are triggered there.

🤔 My Questions

Is sendNotifications in the JSON of the "Add comment" action actually evaluated by Jira at all, or is it silently ignored on import because it's not a supported parameter for this action type?
Is it known behavior that the "Add comment" action simply has no way to suppress email notifications from the notification scheme?
Is there a reliable workaround – other than removing the comment action entirely?

Here's what I've considered so far:

Combining publicComment: false + sendNotifications: false in the JSON → emails still come through
Removing the comment action entirely → no emails, but also no comment on the issue

Any hints are very much appreciated! Thanks in advance 🙏

Environment:

Jira Cloud
Automation: Global rule, JQL-triggered (scheduled)
Actor: Automation for Jira (system account)
Affected action: jira.issue.comment

Accepted answers

Gabriela - LeanZero

Hi @Stefan Tolksdorf-Cyron, sendNotifications isn't a parameter of that action, so nothing evaluates it. Your export proves it's stored, your inbox proves it isn't read. The action exposes the comment body and its visibility, which is why publicComment survived and changed nothing.

The asymmetry you found is documented in AUTO-602, which opens with Atlassian's own line, currently we can only suppress Email notifications for the Edit Issue action performed by automation or Jira. Gathering Interest since 2020, 1066 votes. Its own ask is in-app notifications, so it's that first line that matters to you.

For 85,000 I'd pull the backfill out of the rule. The REST edit-issue call takes notifyUsers=false and its body can carry update.comment.add, so the comment rides an edit instead of the comment endpoint, which has no equivalent flag. Try it on five, with yourself watching. That part is my guess, the docs only promise notifyUsers covers the update mail. What I'm sure of is emptying Issue Commented on those schemes for the run.

Ongoing is a trickle. The rule may not need solving.

https://jira.atlassian.com/browse/AUTO-602

All comments

Andrea Robbins

I wonder if you export that rule, will it still shows as false, or maybe it defaults to true?

I didn’t even know this existed, so very cool article post

Stefan Tolksdorf-Cyron

He @Andrea Robbins , it stays at false. I was sure, that I´m not the first one who stumbled over a situation like this.

Andrea Robbins

You very well might be! Hopefully not though because I would be interested in the answer as well.

interesting it is still false!

Gabriela - LeanZero

Ongoing is a trickle. The rule may not need solving.

https://jira.atlassian.com/browse/AUTO-602

Stefan Tolksdorf-Cyron

Hello @Gabriela - LeanZero , thank you for your reply. So things are as they are at the moment.

Are you suggesting to set the comment via a REST call?

Arkadiusz Wroblewski

Hi @Stefan Tolksdorf-Cyron

@Gabriela - LeanZero is right, sendNotifications is ignored in native "Add comment" automation actions

Use a "Send web request" action as a workaround with endpoint PUT /rest/api/2/issue/{{issue.key}}?notifyUsers=false and payload to update fields and add a comment in one request. The API token account requires "Administer Jira" or "Administer Projects" permissions for notifyUsers=false functionality.

Scheduled rules cap at 999 issues per run so batch your 85k backfill using JQL (e.g., "GDPR notification date" IS EMPTY).

Best,

Arek 🤠

Stefan Tolksdorf-Cyron

Thank you for your replies and for suggesting possible courses of action.

Gabriela - LeanZero

Yes, and I can drop the hedge I put on it. Atlassian documents that exact route as the workaround on JRACLOUD-97682, "Add notifyUsers=false option to comments API", raised 4 March, still Gathering Interest. The Workaround section on the ticket is a PUT to /rest/api/3/issue/ABC-1?notifyUsers=false carrying update.comment.add with an ADF body, which is Arek's call written out in full. So the comment endpoint genuinely has no flag of its own and riding the edit call is Atlassian's own way round it. That ticket has 0 votes and 1 watcher, so I would not wait for the comment API to grow the option.

https://jira.atlassian.com/browse/JRACLOUD-97682

Stefan Tolksdorf-Cyron

He @Arkadiusz Wroblewski , I will try it. Do you think I can use a "Service account" for it?

How to grant the needed permission? Like this:

Or via the token scope?

Arkadiusz Wroblewski

A service account with write:jira-work scope and Administer Projects permissions works well; this allows notifyUsers=false to take effect.

Use PUT https://api.atlassian.com/ex/jira/{cloudId}/rest/api/3/issue/{{issue.key}}?notifyUsers=false instead of your site URL for scoped tokens via Atlassian API Gateway. Test on one issue before a full backfill.

Stefan Tolksdorf-Cyron

Woohoo. Thank you for the URL. I had the wrong one.

Still receive:

The scopes for the token:

manage:jira-configuration

write:jira-work

read:jira-work

read:jira-user

manage:jira-project

and in addition the "administer projects"-permission in the test space:

Or do I need to grant other scopes or permissions somehow?

Thank you for your help!

Stefan Tolksdorf-Cyron

OK, authentication and posting comments are now working. Using Smartvalues in combination with ADF is working fine too. Thank you for your super-fast and absolutely invaluable support!

Arkadiusz Wroblewski

We are here to help each other, and I'm curious which one helped. 🤠

Ah, well, alone we are master of disaster.

Together, Power Rangers 🤣🤠.

Gabriela - LeanZero

The Single User claim I made doesn't hold up. I leaned on an old thread and stopped reading it too early. It's Jira Server 7.2, not Cloud, and the person investigating there tried twice, on 7.2.0 and on 7.9.2, to reproduce a Single User recipient getting mail through notifyUsers=false, and couldn't either time. The original poster never got a confirmed cause. So it's one unreproduced report on a decade-old Server release, and I handed it to you as a known mechanism.

I don't have a Cloud-confirmed answer to put in its place. You already have the setup in front of you, so if there is a Single User entry on that event, firing it once with notifyUsers=false and watching that mailbox settles it faster than anything I can cite.

The scope and permission diagnosis in my earlier replies is unaffected.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

automation

jira-automation

notifications

notification-scheme

add-comment