Short definition
A JSM queue is a saved JQL-backed view of service-desk tickets in Jira Service Management, organised so agents can see what to work on next. Each queue has a name, a JQL filter, a set of displayed columns, and an ordering. Queues are project-specific, configured by JSM project admins, and form the agent's primary workspace - replacing the issue navigator for day-to-day service work.
How queues fit into JSM
Jira Service Management restructures the agent experience around queues:
- A JSM project has a Queues section listing all available queues.
- Each queue is a JQL filter plus column / sort configuration.
- Agents pick a queue, see the matching tickets in a column-formatted list with SLA timers, and work through them top to bottom.
- The classic issue navigator still works but isn’t the agent’s default surface.
This is intentional: agents shouldn’t have to write JQL to find the next thing to work on. The queue list answers that question, with the most urgent work surfaced first (via SLA-aware sorting).
Typical queue layout
A starter set of queues for most service desks:
- All open - everything not yet resolved. The catch-all view.
- Unassigned - tickets needing pickup. The triage queue.
- My open tickets - the agent’s current assignments. Each agent’s home view.
- Awaiting support - waiting on the agent (vs. waiting on customer).
- Awaiting customer - waiting on the requester’s response.
- SLA breach soon - any active SLA within X hours of breach.
- High priority - P1/P2 only.
- Recently resolved - closed in last 24h, useful for handoff and audit.
The JQL behind each is straightforward; the value is in the curated agent experience.
SLA columns
The most-used queue column type is the SLA goal: a timer showing how close a ticket is to breaching a configured SLA (first response time, resolution time, etc.). Colour codes:
- Green - on track, plenty of time.
- Amber - approaching breach window.
- Red - actively in breach.
Sorting a queue by SLA descending puts the most urgent tickets at the top automatically - no agent has to remember which ones are about to breach.
Common pitfalls
Two patterns to watch:
- Queue JQL drift. Queues’ filters evolve as new categories of work appear; the JQL grows. Audit periodically that each queue still matches its name.
- Overlapping queues. Two queues that catch most of the same tickets create ambiguity (“which should I work first?”). Either make the filters disjoint, or be explicit about the priority order in the queue names.
Common questions
What is a JSM queue?
A JSM queue is a saved JQL-backed view of service-desk tickets in Jira Service Management, organised so agents can see what to work on next. Each queue has a name, a JQL filter, a set of displayed columns, and an ordering. Queues are project-specific, configured by JSM project admins, and form the agent's primary workspace - replacing the issue navigator for day-to-day service work.
How are JSM queues different from filters?
A queue is a JSM-specific UI surface for agents, with columns, sorting, and SLA visualisation. A filter is a saved JQL query reusable across Jira (dashboards, subscriptions, boards). A queue is built on top of a JQL expression similar to a filter but lives in the JSM project's queue list, not in the global filter library.
How many queues should a service desk have?
Most efficient JSM projects have 4-8 queues. Common patterns: All Open, Unassigned, My Queue, Awaiting Customer, SLA Breaching Soon, Recently Resolved. Beyond about ten queues, agents lose track of which queue to start in and the queue list itself becomes a workflow problem. Less is usually more.
Can JSM queues show SLA timers?
Yes. Each SLA goal on the project can be displayed as a column on any queue. The column shows time-to-breach colour-coded by urgency (green / amber / red). This is the most powerful reason to use queues over the generic issue navigator - SLA timers are first-class in queues but invisible in standard JQL views.