So, today we have a real treat. I was recently contacted by long time reader Demitris Danampasis, who had a bit of a challenge for me. I thought it was interesting enough that I went ahead and forwarded it to my colleagues to have the first crack at, but I haven’t even looked at their answers for the sake of fairness. I want to see if I can find a solution myself first!

So here’s the challenge. You are working on a Jira Service Management instance with access to Automation for Jira. Given our proximity to the holidays, you do not want to install another Marketplace App onto your Jira instance. However, you are free to create any additional Projects, issue types, or workflows you need to make this work.

Your Service Desk Agents want to go on leave. While on leave, you need to take them out of rotation not to get issues assigned to them while they are out of the office. Additionally, any issues currently assigned to them need to be reassigned to an appropriate person. I’m excited to see what can be done here, so let’s dig into this challenge.

Step One: Break down the challenge into individual parts.

The way I see it, there are two main requirements for this challenge. First, and probably the easiest part, you must reassign all existing issues to the person providing cover during the leave. This task should be relatively straightforward.

The second part is where things get tricky. It’s fine and dandy that all their existing tasks are taken over, but that only helps so far. They’d still have new tickets being assigned to them, and considering even I don’t care to log onto Jira while on vacation, I doubt users will be getting help. The second and most challenging part of this challenge will be to take them out of the rotation. Given I haven’t even looked at the API for this, that would likely be my first bet – see if I can make an API call to update either the Agent permissions while they are out. If this won’t work, I’m hoping there’s a more direct API call to do what I want. I’m not sure if either is possible, but that’s my best guess right now.

We then need “something” to trigger both of these actions. For this, I imagine a custom issue type, “Leave Request,” which will have a workflow that triggers both entering and leaving the “Out of Office” state. This set up will give us apparent triggers for the Automation, which is always helpful.

Step 2: Issue type, Custom Field, and Workflow

First, as I see it, we’ll need to set up a custom field to hold who will receive the open issues once the Agent goes on leave. This task is easy enough – create a User Picker, name it “Reassign existing tickets to,” and add it to the appropriate screens.  

Now let’s set up our issuetype and workflow. Here, I created an issuetype called “Leave” and gave it the following workflow.  

I didn’t see the need to complicate it, but I did feel it needed some oversight. Given that, the first status “Requested.” Here I think that any Project Admin should move it into “Approved,” so I set up the appropriate conditions to only allow him to see the transition. As part of the approval step, the manager will also set that custom field “Reassign existing tickets to,” so I set up a pop-up for the transition to capture that field. For the Automation to come the field must be set, so you should set it out now.

I also set all of the three “active” statuses to transition to the closed state, each with an appropriate Transition name and resolution.

Everything else here is a pretty standard affair, with all the magic happening in Automation for Jira. So let’s hop over there and take a look.

Step 3: Agent goes on leave

<picture of Automation>

So as I said, the trigger will be easy enough. Just set it for Issue Transition, and set the From field to be “Approved” and the To field to be “On Leave.”  

Then I set up a branch and set it to use JQL, with the following query:

Project = {{issue.project}} and assignee = {{issue.reporter}} and resolution is empty 

I uncheck the “Only include issues that have changed since the last time this rule executed,” as that will cause problems with this use case. Then, as an added precaution, I set the “Rule restricted to projects” field to be the current project I’m interested in. 

Under the branch, I have each issue set the assignee to the value in “Reassign existing tickets to” – hence why I needed it.

Finally, after the branch completes setup the Automation to make a web-request to Jira’s REST API. Honestly, this item was the trickiest part. This API will remove the Agent from the Project Role for your agents, effectively taking them out of the rotation.

For the “Webhook URL,” I set the value to:

<Jira URL>/rest/api/latest/project/<Project Key>/role/<id for project role in your instance>?user={{issue.reporter}}

You must get the internal Jira ID for the project role from Jira. My favorite way to do this is to find that Project Role in the Admin area, then hover over the “View Usage” link. On the URL preview at the bottom of your browser, the Project Role ID will be at the end. 

I used the Header for Authorization (Thank you, API Token!)

The HTTP method was DELETE, and the webhook body was empty.

And that’s it for the Agent going on leave.

Step 4: Agents return

The trigger is nearly identical; we are just going from “On Leave” to “Closed.” Then we have another webhook to call the rest API to add the Agent back into rotation. 

The “Webhook URL” will be: 

<Jira URL>/rest/api/latest/project/<Project Key>/role/<id for project role in your instance>

Authorization Header will still be the same as the previous Rule.

Your HTTP Method this time will be POST, with a Custom webhook body:

{ “user”: [“{{issue.reporter}}”]}

And there you go, the Agent will be added back into rotation upon return!

So what did you think?

Honestly, I am still a bit surprised Jira has nothing built in to account because people need a break sometimes. However, I think this method will allow people to automate going to and from vacation rather effectively without modifying the Project Roles every time. 

Don’t forget about the “Stump the Expert” challenge ongoing with Innovalog. This event has been super important to me since it was first proposed, so you’re going to have to put up with me pushing it for the next month-plus. But seriously, a great Charity gets much-needed support, you get a chance to win a fantastic prize, and everyone benefits from your brilliance as a Jira Admin. What’s not to love?

I do intend to publish through this holiday season. Next week we’ll be reviewing our Jira Admin New Year’s Resolutions from last year, see how they held up, and select some new ones. So if you don’t want to miss a new article, go down below and subscribe to receive blog posts directly to your inbox. Alternatively, you can check us out on Facebook, LinkedIn, Instagram, and even Twitter. There I have news, interesting thoughts, and new posts published regularly. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”