Community
Q&A
Atlassian Automation
Questions
"sendNotifications: false" in Automation "Add comment" action has no effect – emails are still being

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

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 sendNotifications: false

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

4 answers

1 accepted

3 votes

Answer accepted

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

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

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?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Like • Arkadiusz Wroblewski likes this

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

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Like • Stefan Tolksdorf-Cyron likes this

1 vote

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 :)

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

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

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

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

interesting it is still false!

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Like • like this

0 votes

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

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

0 votes

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 🤠

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

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?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Like • Arkadiusz Wroblewski likes this

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.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Like • Stefan Tolksdorf-Cyron likes this

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!

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Like • Arkadiusz Wroblewski likes this

Head is smoking. :D

It is still not working for me. I recreated the token with classic scopes.

read:jira-user, read:jira-work, write:jira-work

I read that a mixture of classic and granular scopes will lead to problems like this. But I still receive the same error in the audit log.

Unable to publish the web request - received HTTP status response:

404

Error found in the HTTP body response:

{"errorMessages":["Issue does not exist or you do not have permission to see it."],"errors":{}}

@Arkadiusz Wroblewski any ideas?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Forums

Q&A

Community resources

Support

Top groups

Community resources

Support

Learn

Community resources

Support

Events

Community resources

Support

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

Context

The Configuration – GUI vs. JSON

The Problem

🤔 My Questions

4 answers

1 accepted

Suggest an answer

Was this helpful?

Thanks!

TAGS

Atlassian Community Events