How to disable Jira update notifications when Automation rules populate custom fields?

[Pavol Harvanka]

My team is annoyed by many jira update notifications they get when Automation for Jira populates/updates custom fields.

As a scrum master, I have setup various custom fields to keep track of who or when a certain action was initiated within our development process. 

For example: who added an issue to the sprint, when did this happen, who transitioned an issue to a certain status, ...

Developers are actively using jira notifications to help them keep track of relevant changes in watched/owned issues and I see now that these updates initiated by my Automation rules are spamming them and thereby decreasing the information value of jira update notifications.

So how can I disable Jira notifications when certain Automation rule is executed?

I have searched extensively and one way would be to use rest api to temporarily switch to a different notification scheme - however currently apparently only visible fields can be modified via rest api from Automation for Jira.

Any thoughts or any plans to implement this feature?

[Pavol Harvanka · Accepted solution]

My colleague found a solution that has been apparently available since 2019. Unfortunately I did not find this forum post in my attempts, when I spent many hours searching for a solution.

Here it is and it seems to work (including the tip for adding a dummy "Edit issue fields" component):
https://community.atlassian.com/t5/Jira-questions/Disable-emails-from-Automation-for-JIRA/qaq-p/1253405

Quite frankly, I am disappointed by the developers of Jira Automation. I attended 2 webcasts last year and asked for a solution for my problem via chat during the event. Answer regarding any plans for future functionality for disabling jira notification was negative.

I really tried hard and during the many searches within the community forum and via google I didn't notice any hints pointing to documentation regarding this function.

This forum turned out to be a lot less useful than I expected.

Hope that I can help others by sharing this old solution.

[David Aguilera]

Thank you so much for tying up this loose end by giving us the solution you found and not leaving us hanging. 

The fact is that Jira documentation is trash since they change and move things all of the time. Finding up to date information is a scavenger hunt of epic proportions. 

Welcome to the fecal show that is Atlassian.

[David Aguilera]

@Pavol Harvanka actually, looking at the answer you linked I don't see it being solved? I want a way to turn off the in Jira notifications from Automation for Jira without having to turn off Global notification settings for everyone - like if a real person comments or updates a ticket we still want those notifications - just don't want them when Automation for Jira does something.

[Pavol Harvanka]

@David Aguilera 

My main issue was with Jira Automation rules using "Edit Issue" action.

I asked about a way to selectively disable such notifications - this can be done as described in the provided link.

Unfortunately my previous statement regarding adding a dummy "Edit issue fields" component to disable notifications for rules using actions like "Transition / Assign issue" was not correct. After further testing I saw that it only works for "Edit issue" action where the relevant check box is located.

So I am still interested in some conceptual way to handle Automation for Jira notifications within Jira.

However knowing at least about this option really decreased the noise and Jira notifications via email became again much more useful.

[Stephen Solomon]

Argh. This is still painful and really needs a global setting. I have automation that fills in data based on role and 50+ roles I have to put in different data for. That box hidden under "more options" is checked by default, and it has to be unticked 50+ times...

But thank you for finding this. I was looking for the setting in customer notification settings. Because it's a customer notification.

[Tony Bathich]

Thanks Pavol for sharing! That's what i was looking for...

[Tony Bathich]

btw, Atlassian should differentiate between Email Notifications and Jira App Notifications.

[AlexV]

It's too bad you didn't get an answer, because your question gave me an idea for a workaround.

Copy Default notifications policy, attach it to your project, and delete all of the rules that annoy people.

Once you get in there, it's actually a lot of noise causing settings.

The other thing you can do if you're on Slack, is Delete ALL of the rules, create a Slack channel and put Jira bot for your project there.

[Joel Bradley]

This is what I did. After removing about 80% of the notifications my team finds them useful. Before there were just a way too many. 

[John Conneely]

if you would like Jira notifications to be stopped as well as emails, you should vote for this here: https://jira.atlassian.com/browse/JSWCLOUD-22681

[AlexV]

There is all this stuff in there:

From the list below, you Only need "Issue Commented"

Maybe need: "Issue Created", "Issue Comment Edited" and "Issue deleted" for creator.

Full list that spams:

Issue Created (System)
Issue Updated (System)
Issue Assigned (System)
Issue Resolved (System)
Issue Closed (System)
Issue Commented (System)
Issue Comment Edited (System)
Issue Comment Deleted (System)
Issue Reopened (System)
Issue Deleted (System)
Issue Moved (System)
Work Logged On Issue (System)
Work Started On Issue (System)
Work Stopped On Issue (System)
Issue Worklog Updated (System)
Issue Worklog Deleted (System)
Generic Event (System)

[Pavol Harvanka]

@AlexV 
Thanks for the answer.

Unfortunately your assumption regarding what sort of notifications are needed is not quite correct for our team.

As I mentioned in my initial post, the developers are used to get update notifications.

If the fixversion changes for some reason, but no comment regarding this action is entered, then "issue updated" notification may be useful.

If there were an update notification about only system fields and not about user created fields, that could maybe work. But as far as I know, that is not the case.

[AlexV]

Have you asked the dev teams what they actually want? The way I came to our list, is by asking a team of ~15 people for what they cared about and actually read. :)

Most of the people wanted less stuff, one particular delevoper wanted more, so we found middle ground that worked for everyone.