Intro
I’ve set a bunch of handy Jira automations. The kind that save time, cut down manual work, and fit projects of any size. Since there are quite a few, I’ve split them into three categories: Order-bringing, Life-simplifying and Monitoring. Each category gets its own article to keep things clean and easy to follow.
This second part is all about the Life-simplifying stuff. Automations that help you stop doing the same boring actions every day and finally get rid of extra clicks.
If you missed the first part (focused on keeping things organised), you can check it out here. That article also includes a quick overview of how our project is set up, which helps explain why I use certain fields or even need some of these automations at all.
Life-simplifying
project-rule-06: Assign Tester When Testing Starts
What it does:
Assigns the person who moved the task to "In Testing" status as the tester.
How it works:
– triggered when the issue transitions to In Testing (Issue transitioned);
– check that no tester is assigned (JQL condition);
– edit the issue to update the custom field Testers by adding the trigger user (Edit issue);
– add all testers as watchers (Manage watchers).
How it looks:
project-rule-07: Create Two Profiled Sub-tasks Backend+Frontend
What it does:
Triggered manually from the menu, it creates two sub-tasks of types Backend and Frontend. Historically, we start with backend work and move on to frontend once the backend is in review. To make this flow easier to track, the frontend task is blocked by the backend one and moves to Waiting status, while the parent issue gets “(parent)” added to its summary.
How it works:
– triggered manually via the More menu from a project issue (Manual trigger);
– create a Backend sub-task with the required description and parameters (Create issue);
– create a Frontend sub-task with the required description and parameters (Create issue);
– transition the most recently created issue to Waiting (Branch rule / related issues);
– navigate over linked issues by type (Branch rule / related issues);
– filter for the Backend task (JQL condition);
– set it as a blocker for the most recently created issue (Link issues).
How it looks:
project-rule-08: Unblock Waiting Sub-task
What it does:
When an issue transitions to In Review, Resolved, Checked or Closed, it checks for any blocked issues of type Frontend or Backend. If such issues exist, it transitions them from Waiting to Open.
This simplifies tracking readiness when different developers (e.g. frontend and backend) are working on related tasks.
There is also a separate automation that sends daily Slack notifications about tasks that are ready to be picked up.
How it works:
– triggered when an issue transitions to In Review, Resolved, Checked or Closed (Issue transitioned);
– filters for specific issue types only (JQL condition);
– checks blockers in Linked issues (Branch rule / related issues);
– verifies their status and project (JQL condition);
– transitions them to Open (Transition issue).
How it looks:
project-rule-09: Backend is Ready? Notify Frontend
What it does:
Once a day, it checks all issues of type Frontend and sends Slack notifications if the blocking Backend task is ready or nearly ready, signalling that frontend implementation can begin.
It works effectively in combination with project-rule-07 (where one specialised task is blocked by another) and project-rule-08 (which transitions unblocked tasks to Open).
How it works:
– runs daily on a schedule to check for issues of type Frontend with status Open (Scheduled);
– filters their blockers (Branch rule / related issues);
– checks if the blocker’s status is In Review, Resolved, Checked, or Closed (JQL condition);
– Sends a list of such issues to Slack (Send Slack message).
How it looks:
Some details:
:js: — the icon that will be shown in Slack;
{{issue.priority.name}} — the issue’s priority;
<https://jira.yourdomain.com/browse/{{issue.key}}|{{issue.key}}> — the issue key with a link;
{{issue.summary}} — the issue summary/title;
{{issue.labels}} — all labels;
{{issue.components.name}} — all components;
@{{issue.assignee.name}} — if usernames in Jira and Slack match, this will tag the assignee;
{{issue.customfield_11406}} — a custom field indicating the quarter when the work is planned.
project-rule-10: No Manual Testing Needed
What it does:
When an issue transitions to Resolved (="Ready to test"), it checks for the presence of a specific component. If the component is present, the issue is immediately moved to Checked (="Ready for Release"), and the Bot is assigned as the tester (after all, we want to track how many of these cases slipped through over the year, right?).
This helps small fixes that don't require manual testing to move quickly through the FastLine to release.
How it works:
– triggered when the issue transitions to Resolved (Issue transitioned);
– check for the required component or label (JQL condition);
– assign the Bot as the responsible tester (Edit issue);
– write an automatic release note from the issue summary (Edit issue);
– transition the issue to Checked (Transition issue);
– notify release managers in Slack so they can mentally prepare and include the task in the next release (Send Slack message).
How it looks:
Some details:
:deploy: — the icon that will be shown in Slack;
<https://jira.yourdomain.com/browse/{{issue.key}}|{{issue.key}}> — the issue key with a clickable link;
{{issue.summary}} — the issue summary (title).
project-rule-11: New Bug Report
What it does:
Notifies on-duty testers in the appropriate Slack channel about a new bug report submitted by the support team in a dedicated Jira project created specifically for such reports.
How it works:
– Triggered when an issue is created (Issue created);
– Check the issue type (JQL condition);
– Send a Slack notification (Send Slack message).
How it looks:
Some details:
:bug: New Bug-report <https://jira.servers.im/browse/{{issue.key}}|{{issue.key}}> *{{issue.summary}}*
Components: *{{issue.components.name}}*
Project: *{{issue.customfield_11405}}*
Priority: *{{issue.priority.name}}*
Reporter: *{{issue.reporter.key}}*, {{issue.reporter.displayName}}
Up Next
Less clicking, more doing. These Life-simplifying automations cover everyday pain points like assigning the right people, keeping frontend in sync with backend, and surfacing tasks when they’re ready to go. They keep teams in motion without constant check-ins or manual status updates.
In the next (and final) part, I’ll cover Monitoring automations. The ones that help you stay informed, spot bottlenecks early, and keep your project under control without micromanagement. Stay tuned!
Top comments (0)