What Is the Next Ticket Queue?

The Next Ticket Queue is pull-based ticket assignment. Instead of Horizon pushing a ticket at a technician the moment it arrives, tickets sit in a queue and technicians claim the next one when they actually have capacity to work it.

It exists for high-volume work where proactive assignment does more harm than good. Alert tickets are the usual example: assigning two hundred of them to a three-person team means nobody works any of them. A queue lets the team pull work at the rate they can absorb it.

Where to Find It

The queue shows up in three places, depending on who you are.

A few related settings live elsewhere:

• Post-commit actions for a single queue: the Post-Commit Actions tab on the queue itself
• Account-wide queue actions: Admin Panel → Components → Assignment → Defaults, in the Ticket Queue Outcome Actions section
• Sending tickets into a push queue: configured on the assignment policy or routing rule that targets it, not on the queue

If a technician sees "No queues available" on their dashboard, that is the claiming-team rules doing their job, not an error. Check the queue's Claiming Teams and the eligibility conditions covered below.

Key Concepts

• Queue Type: Either Push or Filter. Chosen when the queue is created and permanent. There is no conversion in either direction.
• Claim: A technician taking the next ticket from a queue. Horizon writes the assignment to your helpdesk and records who took it, how long it waited, and how deep the queue was at that moment.
• Claiming Teams: The teams whose members are allowed to claim from a queue.
• Selection Strategy: The rule that decides which ticket is handed out next. Either arrival order or a date field on the ticket.
• Eject: Removing a waiting ticket from a push queue without anyone claiming it.
• Hand-off: A dispatcher assigning a queued ticket to a specific technician instead of waiting for someone to claim it.
• Post-Commit Action: A helpdesk write that fires automatically after a queue event, such as adding a note or changing a status once a ticket is claimed.

The Two Queue Types

Every queue is one type or the other, decided at creation. The difference is where its contents come from.

FIFO is unavailable on a filter queue because arrival order means the moment a ticket was put into the queue, and a filter-matched ticket was never put anywhere. It started matching. There is no honest arrival time to sort by, so Horizon refuses the configuration rather than inventing one.

What a filter queue deliberately includes

A filter queue's membership is whatever matches the filter, minus closed tickets, and nothing else. In particular:

• Already-assigned tickets are included. An escalation queue exists precisely to hold tickets that are already assigned to a lower tier.
• Previously claimed tickets are included. A ticket claimed from this queue two years ago is still a member today if it matches today.

Two technicians going for the same ticket is handled at claim time by locking, not by hiding tickets from the list.

Who Can Claim From a Queue

A user may claim from a queue if either of the following is true:

• They are on a team listed in the queue's Claiming Teams field, or
• They are on a team that an assignment policy already routes to this queue

The second half means you usually do not have to list a team twice. If an assignment policy sends a team's tickets into a queue, that team can claim from it without being added explicitly. The field's helper text says so on screen: "Teams already routed here by an assignment policy keep their access without being listed."

Either way, the user still has to pass every one of these:

• The user account is active
• The user is linked to a helpdesk resource
• Their membership on that team is active (not benched)
• The team itself is active
• The team is marked assignable

Routing rules contribute nothing here. A routing rule has no team attached to it, so a queue fed only by routing rules needs its Claiming Teams set explicitly or nobody will be able to claim from it.

An empty membership means nobody, never everybody. A queue with no claiming teams and no policy pointing at it will fill up and hand nothing out. The Queue Board flags this rather than letting you find out from the backlog.

Claim Order

Two strategies are available, set on the queue under Selection Strategy.

Date Field ordering is what you want for anything deadline-driven. Pick the field under Order By Field (it lists the raw helpdesk field names) and the direction under Order Direction, where ascending hands out the earliest date first.

Values are read live from the ticket every time someone claims, so a due date changed in the helpdesk five seconds ago affects the very next claim. Tickets with no value in that field sort last in both directions rather than being dropped from the queue.

Two configuration mistakes will stop a Date Field queue dead, both reported on the Queue Board:

• The field key is missing, or the direction is not set
• The field does not exist as an active date/time field on your ticket entity

There is a third case worth knowing if you run more than one helpdesk integration: date field names are provider-specific, so a field key that resolves on one provider may have no counterpart on the other. Horizon refuses to order the queue at all in that case, rather than silently sorting one provider's tickets to the bottom.

What Happens When a Technician Claims

A claim is not a single database read. In order:

1. Horizon confirms the queue is active and the user is eligible to claim from it
2. It locks the queue so two people cannot be handed the same position
3. It selects a short list of candidates in the queue's configured order, best first
4. It re-checks eligibility, because the user's team could have changed while the lock was being acquired
5. It walks the candidate list. For each one it takes a per-ticket lock, and on a filter queue re-confirms the ticket still matches the filter, then claims it
6. It writes the assignment to your helpdesk, records the claim, and fires any post-commit action configured on the queue

Two details that matter operationally:

• "Everything was taken" is not reported as "the queue is empty." If every candidate lost a race to another technician, the technician is told that, not told a forty-deep queue is empty.
• A short cooldown is applied to a ticket after it is claimed. On a filter queue there is a gap between the assignment write landing and the ticket stopping matching the filter, and the cooldown covers it so the same ticket is not handed to a second technician during that window.
  

How Tickets Leave a Queue

"Eject when assigned in the helpdesk"

Off by default. Turn it on when a queue should release a ticket the moment a human assigns it directly in ConnectWise, Autotask, or Halo, on the grounds that someone has clearly taken ownership outside Horizon.

Horizon distinguishes those assignments from its own. A ticket assigned by a queue claim or by a routing rule stays put; only an assignee Horizon did not ask for triggers the eject. The setting is unavailable on a filter queue, because membership there is the filter and a ticket leaves by no longer matching it.

The Queue Board

Dispatch Panel → Queue Board

The Queue Board is the dispatcher's view of every active queue. It answers two questions the admin screens do not: which queue is backing up, and whether anyone can actually claim from it.

The Status column is the important one. A queue can be configured into a state where the pending count climbs steadily and every single claim fails. Without the column that renders as a healthy queue with a big number, which is the exact opposite of the truth. It flags an incomplete or unresolvable date field, a filter that cannot be loaded, an ordering that is invalid for the queue type, an unsupported multi-integration setup, and the case where the queue's membership resolves to nobody at all.

Two display conventions worth knowing:

• A filter queue whose depth cannot be resolved shows Unavailable, not 0. Zero would read as "nothing waiting" and send you straight past the one queue that needs attention.
• Longest Wait is labelled that and not "next out", because those are only the same thing on a FIFO queue.

Dispatcher intervention

Drilling into a queue gives you its contents and two levers:

• Hand-off. Assign a specific queued ticket to a specific technician. This works on both queue types, and it bypasses the claiming-team check on purpose: a dispatcher may hand a ticket to someone who is not on the queue's teams. It also still works on an inactive queue and on a misconfigured Date Field queue, which makes it the way to drain a queue that no agent can currently claim from.
• Eject. Remove a waiting ticket. Push queues only. There is no eject on a filter queue by any route, because there is nothing to remove: the ticket is in the queue because it matches.

A hand-off is recorded as a claim, not as an eject, so the ticket still counts as queue throughput in your volume and wait-time reporting. It is recorded against the technician who received the ticket, with the dispatcher who performed it noted separately.

Post-Commit Actions

Four queue moments can trigger a helpdesk action automatically:

• A ticket is added to a queue
• A ticket is claimed
• A ticket is ejected
• The helpdesk assignment write fails during a claim

Configure them per queue on the queue's Post-Commit Actions tab, or account-wide under Admin Panel → Components → Assignment → Defaults in the Ticket Queue Outcome Actions section. Each picker offers your active ticket-scoped Helpdesk Action presets.

An empty dropdown means "inherit account default", not "do nothing". Clearing a field on a queue is a real operation: it hands that moment back to the account-wide default. There is no per-queue way to say "fire nothing even though the account has a default". If you need that, remove the default and configure the other queues explicitly.

Nothing is copied onto a queue when you create it. Inheritance is resolved every time an event fires, so an unconfigured queue keeps tracking the account default as that default changes.

One exception to be aware of: an eject caused by the ticket closing runs no action. Your helpdesk will either reject a write to a closed ticket or reopen it, and neither is what you wanted.

Post-commit actions matter more than usual on a filter queue. A claimed ticket keeps matching its filter until something changes it, so the action that mutates the ticket (a status change, a note, a field write) is normally what removes it from the queue.

What Filter Queues Do Not Do

These are deliberate, not defects:

• No wait-time analytics. Horizon never knew when a ticket started matching a filter, so wait duration is recorded as zero rather than guessed from the ticket's created date.
• Depth will not match the saved filter's own preview count, because closed tickets are excluded from queue membership.
• Depth is briefly cached, so it can lag by up to the cache interval. The listing itself is live.
• The list can show a ticket someone already claimed, until the change propagates back through sync. The claim path catches this and moves on.
• No manual add and no eject. There is no way to drop a one-off ticket into a filter queue or pull one out of it.
• No converting a queue between types. Ever, in either direction. If you picked wrong, create a new queue.

Common Use Cases

• Alert and monitoring noise. A push queue fed by an assignment policy, so automated tickets accumulate in one place and the team pulls from it instead of each person receiving fifty assignments overnight.
• Deadline-driven work. A Date Field queue ordered ascending by due date, so the next ticket handed out is always the one closest to breaching.
• Tier escalation. A filter queue over a saved filter for "assigned to Tier 1 and older than four hours". Tickets appear as they qualify and disappear when they are dealt with, with no escalation rule to maintain.
• Overflow off a rotation. A routing rule sends anything the round-robin should not own into a queue, with the claiming teams set explicitly on the queue.
• Dispatcher-managed backlog. Any queue plus the Queue Board, where a dispatcher watches depth and hands off individual tickets rather than waiting for someone to claim.