Suppressing the email when Jira Automation adds a comment (and why sendNotifications does nothing)
Gabriela Perdum
Author
9 min readAugust 2, 2026
Key takeaways
sendNotifications is not a parameter of the automation Comment action, so nothing reads it. Your export proves the key is stored; your inbox proves it is not used.
The Jira comment REST endpoint ignores unknown keys silently. I posted sendNotifications, notifyUsers and totallyMadeUpKey12345 to it and all three returned 201.
notifyUsers is real — on Edit issue, on Update comment and on the worklog endpoints. The one place it does not exist is ADD comment, which is exactly the operation automation performs.
Sending a typed parameter a bad value tells you whether it is declared on that endpoint. It does NOT tell you whether your account may use it — that is a separate permission gate, and a missing permission is ignored silently.
I verified the REST mechanics on a live Jira Cloud site. I did not verify that the email itself stopped, because no API reports it — treat suppression as documented, not measured.
Somebody on the Atlassian Community had done everything right and it still did not work. They exported a Jira Automation rule, hand-added "sendNotifications": false to the jira.issue.comment action, re-imported it without an error, exported it again to check — the key was still there — and then watched the rule send "Issue Commented" email to every watcher anyway. They were staring down a backfill of about 85,000 work items.
That is a good bug report, and the answer is not the one people usually give.
The flag does nothing because it is not a parameter of that action. Nothing in the automation engine looks at it. Their export proved the key was stored; their inbox proved it was not read. Those are two different things, and Jira's APIs are unusually willing to let you confuse them.
Note
Everything below was checked on 2 August 2026 against a live Jira Cloud site. Ticket statuses and vote counts move; I have dated each one so you can tell when this page has gone stale.
Check the rule builder before you touch any of this
Start here, because if it applies to you the rest of this article is unnecessary.
AUTO-602's own description opens: "Currently, we can only suppress Email notifications for the Edit Issue action performed by automation or Jira." That sentence implies the automation Edit work item action has an email-suppression control. Historically it did — a "send notifications" checkbox.
I could not confirm its current state. Atlassian's automation actions documentation does not list any notification option for either the Edit or the Comment action, and community reports disagree about whether the checkbox still exists in the current rule builder. So: open your own rule builder, open an Edit work item action, and look. If the control is there, and you can restructure your rule to set a field rather than post a comment, that is the cleanest answer available and it is entirely in-product.
If it is not there, or you genuinely need a comment, carry on.
Why the flag is ignored
The automation Comment on work item action exposes the comment text, smart values inside it, and the comment's visibility. Atlassian describes it as "Adds a comment to a work item. You can use smart values to reference work item fields to personalize the comment. You can also set the comment visibility." There is no notification control documented, and no hidden one that anybody has demonstrated.
The round-trip fooled everybody because the exported JSON survives re-import untouched. The most likely explanation is that the importer keeps keys it does not recognise and hands the action only the fields the action knows about — I did not reproduce that inside the automation engine, so treat the mechanism as inference. What is not inference is the behaviour of the platform underneath it, which I did test, and which does exactly the same thing.
Do not conflate this with the comment visibility setting, which is real and documented on the action. Visibility controls who can see the comment — in Jira Service Management, whether it is internal or customer-facing. It is a different axis and it does nothing to Jira notification-scheme email.
Where notifyUsers actually exists
notifyUsers=false is a genuine Jira Cloud parameter. It appears on Edit issue, on Update comment, and on the three worklog endpoints. The one operation that does not have it is add comment — which is precisely the operation an automation rule performs when it comments.
That gap is what JRACLOUD-97682 ("Add notifyUsers=false option to comments API") exists to close. Read 2 August 2026: Gathering Interest, Unresolved, 1 vote, 2 watchers, created 4 March 2026. Its Workaround section gives the route round the gap — add the comment as part of an issue edit:
So "just call the API instead of using automation" is only a fix if you call that endpoint. Posting to /issue/{key}/comment gets you nowhere no matter what you attach to it.
AUTO-602 is the ticket to cite for the asymmetry itself. Read 2 August 2026: Gathering Interest, Unresolved, 1,068 votes, 513 watchers, created 29 April 2020. Six years of votes, still a suggestion.
Quote it carefully. Its title is scoped to in-product and in-app notifications, but its description asks for "email notifications as well as the Notifications on the instance". People cite it for one and get corrected on the other; the accurate framing is that the title and the description cover different scopes, and the opening sentence is what settles the Edit-versus-everything-else question.
Warning
Do not reach for JRACLOUD-78140 ("Implement notifyUsers parameter to a number of API calls"). Checked 2 August 2026: Closed, Won't Do, 9 votes — and its description names create, bulk-create, assign and transition. The add-comment endpoint is not in it. It is the nearest-looking ticket to the problem and it is the wrong one.
Telling a real parameter from one Jira is only humouring you
When I ran these calls against a live site, every route returned a success code. That tells you nothing on its own. So I sent each endpoint a parameter that cannot exist, and then sent the real parameter a value it cannot accept.
Call
notifyUsers=false
notifyUsers=notaboolean
madeUpParam=notaboolean
POST /rest/api/3/issue/KEY/comment
201
201
201
PUT /rest/api/3/issue/KEY
204
400
204
PUT /rest/api/3/issue/KEY/comment/ID
200
400
200
4 rows × 4 columnsHeader row enabled
On the edit and update-comment endpoints a bad value comes back as Failed to convert 'notifyUsers' with value: 'notaboolean'. On the add-comment endpoint the same garbage sails through with a 201, exactly like a parameter I invented on the spot. That is the difference between a parameter the endpoint declares and one it has never heard of.
The same silence applies in the request body. Posting three unknown keys alongside a valid comment:
Extra key in the POST body
Result
sendNotifications
201
notifyUsers
201
totallyMadeUpKey12345
201
4 rows × 2 columnsHeader row enabled
All accepted, all ignored, none present on the created comment when I read it back — its keys are exactly author, body, created, id, jsdPublic, self, updateAuthor and updated.
What this test does not prove
I want to be precise about this, because the obvious conclusion is wrong in two directions.
The 400 fires before the handler runs. Send it against a work item that does not exist and you still get a 400 rather than a 404:
That is query-string type binding, not the feature working. A parameter can be declared, type-checked, and still do nothing for you: overrideScreenSecurity is documented as available to Connect and Forge apps, and sending it notaboolean as an ordinary API-token caller still returns 400.
And it only works on typed values.expand is unquestionably read — ask for expand=renderedBody and you get a renderedBody field. Ask for expand=totalgarbage and you get a cheerful 200 and no complaint, because it is a string and any string is valid.
So the honest scope: sending a bad value to a typed parameter tells you whether that parameter is declared on that endpoint. It does not tell you the parameter is honoured for your account, and it tells you nothing at all about string parameters. It is a fast way to rule a route out — which is exactly what it does for add-comment — not a way to rule one in.
The permission gate is the part that bites
notifyUsers=false requires Administer Jira or Administer Projects on the acting account. Without it the parameter is dropped: the edit still happens, the comment still lands, and the mail still goes out. Nothing fails, nothing warns you.
Check for both, with project context, or you will get a misleading answer:
Asking for ADMINISTER alone returns only the global permission, so a project administrator without global admin reads false and wrongly concludes they cannot do this. Either one being true is enough.
Doing it safely
1
Look in the rule builder first
if the Edit work item action still offers a notification checkbox and your rule can set a field instead of commenting, use that and stop here
2
Check the permission with project context
GET /rest/api/3/mypermissions?projectKey=ABC&permissions=ADMINISTER,ADMINISTER_PROJECTS, and remember a missing permission is dropped silently rather than refused
3
Run it on five work items, with yourself watching
add yourself as a watcher, fire the edit-route call, and check your own inbox. This is the only step that tests suppression rather than mechanics
4
Take the backfill out of the rule entirely
a one-time catch-up of 85,000 items and a steady-state trickle are different problems; script the backfill against the edit endpoint and let the rule keep handling only new matches
5
If you need certainty rather than a workaround, use the notification scheme
empty the recipients on the Issue Commented event for the duration of the backfill, then restore them
Step 5 is the unglamorous option and the only one that depends on nothing undocumented. It is reversible, and it suppresses the email because there is nobody left to send it to.
The event is Issue Commented, event id 6. On the site I checked, its recipients were Current Assignee, Reporter and All Watchers — which is why a backfill across tens of thousands of items becomes tens of thousands of emails.
Before you edit a scheme, find out which one the project actually uses and how many other projects share it:
bash
1# which scheme is bound to this project2curl-s-u"$AUTH""$SITE/rest/api/3/project/ABC/notificationscheme"\3| python3 -m json.tool
45# how many projects each scheme is bound to6curl-s-u"$AUTH""$SITE/rest/api/3/notificationscheme/project?maxResults=50"\7| python3 -m json.tool
On the site I tested, the project's scheme was id 10000 and that same scheme was bound to eleven projects. Editing it to quiet one backfill would have silenced comment mail across all eleven. If yours is shared, copy the scheme first and point only the target project at the copy.
Success
Emptying a notification-scheme event affects every rule and every human action on that project, not just your backfill. Write down what you removed before you remove it, and put it back the same day.
What I verified, and what I did not
I checked the REST mechanics on a live Jira Cloud site: which endpoints declare notifyUsers, which reject a bad value, which unknown keys are silently swallowed, what survives onto the stored comment, and whether a comment added through the edit route shows up in the issue history. It does not — the changelog stayed empty across every route, so you cannot use history entries to tell the two paths apart.
I did not verify that the email stopped arriving. No Jira Cloud API reports whether a notification was queued or sent, so the only honest test is a real mailbox, which is step 3 and which you have to run on your own site. Atlassian documents the edit-route workaround and the endpoint type-checks the parameter; those two facts are why I would try it. They are not a measurement, and I am not going to present them as one.
Three more limits. This is Jira Cloud — the Data Center notification model differs. I tested the REST endpoints rather than the automation rule importer, so the importer explanation remains inference. And the state of the Edit action's notification checkbox is genuinely unresolved: the docs omit it, AUTO-602's opening sentence implies it, and community reports conflict. Check your own instance rather than trusting any of us on that one.
The wider habit
A 2xx response and a surviving JSON key both feel like confirmation, and neither is. Jira accepts almost anything you send it and quietly uses the parts it recognises.
The automation rule API does the same thing with a whole object rather than one key. A rule created with a scope ARI and a trigger filter that disagree returns 201, and the trigger you get back is not the trigger you sent — the server rewrote it to agree with the scope, without an error, a warning, or a note in the response.
So when a flag does not appear to work, stop trying to prove it works and try to prove it is even declared. Send a typed parameter something it must reject. If nothing complains, you are on a dead end and you have your answer in one call — then go and check the permission, because that is the gate that will actually decide whether it does anything for you.
