DEV Community: Ekaterina Vikulova

Let JIRA Do the Work: Monitoring (Part 3)

Ekaterina Vikulova — Wed, 09 Jul 2025 14:36:49 +0000

Intro

I’ve cooked up a bunch of time-saving Jira automations: the kind that save time, cut down manual work and fit projects of any size. To keep things clear, I’ve split them into three categories: Order-bringing, Life-simplifying, and Monitoring, with each getting its own article.

The first part was all about structure: status transitions, clean closures, and keeping your backlog tidy. It also includes a quick overview of how our project is set up, which helps explain why I use certain fields.

The second part focused on everyday relief: assigning the right people, syncing frontend and backend, unblock waiting tasks and removing extra clicks from your daily routine.

Now, in this final part, it’s time for Monitoring automations. The ones that help you stay informed, spot bottlenecks early, and keep your project under control without micromanaging.

Monitoring

These rules focus solely on sending alerts and do not make any changes to the issues.

project-rule-12: Send Release Note to Slack

What it does:
When an issue is transitioned to Closed, it checks the issue type and whether the Fix Version field is filled in. If a version is specified, it sends a message to a dedicated Slack channel with the release number and the release note.

How it works:

– Triggered when the issue transitions to Closed (Issue transitioned);
– Check the issue type to include only parent tasks and avoid spamming (JQL condition);
– Send a Slack notification (Send Slack message).

How it looks:

Some details:

https://jira.yourdomain.com/browse/{{issue.key}}|{{issue.key}} – the issue key with a clickable link;
{{issue.customfield_10700}} – a custom field containing the release note written by the QA Engineer responsible for verifying the feature;
https://jira.yourdomain.com/issues/?jql=project+%3D+PROJECT_NAME%+AND+fixVersion+%3D+{{issue.fixVersions.name}}|{{issue.fixVersions.name}} – a link to a filter showing all issues included in the release version specified in the trigger issue;
{{issue.assignee.name}} – the assignee.

project-rule-13: List Ready Backend/Frontend Tasks

What it does:
Once a day, it checks for new Backend and Frontend tasks that are ready to be picked up. You can split them by profile and/or set up separate automations for each issue type.

For example, you can set up separate automations with different icons for clarity:
🛠️ Backend: new features
🐞 Backend: new bugs
🎨 Frontend: new features
🐛 Frontend: new bugs

How it works:

– Runs daily on weekdays based on a cron schedule, checking for issues that match specific types, components, have no assignee, and were created 1 day ago (Scheduled);
– Sends a Slack notification (Send Slack message).

How it looks on Backend example:

Some details:

:ruby: – the icon that will be shown in Slack;
{{issue.issuetype.name}} – the issue type;
{{issue.priority.name}} – the issue priority;
https://jira.yourdomain.com/browse/{{issue.key}}|{{issue.key}} – the issue key with a clickable link;
{{issue.summary}} – the issue summary/title;
{{issue.labels}} – all labels;
{{issue.components.name}} – all components;
@{{issue.assignee.name}} – will mention the assignee in Slack if their usernames match between Jira and Slack;
{{issue.customfield_11406}} – a custom field indicating the target quarter for implementation.

How it looks in Slack:

project-rule-14: Monitor Stuck In Review

What it does:
On weekdays, it checks for issues in the “In Review” status that haven’t been updated recently. It adds a comment mentioning the Assignee, and also sends a message to the manager saying “Check why this is stuck.”

This is useful if your team strictly follows status transitions and doesn’t forget to keep them updated.

How it works:

– Runs daily on weekdays based on a cron schedule (Scheduled);
– Uses the following JQL filter: status = "In Review" AND updated < -5d;
– Adds a comment to the issue, mentioning the assignee by name: {{assignee.displayName}} (Comment on issue);
– Sends a Slack message to the manager in a designated channel.

How it looks:

Some details:

:what: – 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;
{{issue.assignee}} – the assignee, shown by username for brevity;
{{issue.updated.jqlDateTime}} – the last updated time of the issue.

Risk: If a comment was added, the issue won’t be included in the report because its Updated field will change. In our case, this happens very rarely (almost never), so this level of checking is sufficient.

project-rule-15: Priority Check for Blocked Tasks

What it does:
For high-priority issues in the Open or Waiting status, it checks the priority of their blockers and sends a notification. This helps catch cases where an important task is blocked by something Minor and ends up stuck in the queue.

How it works:

– Runs daily on weekdays based on a cron schedule (Scheduled);
– Uses JQL filters to find relevant issues: importantly, filters out issues without blockers:
  status IN (Waiting, Open) AND issueLinkType IN ("is blocked by") AND priority IN (Major, Critical, Blocker, ASAP)
– Adds an extra condition to exclude closed or unrelated blocking issues, and to skip sub-tasks:
  status != Closed AND type NOT IN (Backend, Frontend) (Related issues condition);
– Sends a Slack message to the manager in a dedicated channel.

How it looks:

Some details:

:Jira-blocker: – the icon that will be shown in Slack;
{{issue.issuetype.name}} – the issue type;
{{issue.priority.name}} – the issue priority name;
https://jira.yourdomain.com/browse/{{issue.key}}|{{issue.key}} – the issue key with a clickable link;
{{issue.summary}} – the issue summary/title.

project-rule-16: Log Work Report

What it does:
Sends a notification about logged work hours. It’s used for tracking time for team members who are paid on a per-hour basis.

How it works:

– Triggered when work is logged on an issue (Work logged);
– Filters by the user who added the work log (User condition);
– Sends a Slack message to the manager in a designated channel.

How it looks:

Some details:

:time-zone-fyi: – 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;
{{issue.assignee.displayName}} – the assignee’s name;
{{initiator.accountid}} – the username of the initiator who added the work log;
{{#math}}{{issue.fields.timespent}} / 3600{{/}}h – total time logged in the issue (in hours);
{{issue.updated.jqlDateTime}} – the timestamp of the last update to the issue (server time).

How it looks in Slack:

Tips & Tricks

If you’re using custom fields but don’t have access to the database, you can find the correct smart value name via the REST API:
https://jira.yourdomain.com/rest/api/latest/issue/ISSUE-KEY,
where ISSUE-KEY is any issue key from your project that includes the field you need.

If your Jira instance has many projects, make sure to specify exact project names in your conditions. Otherwise, you might accidentally move issues from other teams.

Whenever possible, prefer Scheduled rules with different time triggers instead of reacting to every status change. If your instance has a high volume of issue transitions, frequent triggers can overload Jira, causing delays or strange behaviour.

Don’t set yourself as the Actor in automation rules. Create a dedicated technical user so all automation activity is clearly separated in the issue history. Otherwise, you may end up wondering why your avatar is doing things you don’t remember.

If you're using Slack notifications, set up separate channels for different types of alerts. Without that separation, helpful updates can become just noise.

Don’t be afraid to create multiple automation rules that send messages to Slack or email – just make sure to review them regularly. If everything is running smoothly, it’s often better to disable them. In fact, I recommend adding notifications to all new rules at first, so you can track whether they’re working as expected.

Try to keep Slack messages short and scannable, ideally one line. If, over time, you notice some data isn’t useful – don’t hesitate to trim it down.

Use different emojis at the beginning of Slack messages to distinguish message types. Clarity makes everything easier.

Before You Go

This wraps up the final part of the series and I hope it sparked a few ideas for automations in your own projects. ;)

From structure to speed to visibility, smart Jira rules can turn routine into rhythm and give your team more space to focus on what really matters.

Got similar automation tips or favourite rules? Share them in the comments! I’d love to see what others are doing and using!

Let JIRA Do the Work: Life-simplifying (Part 2)

Ekaterina Vikulova — Mon, 30 Jun 2025 15:21:24 +0000

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!

Let JIRA Do the Work: Order-bringing (Part 1)

Ekaterina Vikulova — Mon, 23 Jun 2025 15:39:02 +0000

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 5 Jira Data Center Plugins for Managers: Streamlining Daily Work

Ekaterina Vikulova — Wed, 04 Jun 2025 10:13:23 +0000

Intro

Here are some of my favourite Jira Data Center plugins that simplify day-to-day management and help teams avoid micromanagement.

There aren’t many plugins for Data Center compared to Cloud, which is why all useful ones are doubly worth it.

1. Shared Estimations by Sngular

A minimalistic and convenient plugin for asynchronous estimations—no distractions, just the essentials.
It was released a year ago, so we can say the plugin is very young but already worth attention—more managers should know about it.

How it works:
1) Select estimation method. I usually go with Linear (1–10), where each number equals one work hour or day, depending on the task and your needs.

2) Start estimation.

3) Wait for estimators.
While voting is open, participant avatars are displayed. Sorry, I hid them there.

4) Stop estimation.
Once all required votes are in, the Owner closes voting. They may vote themselves or skip it. In my screenshot, I selected 10.

After closing, you see the vote distribution and a suggested estimation based on the most common choice.

You can also view detailed results—each participant’s name and their vote, helpful for deeper analysis.

If votes vary widely, follow-up discussion is recommended. When votes are similar, asynchronous voting works well.

A recent update introduced anonymous voting, where even the owner can’t see who voted what — only that the vote was submitted. Must be enabled / disabled before the session.

Limitations: Bulk estimation isn't supported yet, and I haven't found an easy way to do it using Jira Automation. If you’ve found a workaround — feel free to share!

The dev team is responsive and helpful. They answered my questions quickly and even updated the docs.

Links: Plugin and documentation.

2. Smart Issue Templates for Jira by AppsDelivered

Helps standardise task and bug report creation. When a template is selected, users see all required fields and helpful prompts.

I use separate templates for New Feature, Improvement, and Bug—each with its own structure and color scheme.

How it works:
1) Create a template. Define who can use it via the Available for field.
2) Set the scope. Choose which issues types / projects are included. Update fields as needed.

You can set Jira Groups and Users if you want to restrict the visibility of the template.

3) Define issue details. Priorities, components, and, of course, the description.

4) Save. The templates will appear as a dropdown in the Create Issue form.

I format my templates using {panel} blocks. While panels don’t handle images well, they help visually structure content.

Example template structure (no background):

{panel:title=The idea and Confluence link|borderStyle=solid|borderColor=#cccccc|titleBGColor=#bad7f7}
Short description of the feature.
{panel}
{panel:title=CRM changes|borderStyle=solid|borderColor=#cccccc|titleBGColor=#bad7f7}
Direct requirements: What must be changed, on which pages, and how.
{panel}
{panel:title=Customer Portal changes|borderStyle=solid|borderColor=#cccccc|titleBGColor=#bad7f7}
Direct requirements: What must be changed, on which pages, and how.
{panel}
{panel:title=Requesters / associated links / any additional info|borderStyle=solid|borderColor=#cccccc|titleBGColor=#bad7f7}
 * support/client, etc{panel}

Make sure to clear the Reporter field — otherwise, tasks will be created under your name (great for KPI, not so much for teambuilding).

Dark theme users: background colors may make text unreadable. If you use only light mode, here’s an example with background:

Example template structure (with background):

{panel:title=The idea and Confluence link|borderStyle=solid|borderColor=#cccccc|titleBGColor=#bad7f7|bgColor=#f1f8ff}
Short description of the feature.
{panel}
{panel:title=CRM changes|borderStyle=solid|borderColor=#cccccc|titleBGColor=#bad7f7|bgColor=#f1f8ff}
Direct requirements: What must be changed, on which pages, and how.
{panel}
{panel:title=Customer Portal changes|borderStyle=solid|borderColor=#cccccc|titleBGColor=#bad7f7|bgColor=#f1f8ff}
Direct requirements: What must be changed, on which pages, and how.
{panel}
{panel:title=Requesters / associated links / any additional info|borderStyle=solid|borderColor=#cccccc|titleBGColor=#bad7f7|bgColor=#f1f8ff}
 * support/client, etc{panel}

Links: Plugin and documentation.

3. Clone Plus for Jira by Appfire

Allows you to clone issues across projects in just a few clicks. Saves time when creating similar tasks to multiple teams or duplicating completed ones with the same specs.

Use case: “Bump ruby to x.x” or “Create a new Git Template” where everything is already specified — components, labels, etc.

Supports multiple cloning levels—including full copies with comments, worklogs, and watchers.

Links: Plugin and documentation.

4. Time Tracker for Jira Cloud & DC by Tempo Software

Generates clear Dashboard gadgets from user Worklogs. Helps visualise timespent per project, issue type, or users.

If you’re not using Dashboards yet — start now. They’re a powerful tool for managing teams and projects. Read about it at Atlassian.

You can group data by any field, including Custom Fields and Sprints.

Available reports and gadgets:

Time Sheet Report and Gadget — provides details to analyze workloads by displaying summaries of worked hours in Jira.
Project Pivot Report and Gadget — displays a summary of worked hours in a project of a certain period.
Timespent Report and Gadget — displays the total time spent per issue in a single-column table.
Worked Time Chart Gadget — visualize time spent on issues in a pie chart.
Flexible Reports — create other types of reports and gadgets like Time Entry, Timesheet, Calendar, Timespent, and more.

It is possible to display information by week or by month.

Example: Worklogs by Issue Type for the current month, grouped by user:

You can subscribe to reports via email from the Details section.

Links: Plugin and documentation.

5. Issue History Collector – See History by Appfire

While the previous plugin focuses on worklogs, this one analyses issue status transitions. It helps measure the full journey from planning to release (Time to Market). This kind of analysis helps identify weak points in processes that require optimisation or adjustment.

At the Jira Project you can filter reports by Issues or Users, and group by any chosen field.

In my example, the report is by issues:

Results can be exported to Excel.

Two new tabs appear in the issue view: User/Status Statistics and Status/User Statistics.

Global Admins can set working hours to exclude nights and weekends.

Limitations: If you manage multiple Jira projects, you’ll need to generate reports separately for each one.

Links: Plugin and documentation.

Conclusion

There are plenty of Jira plugins out there, but not all of them can be adapted to a team’s specific needs. Share your favourite and most useful ones in the comments or separate posts — let the world know about them!

GitLab: templates for Merge Requests

Ekaterina Vikulova — Tue, 27 May 2025 18:52:44 +0000

Intro

GitLab is a well-established tool that hardly needs any introduction. This article is more like some notes to my future self.

In GitLab, there are convenient user groups and even subgroups.

In GitLab, you use groups to manage one or more related projects at the same time.
You can use groups to communicate with all group members and manage permissions for your projects. If someone has access to the group, they get access to all the projects in the group.
You can also view all of the issues and merge requests for the projects in the group, and analytics about the group's activity.
Read more at GitLab.

Moreover GitLab offers handy templates for Merge Requests (MR), where these groups can be used.

Templates exist to standardise processes, save time and reduce mistakes in the MR's descriptions. Why create a new MR from scratch every time when you can make a good template once and reuse it?

GitLab templates eliminate repetitive writing and set a clear structure — everyone knows what information to provide and how it should look. This simplifies the creation process for the author and makes it easier for reviewers to understand what’s going on.

What to specify and where templates live

In templates you can specify:

users or groups (if you just want to notify them);
users or groups as reviewers;
assign necessary labels;
assign yourself as the assignee;
set Draft status;
set Ready status;
and much more.

A detailed list of “GitLab Quick Actions” is available in the documentation.

How to add a template to a repository:

path: .../-/tree/master/.gitlab/merge_request_templates
file: *.md

For example:
.../-/tree/master/.gitlab/merge_request_templates/Backend-ALL.md

Real example

In earlier versions of our templates, we specified exact usernames. When new employees were hired or team members switched teams, we had to manually update all templates where those names appeared. This was inconvenient not only because we needed to edit every template, but also because it was easy to forget — especially when templates were existing across multiple repositories.

Now we add users to specific groups and from there the magic takes care of itself – no human intervention needed.

How it works in practice

Find the list:

Select the needed one:

Apply it:

Of course, the Jira task describes what needs to be done and Figma shows how it should look, but from a code perspective, there are always nuances: a bit of refactoring here, rewriting an entire section there, fixing this little thing on the side, doing something a bit different than asked because… you know how it goes — and a whole lot more.

Code review is performed so that the author gets a second opinion on the chosen solution, increases the chances of catching bugs and issues early, and fosters knowledge sharing within the team.

Make your colleagues’ lives easier — briefly explain what you did and why.

About the example

In my example, the subgroups team-1 and team-2 of the backend_developers group are used. They are assigned as reviewers and get notified. Also, right after creation the MR author is assigned automatically and the labels Review and Backend are applied without extra clicks.

Template name used in the example: Backend-ALL.md

Code snippet:

* Jira tasks: TASK-
* Reviewers: @backend_developers/team-1 @backend_developers/team-2

### What

### Why
-
-

/assign_reviewer @backend_developers/team-1 @backend_developers/team-2
/assign me
/label ~Review ~Backend

Many team members have personal filters set up based on team labels.

Tips and tricks

Use labels — they make it easy to filter merge requests by teams, domains or change types. Color-coded labels simplify visual navigation: even a quick glance is enough to understand what the MR relates to.

Be careful with the filename — it will be used as the template name in the dropdown list. The name should be concise and clearly reflect the template’s purpose.

GitLab generates the list of available templates from the default branch (main or master). So, if you add a template in a separate branch and don’t see it in the list, don’t worry. After merging into the default branch, the template will appear.

DEV Community: Ekaterina Vikulova

Let JIRA Do the Work: Monitoring (Part 3)

Intro

Monitoring

project-rule-12: Send Release Note to Slack

project-rule-13: List Ready Backend/Frontend Tasks

project-rule-14: Monitor Stuck In Review

project-rule-15: Priority Check for Blocked Tasks

project-rule-16: Log Work Report

Tips & Tricks

Further Reading

Before You Go

Let JIRA Do the Work: Life-simplifying (Part 2)

Intro

Life-simplifying

project-rule-06: Assign Tester When Testing Starts

project-rule-07: Create Two Profiled Sub-tasks Backend+Frontend

project-rule-08: Unblock Waiting Sub-task

project-rule-09: Backend is Ready? Notify Frontend

project-rule-10: No Manual Testing Needed

project-rule-11: New Bug Report

Up Next

Let JIRA Do the Work: Order-bringing (Part 1)

Intro

Order-bringing

project-rule-01: Start Parent When Sub-task Starts

project-rule-02: All Sub-tasks Resolved? Move Parent

project-rule-03: Task Moved from Another Project

project-rule-04: Remove Assignee if No Code Needed

project-rule-05: Close Sub-tasks When Parent is Released

Up Next

Top 5 Jira Data Center Plugins for Managers: Streamlining Daily Work

Intro

1. Shared Estimations by Sngular

2. Smart Issue Templates for Jira by AppsDelivered

3. Clone Plus for Jira by Appfire

4. Time Tracker for Jira Cloud & DC by Tempo Software

5. Issue History Collector – See History by Appfire

Conclusion

GitLab: templates for Merge Requests

Intro

What to specify and where templates live

Real example

How it works in practice

About the example

Tips and tricks