Repeating a single automation on selection of users

[Jack_Valentine]

Hallo all,

I'm currently trying to make an automation which checks if a group of users has any issues in progress, and to email them individually if they do not.

I currently have half of this working, the "check if there are any issues in progress":

But I cannot get this to check a group, and then run individually per user.

I thought that something like advanced branching would help:

but no dice. 

The key to this rule is that it does not check whether the *group all together* has any issues in progress, but that each individual has something in progress. 

Anyone have any suggestions?

Help greatly appreciated!

[Bill Sheboy · Accepted solution]

Hi @Jack_Valentine 

That is an interesting use case...Three things I note in your rule to try:

1. Your advanced branch uses a smart value you name as {{Assignee}} and I recommend that you use a different value to avoid possible problems.  Perhaps {{varAssignee}}
2. Next, your lookup issues action's JQL inside of the of the branch is not using the branch variable.  Try adding that to the JQL to limit it to process each person, one by one: status = "in progress" AND assignee = {{varAssignee}}
3. When comparing the lookup issues size to 0, try to add a default to confirm it is numeric and not null.  To do that, please use: {{lookupIssues.size|0}}

Kind regards,
Bill

[Jack_Valentine]

Hey @Bill Sheboy ,

That's fantastic, thanks :) 

It's *mostly* working - I now have a separate issue in that the email component is sending an email per issue, rather than per assignee:

I would of thought that because the email was in the branch of "assignee", the mail would send just once, do you have any idea why this is triggering per issue? 

I tried reading over some of the other community posts I found but there weren't any I saw which were massively relevant. 

Thanks in advance! 

[Bill Sheboy]

Progress; well done!

I hypothesize that you have JQL in your scheduled trigger.  Correct?

If so, that is causing the looping around the branch, which then sends emails for each issue from the trigger. 

One solution is to remove the JQL from the trigger; your Lookup Issues JQL is accessing the issues you care about...and you are looking for the absence of information anyway, so the issues' details are not relevant.

[Jack_Valentine]

Hey @Bill Sheboy , 

I tried removing the JQL, but the automation then complains at me because it needs to have a JQL for a user condition:

Not exactly what I wanted, as I was hoping to run it each morning before the scrum - but if I change the trigger it doesn't complain, and I *think* it works.

I think other use cases of this could be things like "notify scrum master or PO when team member needs more issues assigning" or something similar.

If I could get it to run on a schedule that would be cool, but I'm going to play around with it a bit more with some different triggers - If you can think of a way around the JQL in scheduled not running on every issue/ not requiring a JQL search let me know, but I greatly appreciate all your help thus far!

[Bill Sheboy]

Hi, Jack.

You do not show what is in your advanced branch...and if that is already limiting the assignees to the same listed ones from your user condition, then the user condition can be removed (and so can the JQL from the scheduled trigger).  Correct?

Also, please consider if using a rule like this is a temporary solution or a long-term one.  When the PO has enough selected work ready and the team pulls work when they have capacity, there should be no need for the SM or PO to "assign" stuff to people.  Just my 2 cents.  :^)

Thanks,
Bill

[Jack_Valentine]

Hey @Bill Sheboy ,

Currently this is my advanced branch, as I was just testing it - but essentially I would like it run of membersOf("XX") group if that's doable. 

If I put the user condition in here, the scheduled trigger still requires a JQL

Thanks!

Jack 

[Bill Sheboy]

The rules and JQL basically only work with issues; there are some exceptions for rules but user groups is not one of them for branch/scheduled processing yet: https://codebarrel.atlassian.net/browse/AUT-708

And, you are looking for the absence of issues, not for issues, for members in the group.

A complicated work-around is to gather the group's user by calling the REST API from the rule with a web request, and then use those values to drive the advanced branch.  If you want to try that, here are some references and examples:

• https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828
• https://docs.atlassian.com/software/jira/docs/api/REST/1000.824.0/#api/2/group-getUsersFromGroup

[Jack_Valentine]

Thanks @Bill Sheboy !

I think I'm going to table this for the time being - we got very close but unfortunately I have other commitments I need to work on. I believe that you helped solve all my questions even if I wasn't able to get the rule working exactly, I greatly appreciate your help and time.