Jira Service Management Queues: Queue Management, Permissions, Filters, and Limits

What are queues in Jira Service Management, and how do you create one?

A queue is a saved view of work items inside a single service project, made of three parts: a filter that decides which items appear, an order that decides what sits at the top, and a set of columns that decides what an agent can see without opening anything. That third part matters more than it sounds. A well built queue lets an agent triage twenty tickets from the list itself, because the reporter, the request type, the SLA clock, and the priority are all visible in the row. A badly built queue makes them open every ticket to find out whether it is theirs. To create one you go to Queues in the service project sidebar, then Manage queues, or Queue settings on the Enterprise plan, then Create new queue. From there you set the filter, pick an Order by field, and choose your columns, which you can drag into whatever sequence your team reads fastest. The permission split is the part people trip on. Editing or creating a queue requires project admin. Viewing a queue requires a licensed Jira Service Management agent account. An agent cannot make their own private queue the way they can save their own filter, so every request for a personal view goes through an admin, and a project ends up with fifteen queues that exist because one person asked once. That is worth resisting, for reasons the next section gets into. If a queue is genuinely for one person, a saved filter is the better home for it, because filters belong to the user who made them and do not spend the project's queue budget or clutter anyone else's sidebar.

How many queues can you have in Jira Service Management?

Cloud allows up to 300 queues per work category, per project. That is a substantial increase from the previous ceiling of 50, which is why older guidance and older forum threads still quote the smaller number. Alongside it sits a second, less publicized limit: the Team priority group is capped at 50 queues. Queues beyond that cap are not lost, they are collected into an Other group that stays collapsed by default, so they exist but nobody sees them unless they go looking. In practice the ceiling is not your problem. Atlassian's own guidance on running queues at scale points at a far more uncomfortable number: the average agent looks at no more than three queues in a week. Whatever the other forty contain, it is not work anybody is doing. Every extra queue costs twice, once in the cognitive load of a sidebar nobody can scan, and once in the query the application runs to keep them all counted and current. The performance advice that follows from this is consistent and worth taking literally. Prefer several simple queues over one clever one. Avoid queues that reach across multiple custom fields, chain complex JQL functions, or filter on labels, because those are the queries that get slow first and stay slow. Avoid full text searches entirely, the summary ~ "hacked" and text ~ "thing" pattern, which is usually a sign that the request types are doing too little categorization and the queue is being asked to compensate. And bound your queues to recent work rather than all history, because a queue that reaches back three years is paying for rows no agent will ever scroll to. The honest test for any queue is whether somebody is accountable for emptying it. If nobody is, it is a report, and it belongs on a dashboard.

Jira queue permissions: can you hide a queue from certain agents?

No, and this is the single most common disappointment in the whole feature. There is no option to hide queues from service desk agents. Queue visibility is not a permission, it is not a scheme, and it is not configurable. Any licensed agent with access to the service project sees every queue in that project, including the ones built for a different team, including the ones with sensitive request types in them. There is a long standing open feature request for per-queue permissions and it has not shipped. Two workarounds exist, and they solve different problems, so pick by which one you actually have. The first is an issue security scheme. This restricts which work items a user can see, based on groups or project roles, and it applies everywhere including inside queues. The queue still appears in the sidebar, but a user who is not in the security level simply does not see the restricted tickets in it. This is the right tool when the concern is confidentiality, an HR or security request type that most agents should not read. It is the wrong tool when the concern is clutter, because the queue is still there and now it is also misleading, since two agents looking at the same queue see different counts. The second is separate service projects. Each project carries its own queues and its own agent list, so a technician added to one project sees that project's queues and nothing else. This gives true isolation, and it is the approach Atlassian community leaders point at most often. The cost is real: separate projects mean separate request types, separate SLAs, separate automation, and reporting that has to be stitched back together at the dashboard level. Do not split a project for tidiness. Split it when the teams genuinely do not share a workflow. One more permission detail that catches people during onboarding: an agent needs Service Desk application access, not just Jira access. A user with a Jira Software license added to a service project can browse work items and see nothing in the Queues tab, because queues are an agent feature. That is not a misconfiguration to hunt down, it is the licensing working as designed.

Why did my Jira queues disappear, or why is a queue suddenly empty?

Split this into two questions, because they have completely different answers. One person cannot see queues, everyone else can. This is almost always licensing or group membership. Check that the user holds a Jira Service Management agent license rather than a Software or Core one, that they have Service Desk application access, and that they are in the agent group for the site. A user with Software access added to a service project sees the project and no Queues tab at all, which reads like a bug and is not one. Queues vanished for everybody, or across every project. Now you are looking at something instance wide. The cause that surprises people most is that a single queue with invalid JQL can break the display for the whole set. A queue that references a custom field, a status, or a value that has since been deleted or renamed leaves a filter that no longer parses, and the failure does not politely isolate itself to that one queue. The same class of problem comes from work items sitting in a status that no longer exists after a workflow change. Two other causes are worth knowing because nobody would ever guess them. A third party app can break the queue display outright, so if this started the day after an app update, disable it and check before spending an afternoon on JQL. And an announcement banner with broken HTML, something as small as a missing closing tag, can stop the queue view from rendering, because the malformed markup breaks the page around it. Turning the banner off temporarily is a thirty second test that has resolved more of these than it has any right to. On Data Center, add a version mismatch between Jira Service Management and Jira Core to the list, and check whether a proxy, firewall, or VPN is blocking the background requests the queue view depends on. An empty queue, as opposed to a missing one, is usually the boring answer: the JQL is correct and matches nothing, most often because it filters on a project, a request type, or a resolution value that changed underneath it. Open the queue's filter in the issue navigator and take conditions off one at a time until rows appear. Whichever condition brought them back is the one that broke.

Jira queue vs filter, and the decision a queue will never make for you

The practical difference comes down to reach and audience. A queue lives inside one service project, is visible only to licensed agents on it, sits one click away in the sidebar, and supports inline editing so an agent can change a field without opening the ticket. That last part is why agents like queues: triage happens in the list. A saved filter is a global Jira object. It can be shared with any Jira user, not just agents, and it feeds dashboards, boards, and email subscriptions, which a queue cannot do. So the rule of thumb is straightforward. If the audience is your agents and the purpose is doing the work, build a queue. If the audience includes a manager, a stakeholder, or anyone without an agent license, or the output belongs on a dashboard, build a filter. Exporting follows the same split. A saved filter exports to CSV or Excel from the issue navigator as a matter of course. A queue historically did not, which is why export Jira queue to Excel is still a common search; the current path is to open the queue's contents in the global issue navigator and export from there, which works but is a step people have to be told about. Neither one, though, addresses the thing that actually goes wrong. Both a queue and a filter are views. They describe work. They do not distribute it. A perfectly tuned queue still leaves the assignment to whoever opens it first, and that is where the load goes uneven: the quick tickets get taken immediately, the awkward ones age at the bottom, the two most conscientious agents end up carrying a third of the board, and the person who joined last month is barely assigned anything because nobody is watching. Jira's automation can close part of this, and if you have not built it yet, the Assign issue action supports round robin, balanced workload, and random, which is genuinely useful and free with the licence you already hold. It also has real edges: an agent without the Assignable User permission is skipped silently, there is no shift or working hours awareness, and the balanced workload option counts open issues rather than the effort in them. That is the boundary Assigner works on, beside Jira rather than instead of it. Queues keep doing the triage they are good at, and Assigner decides the person: round-robin assignment with rotation state that survives team changes, workload balancing that counts open work rather than rows, skills-based routing, and availability routing that respects working hours and time zones, applied across support ticket routing, sales leads, and ops tasks through one engine at $12 per user per month. Every assignment records the rule it used and the candidates it considered. Our page on Jira ticket assignment sets out where staying native is the right call, because for a single team on one project it frequently is. Assigner is a companion rather than a live two-way sync, and it is built to help rather than to guarantee an outcome.

What are queues in Jira Service Management?

A queue is a saved, filtered list of work items shown in the Queues tab of a service project. It is built from three things: a filter that decides which items appear, an order that decides what sits at the top, and a set of columns that decides what an agent can read without opening a ticket. Queues are how agents triage, and they exist only inside the service project that owns them.

How do I create a queue in Jira Service Management?

Open Queues in the service project sidebar, choose Manage queues, or Queue settings on the Enterprise plan, then select Create new queue. Set the filter that defines what belongs in it, pick an Order by field, and choose and reorder the columns your agents need to see. You must hold project admin permission on that service project; an agent cannot create one.

How many queues can you have in Jira Service Management?

Cloud allows up to 300 queues per work category, per project, raised from an earlier limit of 50. A separate cap of 50 applies to the Team priority group, and any queues past that are collected into an Other group that stays collapsed by default. The practical limit is much lower than the technical one, since the average agent looks at no more than three queues in a week.

Can you restrict access to a queue in Jira Service Management?

No. There is no option to hide queues from service desk agents, and queue visibility is not a permission or a scheme. Every licensed agent on a service project sees every queue in it. The two workarounds are an issue security scheme, which hides individual work items rather than the queue, and splitting the work into separate service projects, which gives true isolation at the cost of duplicated configuration.

Who can create and edit queues in Jira Service Management?

Creating and editing queues requires project admin permission on that service project. Viewing a queue requires a licensed Jira Service Management agent account with Service Desk application access. A user holding only a Jira Software or Jira Core license can be added to a service project and will still see no Queues tab, because queues are an agent feature.

Why did my Jira Service Management queues disappear?

If one person cannot see queues, check their license and application access first, since agents need Service Desk access rather than Jira Software access. If queues vanished for everyone, the usual causes are a single queue whose JQL no longer parses after a field or status was deleted, a third party app breaking the display, or an announcement banner containing malformed HTML such as a missing closing tag.

Why is my Jira queue empty when tickets exist?

An empty queue almost always means correct JQL that matches nothing. The filter usually references a project, request type, status, or resolution value that has been renamed or removed since the queue was written. Open the queue filter in the global issue navigator and remove conditions one at a time until rows appear; the condition that brings them back is the broken one.

What is the difference between a Jira queue and a filter?

A queue lives inside one service project, is visible only to licensed agents there, and supports inline editing so triage happens in the list. A saved filter is a global Jira object that can be shared with any Jira user and feeds dashboards, boards, and email subscriptions, which a queue cannot do. Build a queue for agents doing the work, and a filter for anyone reporting on it.

How do I export a Jira Service Management queue to Excel?

Open the queue contents in the global issue navigator, then use the export option to produce a CSV or Excel file. Queues did not originally offer a direct export, which is why the question is still common and why older answers tell you to copy the JQL into the navigator manually. Saved filters have always exported directly from the navigator.

Can Jira Service Management assign tickets from a queue automatically?

Not by itself. A queue is a view and takes no action, so work sits in it until an agent claims it. Automation for Jira can close the gap with an Assign issue action offering round robin, balanced workload, and random, though it has no shift or working hours awareness and silently skips anyone lacking the Assignable User permission. Rotation that survives team changes needs state kept outside the queue.

What is the Team priority group in Jira queues?

Team priority is the pinned group at the top of the Queues tab holding the queues your team works from every day. It is capped at 50 queues. Anything beyond that cap is placed in an Other group that is collapsed by default, so those queues still exist and still count toward the 300 per project ceiling, but nobody sees them unless they expand the group deliberately.