I’m frequently asked how I approach requests for automation configurations in Jira.

I don’t have a definitive answer regarding when and how I automate Jira configurations, but I do have an approach. This approach has been very effective.

Frequently the context is someone on a team asking me: Can you automate Jira to update a related issue when I change this kind of issue?

My approach is to respond quickly with these three answers:

  • In a word “No” (not without an app)
  • In four words, “It can be scripted” (with an app)
  • In five words, “Let’s make sure we should”

I’ll talk about each of these answers to show you my approach to automation in Jira.

In a word “no”

First, let’s recall that Jira doesn’t provide very much built-in functionality enabling one issue to have its information updated based on what’s happening in other issues.

There is no built-in way to have Jira update an issue because an action was taken on a different issue. It’s not ‘built-in’ into Jira, full stop.

In four words, “it can be scripted”

It’s usually Jira Software boards that prompt teams to ask for this automation. The most common request I hear is: If I’m using a board and I transition a sub-task out of the done column, can Jira reopen a sub-task on its parent?

When you are using a board, transitioning the last sub-task of another issue will prompt you to close the parent task. However, the opposite interaction never occurs. Jira doesn’t ask the user if they want to transition the parent back to an unresolved status.

This is the most common example, though there are many many more.

There are lots of scripting and automation apps available that you can use to do things like this.

I help a large number of teams with their Jira configurations. I don’t assume the request for automation is something I should do in every case. There’s the obvious concern that as soon as I configure automation, we have to maintain it. But this isn’t really why I pause. I pause because I frequently get the request out of context of the problem that we’re trying to solve.

Instead of just doing it, I will engage with the team requesting the change to understand how configuring the tool this way makes the team more effective.

Why don’t you just automate it? Why do you have to ask so many questions?

When the team asks why we need to discuss it, I’ll tell them it’s due diligence we do every time automation is requested. The more we automate Jira’s ability to update related issues, the more we codify a process between issues.

If we automate too casually, we will make Jira too strict and brittle. In a large instance this becomes a significant problem very quickly. I’ll remind the client that if we don’t discuss it and understand what outcome we’re solving for, when they change their process they may have to “undo” what the automation is now doing. Implementing poorly understood automation always creates more work for the team requesting the automation.

Let’s say the best place to implement the automation is on a workflow (it’s an obvious place to do automation). Let’s use a requirement like this: As a team member, when a story is moved from <this status> to <that status>, any related issues should be updated from <this status>  to <that status>.

Implementing a script like this effectively binds functionality between two workflows.

It also binds the facts between issues to each other. There can be many related issues. There is always a criteria that we need so we know which of the related issues should be affected.

When you later get a request to change one of the two workflows, or any other facts about the two issues, you will need to address the impact of the change on the other bound configuration to preserves the automation. If you don’t understand why the automation was implemented in terms of how it makes the team more effective, you won’t have any idea if you should disable the automation in the face of this new change or if you should update the automation with new requirements.

When you script it, iterate to get the least brittle automation and document the change.

It can be scripted. There’s nothing wrong with automation. Here’s what else you have to do when automation is appropriate. This will help you do it well, produce a good outcome and your future self will thank you for it.

Experiment in a staging environment with the same configurations, and ideally the same issue data, that the team is using in production. If you are on Jira Cloud, copy the configurations you need to implement the automation into a “testing” Jira project that doesn’t affect the “real project”.

Iterate against the requirements so that you have at least one way the automation meets the requirements. Stop and think: Ok can I make this change more maintainable? If I change any of the related workflows or criteria for the automation, can I tune this so it will fail gracefully? Show it to other Jira administrators for feedback. If you are the only Jira administrator in your company, post your solution to the Atlassian community.

Once you have something that works and is maintainable, you are ready to show it to the team that made the request. You need to do this before you finish, so don’t just implement it in their real project yet. You will always learn something when the people you did the work for try out the automation before you finish. If you just implement it, you are losing all opportunity to have your customer help you improve your solution.

Once the automation works, is maintainable, and your customer agrees it’s effective, you can finish the job. Help out your future self and your other Jira Admins by documenting the change and sharing that documentation. Share this documentation (even if it’s a bit technical) with the team that requested the change as they were active participants in the what and why.

That sounds complicated? Why doesn’t Atlassian make this kind of automation a standard feature?

Actually, there are more than a couple of scenarios where automations that have clear and obvious benefits to all Atlassian customers are built into Jira.

Atlassian deliberately avoids building in too much automation for many reasons, but the root reason is because Atlassian has always gone to great lengths to keep Jira a bias towards being as methodology neutral as possible.

Scrum board users will notice methodological assumptions in their boards, backlogs and reports. Jira Service Desk users, in particular those using the ITSM/ITIL certified configurations, will notice quite a lot of methodological assumptions in their configurations. But those are two examples of methodologies that are both well understood and very popular. Even so, Jira remains very configurable. You can adapt how your team implements a methodology and so, in the vast majority of cases, Jira can be configured against your team’s specific implementation of that methodology.

In order to preserve this bias we assume informed responsible team members are doing things like:

  • Creating issues in the correct team’s project
  • Reviewing new work coming to the team to determine if the new work is appropriate and valuable in the context of the organization’s mission and the team’s charter
  • Keeping everyone up to date on our progress by transitioning those issues through a workflow
  • Marking work complete when the team is done working on them
  • Making sure that as we work on a team, individuals can properly assign and reassign their work to collaboratively complete work

Atlassian makes a sure user interfaces are fast and easy to use. We have keyboard shortcuts, bulk actions, dashboards, reports and a powerful workflow enforcement engine to keep these informed responsible team members focused on their work rather than spending large amounts of time in Jira.

In five words, let’s make sure we should?

We never want to add to a process without measuring if that change produces a valuable outcome. With regards to automation, I want to leave you with this: If your team members aren’t actively creating, updating, and completing issues in the context of your teams methodology, does automating really help the team produce a better outcome for the organization?

This is a subtle question, but it’s worth bringing up because it’s not just the automation that we’re maintaining. When I ask the team this question, I usually frame it in the context of their request. But broadly what I’m asking is: If the team has consensus and is committed to completing an issue, why didn’t they ask to reduce the number of issues required to complete the work? Why didn’t they ask to remove the number of data entry steps required to complete the work?

Even with automation, they still need to use Jira to track, collaborate and complete work. Asking them if the configuration should be simplified keeps you and the team focused on how Jira helps them produce quality work.

Teams that balance their desire to demonstrate commitments, priorities, blockers and produce reports often request automation because they have too many issues to track. Asking them to consider how we can reduce the number of issues they need to update is often a very revealing conversation, especially as it relates to improving outcomes. In order to keep Jira’s configurations nimble and easy to use, it’s in each team’s own best interest to keep their Jira issues “as simple as possible, but no simpler”.