So, I can already hear you, readers. You’re saying, “Aren’t we supposed to have a part 2 to the Dragonslayer post where you modernize the instructions?” And you are correct. However, that turns out to be a more significant task than I first imagined. 

However, I want you to have something to read this week. That was when I had a request from a client this week. Upon reviewing the solution to the request, I felt it would be perfect for posting about this week.

Automation for JIRA

One question users always ask me is how they can automate actions in JIRA. For example, when they move a story into the sprint, how can they automatically have the subtasks moved too. And for the longest time, I didn’t have a useful answer.  

Sure, you can make it work in Scriptrunner, but the amount of work it would take would make it not worth it. Then I discovered Automation for JIRA. This one allows me to tailor automations to specific projects, and so so using no programming. 

So for this post, I thought I’d go into the request I was given and how I approached solving it using Automation for JIRA. Let us begin.

The Request

So, my first recommendation is to understand the request entirely. Figure out not only what the users are asking you to do but also why they are asking it in the first place. 

In this case, the client asked me if there was a way to automatically create sub-tasks on an issue based on what components are on the parent issue. That’s great, but that doesn’t solve the “why.” However, I was fortunate that the client already explained their thinking here.

It turns out that the client has the components in their project broken down by functional teams, and for each task, they want to add Components to the issue based on who has an active role in it. They then want to create a sub-task for each component so that the individual teams involved can track their work.

The reason for the requests tells me a good bit about the request that the initial ask did not. For example, Components may not only be added at issue creation but at any time during the Issue’s lifecycle. This fact comes into play soon. It also tells me that I need to be able to support any combination of components. This requirement can make things tricky, but I don’t think impossible.

Getting started

The Trigger

The first thing I think about when I start building an automation is, well, the starting point. What kicks it off. Let me explain. For every automation rule you have, you need some event to kick it off. Some marble that is falling to set off your Rube-Goldberg machine.

In Automation for JIRA, this is called the Trigger. There are a number of these available within the tool.

That is quite the list, no? While it may be something to go through, I think it’s a natural choice here. Remember when I mentioned that we discerned from the request that we would need this to happen at any point during the Issue’s active life cycle? That means we can rule out anything that doesn’t have to do with the Issue. We can also rule out anything that takes place during specific events of the lifecycle, such as a transition or creation.

Furthermore, we have a trigger that can focus specifically on when a field is changed.

So when we select this option, we are presented with several settings. Because we are focusing on the Components, we choose that for the field setting, and leave the “For” setting to it’d default “All issue operations.” Once done, we click “Save.”

Conditions

So, now we need to think about when we don’t want this rule to run. We can specify when an automation rule runs by using “Conditions.” Here is a view of what our rule looks like after saving the Trigger.

We know we only want this rule to run when the parent issue is active. So lets put a condition on here to check that the Resolution field is empty.

Having this immediately after the Trigger keeps it from executing when this condition isn’t true (in our example, when the Issue is resolved). There are many conditions available, and we can use a few of them here in a moment.

The “Component Block” – More Conditions and Actions

Now comes the tricky part. We need to be able to split off actions based on the components. We also need to check – per Component – that it’s appropriate sub-task doesn’t already exist. This requirement stumped me for a second until I settled on the “If/Else” block. Using this condition creates a situation where you can have actions run if the condition is true, but if it’s false, it won’t stop the entire chain from running.

Here we have the If block with two conditions. The first checks for a specific Component – in this case, “Ducks.” The second checks all sub-tasks to make sure we don’t already have the one we want. If any have the summary “Test Ducks,” this Trigger fails, and any actions we have on this branch don’t run.

What do I mean by branch? I mean this If block, once saved, creates a branch in our rule flow.

Here is where we will add our actions. In this case, we will want to create an issue within the current project with issue type “Sub-Task”. This will allow us to specify the responsible user, description, and most importantly summary. For this to work properly, you need to make sure you summary you are creating matches the check you have in the If Statement.

Click Save, and that’s the block done for this Component. Rinse and Repeat for each Component you desire to automate, and you should be good to go.

Branches

So, we didn’t end up using them for this request, but I still wanted to touch on Branches. We used the If/Else Block for some rudimentary branches, but what happens when you want to run an Automation Rule against all the Issue’s Sub-Tasks?

In this situation, you want to use a Branch rule. This rule allows you to execute a set of actions on issues based on their relation to the Issue that triggered the rule.

Something handy to keep in mind, but as I’ve stated, not always something you need.

And that’s it!

I am sorry for not having the second Dragonslayer post – but I do hope to have that available for next week. But this request struck me as an interesting problem and a great example of how to develop and use an Automation Rule. 

If you like the content you find here, don’t hesitate to sign up below to receive emails when I post new content. And you can also check me out on twitter at this link. But until next time, my name is Rodney, asking “Have you updated your JIRA Issue today?”