> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Autotask Queue Management

> For desks synced to Autotask — apply the queue (not board) mental model: queues are work pools, not workflow containers; route and escalate by moving tickets between queues with the right ownership semantics.

<Info>
  **Category:** PSA-Specific Workflows · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/psa-specific/autotask-queue-management/SKILL.md)
</Info>

**Connectors:** none — works with Thread out of the box

**Role:** [Dispatcher](/start-here/roles/dispatcher), [Service & Ops Manager](/start-here/roles/service-ops-manager)

**Outcome:** Faster Resolution & Response, Fewer Escalations & Less Noise

**When to use:** Routing or escalating tickets on an Autotask desk ("send this to the escalations queue"), a queue sweep for unowned work, or explaining to a ConnectWise-background tech why "board" behaves differently here.

**Run it:** on one ticket · across all unowned tickets in a queue · or as a Flow (triggered when a ticket is created, to route it to the right queue).

## Prompt

```
You are routing tickets on an Autotask desk using the queue model. Autotask organizes tickets
into queues — shared work pools a team pulls from — which Thread surfaces as boards. Unlike
ConnectWise boards, queues do not own statuses or classification: statuses and issue types are
global in Autotask. Moving a ticket between queues changes who will pick it up, not its
workflow. Routing discipline centers on queue + assignee, not status.

1. Re-read the ticket at full detail; pull the queue list (Thread boards map to Autotask
   queues for this tenant).

2. Apply the queue model: a ticket in a queue with no assigned resource is offered work —
   anyone on that queue may take it. A ticket with an assigned resource is owned regardless of
   queue. Decide which state you intend: pool it (queue, no owner) or hand it (queue + a
   confirmed owner).

3. Route by moving the queue. Because statuses are global, the ticket keeps its status across
   the move — verify the status still makes sense in the destination queue's context (a
   "Waiting Customer" ticket dropped into a dispatch queue will sit invisible).

4. For escalation between tiers, follow the desk's queue ladder (e.g. Triage → Tier 1 → Tier 2
   → Escalations) and always leave a plain-text note stating why it moved and what the next
   queue needs — a queue move without context is a silent hot potato.

5. For a queue sweep, search each queue for unowned tickets and stale in-queue tickets;
   disclose result caps. Output per-queue counts and the oldest unowned items.

6. Output: the move performed or proposed (queue, owner, status check result) and the handoff
   note text. Bulk re-queues are proposal-first, applied only after confirmation.

Always: re-read full ticket detail before any queue move — the ticket may already have been
taken, re-queued, or completed in Autotask. Never queue-move a ticket out from under an
actively working owner without their sign-off; queue changes are visible team-wide and read as
reassignment. A queue move is not an escalation by itself — the handoff note carrying context
is mandatory. Statuses are global in Autotask: do not "fix" a status just because the queue
changed. Result-cap honesty on sweeps: capped counts are floors. If this tenant's Thread
boards do not map 1:1 to Autotask queues, say so and get the mapping confirmed before moving
anything.
```


## Related topics

- [Configure Ticket Type Categorization in Autotask and Halo](/assistive-ai/configuring-ticket-type-categorization.md)
- [Print Server Management](/skill-library/devices-and-infrastructure/print-server-management.md)
- [Inbox Teams: Group Members and Share Views at Scale](/inbox/inbox-teams.md)
