Jira automation - messing up assignees

[Boleslaw Nowak]

Hey everyone, we've recently run into issue with our weekly automation which assigns weekly duties within the team. 

So we have a setup in which there are 4 tasks created each week as a procedure to perform. And the setup was to assign those 4 tasks in a round robin - to the same person, so week1 - person A takes care of all 4, week 2 - person B takes care of all 4, week 3 - person C takes care of all 4  and so on.

And this automation was working well, for almost a year now, no issues at all.

But since 2 weeks it went "crazy" and it started to assign those tasks to different assignees like:

- Task 1 - person A

- Task 2 - person A 

- Task 3 - person B 

- Task 4 - person C 

which is fairly annoying, feels like it went totally out of sync with the round-robin assignment.

Any idea what could be done to fix it? Maybe some adaptation to the automation rule should be done?

[Bill Sheboy]

Hi @Boleslaw Nowak 

If that is the rule you have been using for a year, I am quite surprised it worked as you describe.  In my opinion...The explanation of round-robin assignment is a bit vague, and seems to imply the "round-robin" applies to the scope of the rule, and nothing else: https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Assign-issue  And so I would expect it has been a coincidence of timing that it did not assign the issues to different people within that same branch.

How to fix this...I do not believe that is easily possible with an automation rule...

First, one complicated way to do this is using a known starting date, pick the date difference to {{now}}, use math to find if this is a 1st, 2nd, or 3rd week, and select the user based upon that result, from a list of users.

Second, would be to create three rules with 3 different schedules, assigning to a specific person.

Third, a work-around would be to assign just the first issue using balanced workload instead of a rotation, save that assigned user in a created variable, and then branch to set all other assignees to match.

Kind regards,
Bill

[Yvan Martin]

Hi @Boleslaw Nowak

Developer from Automation here.

I'm not aware of any particular change we've made recently that would result in a regression here, the nature of branching within a rule execution like the one you've showed does have some parallel execution nature to it. Although they are using the same datastore for incrementing the count, it may be possible for there to be some overlay based on timing. 

If you would like us to have a look at your particular instance further to see if we can spot something specific to your instance here, then you could try getting touch with our support channel:  https://support.atlassian.com/

Cheers.

[Boleslaw Nowak]

Thans for the answer @Yvan Martin in the end we've went with a route of assigning the first ticket to a person by round robin, and then create the other 3 without an assignee to avoid the issue of having numerous assignees on those - and then add assignees to those 3 tickets manually. 

Not perfect as it involves manual work in the end, but still less time consuming than trying to solve this problem, from what I see within this question it's not an easy fix that I was hoping for ;). 

[Clark Everson]

Hi @Boleslaw Nowak 

I may suggest doing a branch rule for each one? see if that works

Best,
Clark

[Boleslaw Nowak]

You're suggesting to create a branch rule for every single of those tickets within this automation?