By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Improving processes through Jira automations

Manuel Rivero
February 29, 2024


Jira is a great tool for different teams to organize work and track progress on reported tasks. However, as projects start growing and teams become larger, it’s very common to find endless backlogs on development boards and performing maintenance on them can become tedious and time consuming. Fortunately, Jira provides us with a robust automation suite that can be used to assist with this process.

In this article, we will describe how we used Jira automations in one of our projects to assist the team with backlog management, and how it was used to organize our Customer Support board as well.

Configuring an automation

In Jira, Automations can be accessed by navigating to a board, clicking on Project Settings on the left hand side menu, and going to Automations.

These consist of three main components:

  • Triggers: define which action or situation will trigger the execution of the automation. Some examples are: When an issue is created, When a comment is added, Scheduled based on a Cron Expression, etc.

  • Conditions: allow filtering which issues will be taken into consideration or filtered out. For example, Specific issue types, Issues reported by a specific Jira User, etc. 
  • Actions: define the action to be applied to the issue, like Moving it to a different Sprint, Adding a Comment, Sending a Message to Slack, etc.

First use case: Backlog Cleanup

In order to help with board maintenance, on our main Development board, we created three static sprints to allow us to organize tasks by relevance in time:

  • Active Backlog
  • Inactive Backlog
  • To be Closed

The objective of having these sprints is defining a structure on which cards would progressively be moved to lower priority backlogs as they’re not updated or prioritized in time.

So the first thing we needed to do is to make sure that any card that is Created on the board was sent to the Active Backlog so it could be prioritized for upcoming sprints, and this is easily resolved by the following automation:

Rule 1: Move issues to Active Backlog

  • Trigger: When issue is created
  • Conditions: None
  • Actions: Edit Issue Field. A custom definition is required here, as Jira does not allow choosing specific Sprints on the dropdown, so the ID of the Active Backlog Sprint was pulled via API and configured on the Additional Fields area.

With this, every time a card is created on the development board, it will be sent to the Active Backlog sprint for prioritization. 

The next step is to define automation rules to move these cards to lower priority backlogs after some inactivity period. For these, we created two very similar rules:

Rule 2: Move cards in Active Backlog to Inactive Backlog after 90 days of inactivity

  • Trigger: this is an instance of a Scheduled Trigger, with a custom JQL query to pull only non-epic cards that belong to the Active Backlog sprint and haven’t been updated in the last 90 days.
  • Conditions: None, filtering is done at a Trigger level since it’s a Scheduled Trigger.
  • Actions: this rule has two actions:
  • Moving the card to the Inactive Backlog Sprint in the exact same way as shown in the first example
  • Adding a comment indicating the action that was taken, primarily so that the original owner / reporter of the card is notified of the action, and can move it back to the Active Backlog if necessary.

Rule 3: Move cards in Inactive Backlog to To be Closed after 60 days of inactivity

  • Trigger: Scheduled Trigger, with a custom JQL query to pull only non-epic cards that belong to the Inactive Backlog sprint and haven’t been updated in the last 60 days.
  • Conditions: None
  • Actions: this rule has two actions:
  • Moving the card to the To be Closed Sprint 
  • Adding a comment indicating the action that was taken

Rule 4: Closing cards on To be Closed after 30 days of inactivity

  • Trigger: Scheduled Trigger, with a custom JQL query to pull only non-epic cards that belong to the To be Closed sprint and haven’t been updated in the last 30 days.
  • Conditions: None
  • Actions: this rule has two actions:
  • Transitioning the issues to the Done
  • Adding a comment indicating the action that was taken

Since closed cards on future sprints are not visible on the backlog UI, this last action allows significantly reducing the clutter of lost and forgotten cards.

Use case 2: Customer Support Board Maintenance

Another use case on which automations are extremely helpful is to help manage Kanban-styled customer support boards. We have several of them in place to help with daily management tasks.

Rule 1: Handling approval of Hotfix Requests.

In this particular project, we defined "Hotfix Requests" as a special type of support card that often involves making small changes requested by Support analysts, be it fixing some typos on the UI, or changing the way something works, while not necessarily being related to any given User. We defined a system in which these need to be approved by at least 5 other Support Analysts before being worked on, to ensure that we don’t put out work for something that might not be a good idea and lead to a rollback later on. For this, new Hotfix Requests are created in a To be Approved state, and they have a multi-user field for Approved By that is updated by Support analysts when they review the card and agree with the change.

With these considerations in mind, there is this automation set in place to move these cards to the backlog after they are approved:

  • Trigger: Value changes for the Approved By field
  • Conditions: two conditions are set in place for this:
  • Issue needs to be in To Be Approved state
  • There is an Advanced Condition that validates that the Approved By field (which is translated to a comma-separated string on Jira's Smart Values) has at least 5 members, using the Split function
  • Action: Issue is moved to the Backlog, so that the Technical Support team can tackle it in order of priority

Rule 2:
Managing Cards waiting for response from the Customer Support team

Another issue state we manage in this board is Waiting for Answer, which corresponds to cards for which the engineering team requires more information from the Customer Support team/client. It was very common for these issues to spend entire weeks in this state, without any kind of response, specially in cases where the issue was resolved automatically, so we built a very simple automation ensure that these cards are closed after 5 days without activity:

  • Trigger: Scheduled with JQL query that pulls all issues on that state that haven’t been updated in the past 4 days.
  • Conditions: None
  • Actions: 
  • Add a comment to the card indicating that the card was automatically closed due to inactivity (primarily to notify the reporter in case they want to reopen it)
  • Transition the issue to the Done state

Additionally, in this context, we also have another very simple Rule that transitions the issues on Waiting for Answer back to the Backlog when a new comment is added, so that the engineering team can start working with the new information:

  • Trigger: a Comment is added to the card
  • Condition: card is on Waiting for Answer state
  • Action: transition the issue to the Backlog


As shown in this article, Jira Automations are a great tool to assist with the management of different types of boards. They are often very easy to configure, and they can significantly change the time invested in mundane but necessary maintenance tasks. The rules that have been shown are relatively simple and serve as an introduction to the system, if you’re interested in learning more, don’t hesitate to review the official documentation at Atlassian Support:

Interested in our services?
Please book a call now.