Ask a support team where new work lives and you usually get an uncomfortable answer: it lives in whoever’s inbox the customer happened to email. Queues are the oldest, simplest fix Dynamics 365 has for that — a shared holding area where work sits unowned until somebody deliberately takes it. No plugins, no premium licenses, just a discipline the platform enforces for you.
This post covers what queues actually are, the handful of commands agents use daily, and the small design decisions that make queues work in practice.
Queues in one minute
A queue holds queue items — pointers to cases, activities, or (if you enable it) any other entity. The record itself does not move; the queue item is a work ticket that says “this thing is waiting here”. A case can even sit in more than one queue at once, though most teams avoid that. You get personal queues (one per user, private) and public queues you create for teams, functions, or tiers — a Support Inbox, a Priority Desk, a Billing Questions queue.
The Queues page in Customer Service Hub has two dropdowns that trip everyone up on day one: the view (All Items, Items available to work on, Items I am working on) and the queue selector (a specific queue, all queues, queues I’m a member of). Combined, they answer the two questions an agent actually has: what’s waiting and what’s mine.
The four verbs
Select a queue item and the command bar gives you the whole workflow: Pick, Release, Remove, and Route.
Pick is the important one. It assigns the item to you and stamps you as the person working it. The dialog asks one clarifying question:
“Also remove the item from the queue?” — if you say No, the item stays visible in the queue with your name on it, which is what most teams want: the queue remains the single pane of truth for what is in flight. If you say Yes, the item disappears from the queue entirely and lives only on your plate.
After picking, the Worked By column fills in — and this is the difference between a queue and a shared mailbox. Everyone can see that the portal-login case is being handled, and by whom, without a single “is anyone on this?” message.
Release is the undo: it clears Worked By and puts the item back up for grabs — what you use when you picked something and then realized your shift is ending. Remove takes the item out of the queue without assigning it to anyone. And Route sends the item to a different queue or user — the manual version of what routing rules do automatically.
Design decisions that matter
A few things I have learned setting these up. Keep the number of public queues small — queues multiply like dashboards, and a queue nobody monitors is worse than no queue, because work in it looks handled. Match queues to capacity boundaries, not org charts: a Tier 1 / Tier 2 split earns its keep, a queue per product variant usually does not. Give each queue an owning team whose members treat “queue is empty” as the definition of done. And queues pair naturally with automation: an email-enabled queue can turn inbound mail into cases via automatic record creation rules, and routing rules can drop new cases into the right queue by priority or subject the moment they arrive — at which point the agents’ job reduces to the one verb that matters: Pick.
Start with two queues and the Pick discipline. You can add sophistication later; you cannot add back the hours lost to work that sat in someone’s inbox for a week.
