Round-robin auto-assign but exclude epic assignee

[Ryan Taylor]

Hey there. I'm looking to set up automation to round-robin auto-assign an issue that contains "tire kick" in the summary and transitions to "IN QA" status. That's pretty simple to do, but I want to dynamically exclude the owners of the feature that are defined on the issue's epic in custom fields—"Android assignee" and "API assignee". Is there a way that I can exclude these 1-2 users from the list before doing the round-robin assignment?

This is what my current automation is a bit hacky and doesn't quite work. I don't love that it relies on three separate round robin assignment actions.

[Bill Sheboy · Accepted solution]

Hi @Ryan Taylor 

Short answer: I do not believe that is possible with the built-in features of automation rule, round-robin assignment.

My understanding is round-robin assignment relies upon a stable user list, and the last-selected-user information stored somewhere with the rule data, relative to the last time the rule was updated and executed.

Putting that all together, your scenario would probably not work because the user list is dynamic.  There is no built-in "retry until I find someone" for a dynamic list with round-robin assignment.  When excluding only one user, the technique of assign / re-fetch / condition test / assign-again works.  But, with multiple user exclusions you could end up in an endless loop.  This is why a recursive rule pattern (using an Incoming Webhook Trigger) will not solve this.

I recall an older question where someone tried to solve this with User Groups:

• Before the rule is built: create a User Group with the default set of people
• When the rule triggers
  • Use the REST API endpoints with Send Web Request to dynamically change the group members...remembering to include everyone else in a consistent order
  • Use the group in assignment with round-robin
• As groups can change outside of rules, I hypothesize the rule engine correctly uses its stored, round-robin data to skip over missing items in the group

Please note well: I have not tried that workaround in years, so please test it accordingly.  The latency time for updating group members could prevent this from working.

Another option: investigate the Atlassian Marketplace for apps supporting complicated assignment scenarios.

Kind regards,
Bill

[Ryan Taylor]

Hey Bill,

Appreciate the reply. I agree that this seems to be a limitation of the round robin assignment action. The best workaround I can think of at the moment is to move the task out of "IN QA" and back into "IN QA" if the task happens to get auto-assigned to one of the owners of the epic/feature. This means that when this happens, the person that was skipped won't get chosen again for awhile, but it's the only option I can think of for now.

Cheers

[Bill Sheboy]

Thanks for that update, @Ryan Taylor 

Please note that by moving out of, and back into, the status "IN QA", this may impact any measures you use such as time-in-status or rework-looping.  Please check with your team to confirm how this impacts any measures.  Thanks!