Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Automating round robin assignment for different shifts in Jira Server Automation

I am using the Automation plugin for jira server in jira Service Management for this. I have three shifts of service desk workers, and I want to do round robin assignments for each shift. My requirements are thus: 


  • shift 1 is 8 AM-5 PM
  • shift 2 is 11AM-8 PM
  • shift 3 is 12AM - 9 AM
  • the project lead needs to be able to change people between shifts without contacting the admin (me). 

The problem is that between the hours of 11 AM and 5 PM, I have two different shifts working. I was intending to use roles to do the assignment, but you can't specify two roles in a round robin. 

What I tried next was setting an entity property on the project for Last Assignee, with a value of either 1 or 2 for whichever of the two overlapping shits was assigned, and then using if/else to switch up assignment, as follows:projectProp.png


Now, my notation could well be off (I also tried, but it looks like while Automation can set properties all day long, indicates that it can't actually read them, except for issue properties. Which aren't useful in this case, because I need to know what role for the assignee in the /last/ created ticket in order to set the next one. It would be much simpler if I could just specify two roles, otherwise I'll have to create yet another role for the overlap period, add everyone in both to it, and then it will show on all projects, even where it isn't relevant. 

Anyone have thoughts on this?




2 answers

0 votes

So @Rodney Nissen posed a question about this in the Innovalog "Stump The Expert Challenge", but for the life of me, I can't figure out how to use JMWE to do it. (Sorry Innovalog.)

The challenge is "Round-robin issues based on time zones" - sound familiar?

But he also recently posted "Give Me A Break", a tutorial on how to create a project/workflow + automation that will allow users to remove themselves from a Service Agent role when they are on vacation (and also bulk-assigning their tickets to whoever is covering for them).

Anyways, thinking about the challenge, I found your question again and am sure Automation is the way to go for this, but as to your last requirement, I think Rodney's tutorial kind of nails it.

Having a project/workflow that uses the Automation Web Requests to hit the JIRA API to add/remove users from the rotation groups would allow for "self-service" for the project lead.


And oooof. Now that I reread your original question, it doesn't even look like having the project lead be able to manage the groups was the issue. It was the whole double-shift thing. Whoops. Did you ever figure that out?

Rodney Nissen Community Leader Jan 13, 2021

To be fair, we did call that challenge a "mind-bender"

0 votes
Darryl Lee Community Leader Dec 03, 2020

Are you wrapping in curly braces?

It's a smart value, so you'll need to do: {{}} to check it.

Yes. This is what it looks like in the editor: 

log value.pngScreenshot 2020-12-03 152923.png


and I tried this in both the {{projectProperty.lastAssignee}} and above formats, with the same result. If the format is still again something different... well, that could very well be so.

Darryl Lee Community Leader Dec 03, 2020

OH! I forgot the quotes. For some bizarre and undocumented reason, you have to put Property names in quotes:

Try this: {{"lastAssignee"}}

I got this tip from @William Sheboy

Like # people like this

Yup, it looks like project properties can now be read from the automation rules.

Here's an unrelated tip if you try to organize your entity properties better (such as with a namespace organization): the key cannot always contain a period.  It definitely doesn't work for project entity properties, and I have seen some posts that it does work for issue entity properties.  Curious...  I submitted a defect for this to learn if this is just a documentation gap versus a defect.


Like Rabbit Stoddard likes this

Do you have to use the quotes when you set the property as well, on this screen? 


No, you just set the property with no quotes around the key.

If you are wondering if there is an issue even setting the property, you may also just do a quick check in a browser using the REST API to grab the values:


Like # people like this

I haven't got this working yet, but I am pretty sure it's something I'm doing wrong on my side. I was able to confirm that the property isn't actually getting set with the API call, so I'll start there.

@Rabbit Stoddard if you post your current rule maybe the community will see something to help.


Suggest an answer

Log in or Sign up to answer

Atlassian Community Events