Add a status type in a workflow that sent notifications to specific groups of jira users

[Snorre Strand Asbjørnsen]

Our team have issues that needs approval from one or multiple groups of Jira users before issue can be moved to "Done". 

I want to add a status type into a workflow so when an issue is moved into this status type one or multiple groups of Jira users will receive a notification through email that will direct them to the issue for them to review and approve or reject issue solution/progress. I would assume utilizing a field of some sort for the issue to identify groups of individuals that would receive said notification.

Our main goal is to create a single repository of the approval process tied to the related issues.

However, this is my theory on how to best approach this, but I am open to any ideas and hope of clarity on best approach to resolve this. Another concern I am not sure on how to resolve is if I can create some sort of structure within the issue to make the approval process when inside of a issue more structured. As of now approval confirmation would most likely be tied to the comment section, but not sure if that is an optimal solution.

[Lisa Forstberg]

Hi @Snorre Strand Asbjørnsen ,

I can see multiple solutions for this, but this is probably the simplest:

• Add the status before "Done", lets say "In Review"
• Add a transition screen in the transition to status "In Review". Add group picker fields or user picker fields where the user can pick "reviewers" to choose who to send the email to.
• Add an automation that fires on the transition to status "In Review". Use the action "send email" in which you can send it to a predefined group, a user picker field, a group picker field from the issue.

The tricky part is the "one or multiple groups of Jira users". Will the user performing the transition to status "In review" actively choose  group/s or a user? Regular users cannot see who is in a group so they are kind of blind of who they are contacting. Also group picker fields cannot yet be limited to a subset of groups. The user will see all groups that exists in the site. (feature request for that)

If the user don't need to choose a group, then skip a user/group picker field in the transition and let the automation just send it to the predefined group created for this purpose. 

Watch out for the consequence of drenching too many users with email notification about the need to review an issue.

Other solutions

Is there any metadata on the issue that could help us choose a relevant reviewer? Product, function area, component, Team? 

Are you using Assets at all? (I see you are on Premium). Assets could help with holding Users related to certain object (Like product, application, function, Team) that are stored on the issue, so the automation can go and fetch the appropriate group of reviewers by this object dynamically. Also easier to maintain to have a central repository of reviewers for different areas of the business. 

All the best

Lisa

[Snorre Strand Asbjørnsen]

Hey, thank you for the insight and quick response.

If I wanted to skip users selection groups/users and letting the automation send it to predefined groups. Can I predefined groups on specific issues or will it be predefine for groups in a project in its entirety? If predefining groups on specific issues works how would I approach setting these predefined groups on a singular issue. Would this be a type of field I have to configure?

[Lisa Forstberg]

Hi!

You have a couple of options on how to build the automation

1. Let the logic sit in the automation only.

Add branches to your automation. The whole automation is triggered for a large set of issues, then one branch per reviewer group in the automation for the subset of the issues (add branch and add if issue field conditions).

2. Have the automation set the group picker field

It can, however, be very useful that the automation is updating a group picker custom field on the issue. Add branches to set the correct group in the group picker field. Then round off the whole automation with just one action: send email to whatever group has been added to the issue in the group picker custom field.

I think I am in favour of option 2 as many reviesers would prefer looking at a Jira filter /dashbord in Jira instead of sifting through email notifications. Also some emails get lost... For a reviewer they would be interested to see "get me all issues in status In review where reviewer group field = group-name-ABC".

Of course the groups needs to be created and maintained by Jira admins (as people join, move or leave). To be honest, this tend to be the biggest challenge in these kind of cases. People move around and Jira admins often don't get the message in time to  update the group memberships. The Assets solution mentioned in the first answer can make this a bit more transparent. 

br

Lisa

[Snorre Strand Asbjørnsen]

Thank you again for more in depth aid.

I was looking into Assets, and as I understand it seems to a part of Jira Service Management?

Currently that product is not a part of our product package. However, it seems to be free for up to 3 users. Does this mean with the free version I could Assets and integrate it into Jira without any additional costs?

[Lisa Forstberg]

True, Assets is bundled Jira service management but it is not shipped with the Free or Standard plan so you need to pay for the Premium Plan to get it

Check out the pricing here: https://www.atlassian.com/software/jira/service-management/pricing

Regards

Lisa