Plan requirement
| Subscription | Suite Professional or higher, Support Professional or higher |
| Access | Admin |
A queue is a set of waiting tickets with an order and a group of agents who can take them. Everything else is detail.
What a queue holds
- Conditions: which tickets belong in it.
- An order: which goes first.
- Groups: who can receive from it.
- Optionally subqueues, which refine the order further.
The default queue
Without custom queues, routing uses a standard queue that assigns within the group named in the ticket's group field. It is created for you when routing is switched on, and it catches everything that no custom queue claimed. For many teams that is enough, and building queues you do not need is a way to make a simple system complicated.
You will not see it on the Queues page. The standard queue is not listed there, so an empty page does not mean nothing is being routed.
Order within a queue
Tickets are ordered either by priority and timestamp, or by time to SLA breach. That second option is the one people overlook, and it is the honest choice where you have made promises: it puts the ticket closest to breaching in front, rather than the one somebody labelled urgent. Either way, it encodes what should be answered first, once, instead of relying on every agent making the same judgement.
The choice is made once, in the routing configuration, and applies to the standard queue and every custom queue alike. It is not a property of an individual queue, however much it reads like one. Priority itself only enters the calculation on Professional and above; below that, ordering is by age.
A ticket lives in exactly one queue
Queues are evaluated top down and a ticket drops into the first one whose conditions it meets. It does not appear in the others, however well it matches them. So the order of the queues page is not cosmetic: it decides which queue owns a ticket, and therefore which ordering rules apply to it.
That is what makes queue ordering a way to express priority between kinds of work, not just within one kind.
And custom queues outrank the standard queue entirely, whatever the tickets say. Work from a custom queue is handed out before anything in the standard queue, regardless of individual ticket priority, so an urgent ticket that fell through to the standard queue waits behind a routine one that matched a custom queue.
A custom queue overrules the group field
This is the behaviour that catches people. The standard queue routes to whatever group the ticket says it belongs to. A custom queue does not: once a ticket matches one, routing ignores the ticket's group field and uses the queue's own primary and secondary groups instead.
So a ticket your triggers carefully assigned to one group can be handed to another, and nothing is broken. If that is not what you wanted, the queue's conditions are too broad, not the trigger.
What happens first
Triggers run before routing. A new ticket fires its triggers, and only then does routing try to assign it to somebody. If nobody is available at that moment, it goes into the queue and waits there.
That order is why a trigger that sets the group or the priority still shapes routing, and why a trigger that runs on update cannot.
What gets into a queue at all
A ticket only queues if it is unassigned and in a status of New or Open. Assign it to somebody, or set it to Pending, On-hold or Solved, and it leaves routing entirely.
Beyond that the two kinds differ. The standard queue also needs the ticket to have a group, and an email ticket to carry the auto-routing tag. A custom queue needs neither: matching its conditions is enough.
Two more never queue: a soft-deleted ticket, and a messaging ticket whose session has ended.
Between queues, order beats priority
Ordering decides what comes first inside a queue. Between queues, two other rules apply, and they override anything a ticket's priority says.
- Custom queues always come before the standard queue. Every ticket routed through a custom queue is handed out before anything in the standard one, whatever its priority. An urgent ticket that matched no custom queue waits behind a routine one that did.
- Where an agent can take work from several queues, the higher queue wins. That is the order on the Queues page, which is the same order that decides which queue owns a ticket.
So the queue list is doing two jobs at once: deciding where a ticket goes, and deciding whose turn it is. Worth checking before you conclude that priority is being ignored.
What a queue is not
- Not a view. A view is a list to look at. A queue is what routing hands out from.
- Not a group. Groups say who agents are. Queues say what waits.
- Not a permission. Agents can still open tickets that a queue would not hand them.
Comments
0 comments
Article is closed for comments.