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!
That is an interesting use case...Three things I note in your rule to try:
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!
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.
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!
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. :^)
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:
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.
Hi everyone! Are you interested in beta testing Atlassian University’s newest (unreleased!) training course? We’re looking for 15-20 volunteers to test our newest training course, Basic reporting...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events