Intro
I’ve set up a lot of useful Jira Automations and selected the most universal ones — the kind that save time, reduce manual work, and fit projects of any size or complexity. Since there are quite a few, I’m breaking them down into several articles. The plan is to cover three categories: Order-bringing, Life-simplifying, and Monitoring. This first article focuses on automations that help keep things organised.
Of course, these automations aren’t “the only right way.” They reflect my experience and what works for us. Hopefully, they’ll give you ideas for your own workflows.
A few words about our project setup:
- Most features require both frontend and backend work, and they go live together. So we use custom sub-task types: Frontend and Backend.
- Ideal ticket lifecycle: Open → In Progress (“being worked on by developers”) → In Review → Resolved (“ready for testing”) → In Testing (“being tested by QA”) → Checked (“tested, waiting for the next release”) → Was Released (“deployed to users”) → Closed.
Visualised:
But reality, of course, makes its own adjustments 😉 😏:
- I use Labels to organise tasks on team boards.
- A Sub-task is a bug that has been found in a specific feature branch and will be fixed there.
- There are also many custom fields in the projects (you can read more in the official documentation).
Types of rules:
- Project rules – work inside one project.
- Global rules – affect all projects. Only global admins can create these.
How I describe each automation:
- What it does and why it helps.
- How it works – step-by-step with Jira Automation actions.
- How it looks – screenshots and Slack message variables.
Order-bringing
The main idea — more order, fewer tedious clicks. These automations juggle tasks on their own, some don’t even send notifications for the manager to check.
project-rule-01: Start Parent When Sub-task Starts
What it does:
When a sub-task is moved to "In Progress," it checks if there’s a parent task. If yes, it moves the parent to "In Progress" too and assigns the Bot.
Why? So you can stay focused on your sub-task while still showing managers that work has started.
How it works:
- Triggered when the task transitions to In Progress (Issue transitioned);
- Check that it has a Parent (New condition → Related issues condition);
- Select the Parent (Branch rule / related issues);
- Add two checks for it: 1) The task is in one of the desired statuses; 2) Its sub-tasks also meet the required conditions (JQL condition);
- Transition the parent task to the same status as the triggering task (Transition issue: Copy from trigger issue);
- Check who is assigned to the task (JQL condition);
- If no one is assigned, assign it to the Bot (Assign issue).
How it looks:
project-rule-02: All Sub-tasks Resolved? Move Parent
What it does:
Moves the parent to "Resolved" when all its sub-tasks are resolved.
Useful when multiple people are working on one feature. As soon as all sub-tasks are closed, the task moves to the testers’ queue.
How it works:
– Triggered when the task transitions to Resolved (Issue transitioned);
– Check that it has a Parent (Branch rule / related issues);
– For the Parent add two checks:
1) The task is in one of the desired statuses;
2) Its sub-tasks also meet the required conditions;
– Transition the Parent to Resolved.
How it looks:
project-rule-03: Task Moved from Another Project
What it does:
Catches tasks that were moved into current project. Sends a Slack alert so we can assign labels/components and make sure the task lands on the right board.
How it works:
– Triggered when an issue is moved to the current project (not created!) (Issue moved);
– Sends a notification to Slack (Send Slack message).
How it looks:
:wat: — the icon that will be shown in Slack;
<https://jira.yourdomain.com/browse/{{issue.key}}|{{issue.key}}> — the issue key as a clickable link;
{{issue.summary}} — the issue title;
{{issue.components.name}} — all components of the issue;
{{issue.reporter.key}} — the username of the person who reported the issue (interestingly, the Creator can specify someone else as the Reporter when creating the issue);
{{issue.reporter.displayName}} — the full name of the person who reported the issue.
project-rule-04: Remove Assignee if No Code Needed
What it does:
If the resolution is "Invalid", "Duplicate", "Obsolete", etc., it unassigns the task. Helps us count only real work in our stats.
How it works:
– Triggered when the issue transitions to Resolved (Issue transitioned);
– Check the JQL condition to ensure the resolution is one of the specified values, the issue has an assignee, and it is not a sub-task: resolution in (Invalid, Duplicate, Incomplete, Obsolete, "Won’t Do", "Won’t Fix", Rejected) (JQL condition);
– Edit the issue — in our case, we assign it to the Bot (Edit issue). This step can be left blank if needed;
– Send a Slack message stating that the issue has lost its assignee (Send Slack message).
How it looks:
project-rule-05: Close Sub-tasks When Parent is Released
What it does:
When the parent is set to the Was Released status, all sub-tasks sequentially transition through the statuses Was Released and Closed. This is used by release managers when a version has been successfully rolled out to users and the task can be closed.
It saves a lot of time on manual closures — if the task had many sub-tasks, it could take several minutes otherwise.
How it works:
– Triggered when the issue transitions to Was Released (Issue transitioned);
– For its sub-tasks, change the status to Was Released, and then to Closed (Branch rule / related issues).
How it looks:
Up Next
These “Order-bringing” automations help reduce chaos, enforce consistency and save time on routine project management. Even a few simple rules can make your workflows noticeably smoother.
In the next part, I’ll cover Life-simplifying automations — the ones that save clicks, reduce repetitive actions, and generally make your day a bit easier. Stay tuned!
Top comments (0)