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

6 answers

1 accepted

5 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 • like 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

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.

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

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!

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

Comment

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 🤣🤠.

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

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.

Comment

I will come back to you when I have some time, I'm traveling now.

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

That 404 is the visibility gate, not the flag. You swapped scope sets and the error didn't move, which fits, the endpoint returns 401 when the credentials are incorrect or missing and 404 when the issue is not found or the user does not have permission to view it. Edit issue asks for Browse projects and Edit issues on the project the work item is in. Administer Projects is neither of those and doesn't bring Browse with it.

Run GET /rest/api/3/myself on the same base URL first, it tells you which account the header is landing as. Then the same GET on the issue key. If that 404s too it's visibility. Browse Projects in that project's permission scheme is what I'd check first, then whether the service account holds Jira product access at all. An issue security level it isn't in does the same thing.

Keep Administer Projects though. Without it Jira ignores notifyUsers and sends the mail anyway.

https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueIdOrKey-put

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

Comment

Hi @Stefan Tolksdorf-Cyron, if those Issue Commented recipients are set up as Single User entries instead of a role, group, or Watcher, notifyUsers=false skips them regardless of the caller's permissions. That part isn't scope-fixable. Someone hit exactly this before - full Jira-admin rights, still got the mail, and switching that entry to Watcher is what stopped it. See here. Your token already clears the bar the docs set - write:jira-work plus Administer Projects.

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

@Gabriela - LeanZero is correct, your current scopes are enough, so the 404 isn't a missing scope. Verify you're using the site Cloud ID in /ex/jira/{cloudId}/, not the Organization ID, as that causes 404 errors.

Check Permission Helper to ensure the service account has Jira app access, Browse Projects, Edit Issues, Add Comments, and any applicable issue security permissions.

To isolate the cause, run a GET request to /myself to check your token and Cloud ID, then a GET to /issue/{{issue.key}} to test issue visibility. If both succeed, the issue lies in your PUT request or payload. Keep Administer Projects assigned so notifyUsers=false takes effect once access is resolved.

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

Like • Stefan Tolksdorf-Cyron likes this

Suggest an answer

Was this helpful?

Thanks!

Atlassian Automation

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

6 answers

1 accepted

Suggest an answer

Was this helpful?

Thanks!

TAGS

Atlassian Community Events