Jira round robin assignment hands each new issue to the next person on a list, so incoming work spreads evenly instead of piling up on whoever happens to be watching the queue. Jira Cloud can do this natively with Jira Automation, and for most teams that takes ten minutes to set up. The hard part is everything around it: people on leave, triage that happens in Slack instead of Jira, and the gap between "evenly assigned" and "actually picked up".

This guide covers the native Jira Automation round robin rule step by step, when to choose round robin over balanced workload or random, the failure modes that quietly break the rotation, and how to assign Jira issues from Slack so the people doing triage never have to open a browser tab to hand work out.

What Jira round robin assignment actually does

Round robin is the simplest fair distribution algorithm there is. You define an ordered list of people. The first issue goes to person A, the second to person B, the third to person C, and then it wraps back to A. Atlassian's own support article on auto assignment describes exactly this three person example.

What round robin does not do is look at anything about the people or the issues. It does not know that person B already has nine open tickets, that person C is on holiday, or that the issue that just landed is a five minute fix while the previous one was a three day investigation. It counts issues, not effort, and it counts arrivals, not current load.

That sounds like a list of weaknesses, but it is also the reason round robin works so well for certain queues. It is predictable. Anyone on the team can tell who gets the next ticket. Nobody can game it by closing easy tickets quickly to look less busy. And when issues are roughly similar in size, which is true of many support, bug triage and access request queues, counting arrivals is close enough to counting effort.

Round robin vs balanced workload vs random

Jira Automation's assign action offers three methods when you assign to a user in a defined list. According to the Jira Automation actions reference, they behave like this:

Round robin assigns to the next user in the list, in order, regardless of how much they already have.
Balanced workload assigns to the user with the fewest issues matching a JQL query you provide, so it reacts to current load rather than arrival order.
Random picks a user from the list at random. Over large volumes it evens out; over a single week it can be lumpy.

A rough rule of thumb: use round robin when issues are similar in size and you value predictability; use balanced workload when issue sizes vary a lot or people close work at very different speeds; avoid random unless you specifically want to prevent people from predicting what they will get.

Balanced workload is often the better default for engineering bug queues, and we will show both rules below. But the setup is nearly identical, and most of the operational advice in this guide applies to both.

How to set up Jira round robin assignment with Jira Automation

These steps use Jira Cloud. Atlassian has been renaming "issue" to "work item" across the product, so depending on when you read this the labels may say "Work item created" and "Assign work item" rather than "Issue created" and "Assign issue". The behaviour is the same.

Step 1: Check permissions before you build anything

Every person on the list needs the Browse projects and Assignable user permissions in the project. If one of them is missing, the rule will fail for that person with an assignment error, and depending on how you notice failures that can go unseen for days. Check the project's permission scheme first, or add everyone to a project role that already has both permissions.

The rule's actor (by default "Automation for Jira") also needs permission to assign issues in the project. In most projects this is already true, but restricted projects and some service projects need it checked.

Step 2: Create the rule and pick the trigger

Go to Project settings, then Automation and create a new rule. For most queues the trigger is Issue created (or Work item created). If issues are created in a holding state and only become real work after triage, use Issue transitioned into the status that means "ready for someone to pick up" instead.

Step 3: Add conditions so the rule only touches the right issues

Without conditions, the rule assigns everything, including issues someone deliberately assigned at creation time. Add these before the action:

Issue fields condition: Assignee is empty. This prevents the rule overwriting a manual assignment.
Issue fields condition: Issue type equals Bug (or whatever types this queue covers). Epics and sub-tasks usually should not be in the rotation.
Optionally a JQL condition such as labels not in (needs-triage) if some issues should wait for a human.

Step 4: Add the assign action with the round robin method

Add the Assign issue action and choose A user in a defined list. Add each person in the order you want them to receive work. Under the method, pick Round-robin.

The action also asks for a JQL restriction. For round robin this mostly matters for reporting and edge cases, but for balanced workload it is the whole algorithm: Jira counts how many issues matching that JQL each person currently has, and assigns to the lowest. A sensible balanced workload restriction for a bug queue is:

project = BUG AND statusCategory != Done

That counts open bugs per person, so someone who closes their work quickly gets more of it, and someone stuck on a nasty one gets a breather. If you only want to count recent work, add something like AND created >= -14d.

Step 5: Tell people the issue arrived

Assignment alone does not mean anyone saw it. Jira's own notification email is easy to miss, so add a follow-up action that posts somewhere people actually look. The Send Slack message action can post to a team channel with the issue key, summary and the new assignee's name. If the assignee needs a direct ping, include their name in the message text so the channel sees who owns it.

Step 6: Test with a throwaway issue type or project

Create four or five test issues in a row and check that they go A, B, C, A. Then check the rule's audit log. Every execution is recorded there with its outcome, and the audit log is the first place to look whenever someone says "I never get tickets" or "I get all the tickets".

Where native round robin breaks down

The rule above works on day one. These are the problems that show up in week three.

People on leave still get tickets

The defined list is static. Jira Automation does not know about holidays, sick days or someone being heads down on a launch. When person B is away for two weeks, every third issue goes to an inbox nobody is reading.

Teams usually patch this in one of three ways. Some edit the list manually every time someone goes on leave, which works until the person editing it is also on leave. Some add a condition that checks a custom field or a user property and reassigns if the person is marked away, which adds complexity to every rule. And some stop maintaining a list in Jira at all, and instead ask an external schedule who is available, which is where a rotation tool comes in.

New joiners and leavers are forgotten

Because the list lives inside an automation rule, it is invisible to most of the team. A new engineer joins and does not get added; someone moves teams and keeps receiving the old team's bugs. If you have more than one rule (one per project, or one per issue type), the lists drift apart. Write down where every list lives, and make updating them part of your onboarding and offboarding checklist.

Round robin is fair by count, not by effort

If your queue mixes trivial and heavy issues, round robin will look fair on a dashboard and feel unfair to the people doing the work. Two common fixes: switch to balanced workload so the rule reacts to open load, or split the queue so heavy work (for example anything labelled investigation) has its own rotation.

Triage happens in Slack, not in Jira

This is the big one for engineering teams. A customer success manager reports a bug in a Slack channel. An engineer reads it, confirms it, and then somebody has to create a Jira issue, copy the context across, and assign it. By the time the issue exists in Jira, the round robin rule fires, but the conversation that explains the bug is still in Slack, and the assignee has to go and find it.

The fix is to make Slack the place where issues are created and assigned, with Jira as the system of record, rather than the other way round. More on that below.

Assigned is not the same as acknowledged

Round robin decides who owns an issue. It does not check that they noticed. For low priority queues that is fine; people pick up their assigned tickets when they next look. For anything with a response time target, an assignment that nobody acknowledges is a silent breach. That is the point where you need escalation, not just distribution.

Round robin vs assigning to whoever is on call

There are two different questions hiding inside "who should get this Jira issue":

Who is next in line? That is round robin. It is about spreading routine work evenly over time.
Who is responsible right now? That is on-call. It is about one named person owning anything urgent during their shift.

Plenty of teams need both. Routine bugs and requests go round robin across the whole team during working hours. Anything tagged urgent, or anything raised out of hours, goes to whoever is on call. Mixing the two into one rule usually ends badly: either the on-call engineer gets all the routine work too, or an urgent bug lands on someone who has gone to bed.

A clean pattern is two rules on the same project. The first fires on priority in (Highest, High) and assigns to the current on-call. The second fires on everything else and uses round robin or balanced workload. We covered the on-call side in detail, including the Jira Automation web request that looks up the current on-call user, in how to assign Jira tickets to the current on-call.

Jira Automation also has an On-call responder option in the assign action, but it reads from an Opsgenie schedule. Atlassian has announced that Opsgenie shuts down in April 2027, so if you are building new rules today it is worth not tying them to that option.

Using a rotation as the source of truth instead of a static list

The underlying problem with a defined list in an automation rule is that it is a second, hidden copy of something your team already maintains elsewhere: who is on the team and who is available. Every time those diverge, the rule misroutes work.

The alternative is to keep one rotation, the one your team already looks at, and have Jira ask it who should get the next issue. That rotation can handle leave, overrides and swaps in one place, and every rule that reads from it stays correct automatically.

What a good rotation for issue assignment looks like

Short handovers. For issue distribution, a rotation that moves daily (or even per shift) spreads work far better than a weekly one. A weekly rotation is just round robin with a seven day batch size.
Overrides that take seconds. When someone is out, a teammate should be able to cover their slot without editing an automation rule.
Visibility in Slack. If people can see who has the queue today without opening Jira, they stop pinging the wrong person.
A user group that follows the rotation. A Slack handle like @bug-triage that always points at today's owner means reporters do not need to know the rotation at all.

Pagerly lets you create round robin rotations directly in Slack without setting up a separate paging tool, keeps a Slack user group in step with the rotation, and exposes the current owner to Jira Automation through the same lookup described in the on-call post linked above. Point the Jira rule at the rotation instead of a hard coded list, and leave cover becomes a Slack override instead of a rule edit.

How to assign Jira issues from Slack

If your triage already happens in Slack, the most effective change is often not a better Jira rule but fewer trips to Jira. There are a few ways to do this, from free to fully integrated.

Option 1: Slack workflow plus Jira Automation incoming webhook

Jira Automation supports an Incoming webhook trigger. You can build a Slack workflow that collects a summary and description, then calls the webhook, and have the Jira rule create the issue and run your round robin assignment. This is cheap and needs no extra tools, but the Slack thread and the Jira issue are not linked afterwards, and nobody in Slack sees who it was assigned to unless you add that message back yourself.

Option 2: The official Jira Cloud app for Slack

Atlassian's Jira Cloud app can create issues from messages and post notifications to channels. It is a good fit for teams that mostly want visibility. Combine it with the round robin rule above: create the issue from the Slack message, let Jira Automation assign it, and let the app post the assignment back to the channel.

Option 3: A Slack-native workflow that keeps the thread and the ticket together

For teams where Slack really is the front door, the goal is that the person reporting the bug, the person triaging it and the person assigned to it can all stay in the same thread. Pagerly's Jira integration lets you create Jira issues from Slack messages and comment on, assign and transition tickets from Slack, so the round robin owner can pick up the issue, ask a clarifying question and move it to In Progress without switching apps. Combined with a rotation that knows who owns the queue today, the reporter can simply mention the triage user group and the right person is pulled into the thread.

A practical setup for a five person engineering team

Here is a concrete configuration that works well for a small product engineering team handling customer reported bugs alongside feature work.

The queues

Urgent bugs (Highest or High priority, or anything raised by the on-call alerting): assigned to the current on-call engineer, who has a weekly shift.
Routine bugs (Medium and Low): distributed by balanced workload across the four engineers who are not on call this week.
Access requests and small chores: round robin across all five, because they are uniform in size and predictability matters more than load.

The rules

Rule 1, trigger Issue created, condition priority in (Highest, High), action: look up and assign the current on-call.
Rule 2, trigger Issue created, conditions issue type is Bug and priority is Medium or Low, action: assign to a user in a defined list with balanced workload, JQL project = BUG AND statusCategory != Done.
Rule 3, trigger Issue created, condition issue type is Task with label access, action: round robin across all five.
Each rule ends with a Slack message to #eng-triage naming the assignee.

The weekly hygiene

Every Monday, the outgoing on-call engineer checks the automation audit log for failed executions.
Anyone booking leave adds a rotation override at the same time, not on their last day.
Once a month, someone runs a JQL report of issues created in the last 30 days grouped by assignee, to confirm the distribution looks the way the team expects.

That last step matters more than it looks. Round robin failures are quiet. The rule keeps running and reporting success while one person on the list has been unassignable for a fortnight. A thirty second monthly check catches it.

Measuring whether your Jira round robin is working

Distribution is a means, not the goal. The goal is that work gets picked up quickly and nobody burns out. A few simple measures tell you whether the rotation is doing its job:

Issues assigned per person per month. For round robin this should be nearly identical. If it is not, the list or the permissions are wrong.
Open issues per person right now. If round robin counts are equal but open counts are wildly different, issue sizes vary too much and balanced workload will serve you better.
Time from creation to first response. If this is creeping up, assignment is happening but notification is not. Fix the Slack message step before touching the algorithm.
Reassignments. A high rate of manual reassignment means the rule is routing work to the wrong people, usually because skills differ more than the rotation assumes. Consider splitting the queue by component.

You do not need a dashboard for most of this. Two saved JQL filters and a monthly look are enough for a team of fewer than ten.

Common questions about Jira round robin assignment

Does Jira round robin skip people who are inactive?

Do not rely on it. The safest assumption is that the rule will try to assign to every person on the list, and if someone has lost access the action fails for that issue. Remove people from the list when they leave the team, and check the audit log for errors.

Can I use a Jira group instead of a named list?

The assign action also supports assigning to a user in a group or a user in a role. That keeps membership out of the rule, which is helpful, but a group still has no idea who is on leave. Groups solve the "new joiner forgotten" problem, not the availability problem.

Is round robin available in Jira Data Center?

Automation for Jira on Data Center and Server has offered smart assignment with load balancing, random and round robin methods for several versions, but menus differ by version. Check the automation documentation for your exact release.

Should on-call engineers be in the routine round robin too?

Usually not during their shift. Being on call already carries interruption cost. Excluding the on-call person from routine distribution for that week is one of the simplest ways to make on-call feel fair, and it is far easier to do when both the on-call schedule and the routine rotation live in the same tool.

Key takeaways

Jira Automation supports round robin natively: Assign issue, A user in a defined list, Round-robin. It takes minutes to set up.
Check that everyone has Browse projects and Assignable user permissions first, and add an "assignee is empty" condition so manual assignments survive.
Choose round robin for uniform work where predictability matters, and balanced workload for queues where issue sizes vary.
Static lists drift. Leave, joiners and leavers are the main reason round robin silently misroutes work.
Keep routine distribution and on-call ownership as separate rules, and keep the on-call engineer out of the routine rotation during their shift.
If triage happens in Slack, assign from Slack and keep the thread and the ticket together.
Assignment is not acknowledgement. Post every assignment where people actually look, and review the audit log regularly.

Conclusion

Jira round robin assignment is one of the cheapest fairness improvements an engineering team can make. The native rule is good enough to start with today. The work that keeps it fair is operational: keeping the list in step with reality, separating urgent from routine work, and making sure each assignment is actually seen.

If you would rather manage that rotation where your team already talks, Pagerly runs round robin rotations and on-call schedules inside Slack, keeps user groups in sync, and connects to Jira so issues can be created and assigned from the thread they started in. Pricing is per team rather than per responder; see the pricing page on pagerly.io for the current plans.