The queue structure usually comes from the org chart, not the work
Most Service Cloud case management problems don’t start with a bad assignment rule. They start earlier, when someone builds queues around the support team’s reporting structure instead of the actual shape of incoming work. Tier 1, Tier 2, Tier 3. Product A queue, Product B queue, Product C queue. It looks tidy in Setup. It falls apart the first time a case needs two skills at once, or a queue owner goes on leave and nobody remembers to reassign their cases.
I’ve worked with contact-centre teams where the queue list ran to forty or fifty entries, most of them created for a single project years earlier and never retired. Agents scrolled past half of them just to find where their work actually lived. Nobody could tell you, without checking three separate reports, which queue held the oldest unassigned case right now.
Start from what agents actually do, not what the department chart says
Before touching Assignment Rules, spend time with real case data. Pull six months of closed cases and look at what actually drove routing decisions: product, channel, customer tier, language, complexity. Not what the org assumes should drive routing. What the data shows actually happened.
In most orgs I’ve seen, two or three fields explain the large majority of the routing logic that matters. Everything else is noise dressed up as precision. A queue per sub-product line sounds thorough. In practice it means agents specialised in three narrow queues sit idle while a backlog builds in a fourth, because nobody built a fallback path between them.
Skill-based routing versus queue sprawl
Omni-Channel skill-based routing solves a lot of what queue sprawl was trying to solve badly. Instead of forty queues encoding forty combinations of product and tier, you define a smaller set of skills, say eight to twelve, and let the routing engine match cases to agents who hold the right combination. Agents can carry several skills at once. Coverage gaps show up as a skill nobody on shift currently holds, which is a staffing conversation, not a queue redesign.
The catch: skill-based routing needs someone maintaining the skill assignments as agents change roles, go on leave, or finish training. If that ownership isn’t assigned to a real person, skills drift out of date within a couple of months and routing quietly degrades. I’ve seen a routing problem get debugged for a week that turned out to be three agents whose skill records were never updated after a training programme wrapped up months earlier.
Assignment rules should fail loudly, not silently
A pattern I keep running into: assignment rules with a catch-all “else” branch that dumps unmatched cases into a general queue nobody actively monitors. It feels safe when you build it. Six months later that queue has 200 cases nobody has looked at, because checking it was never actually anyone’s job.
The better approach is to build a genuine catch-all queue, but attach a report and a dashboard component to it, and give it an SLA like any other queue. If a case lands there, someone should know within the hour, not discover it during a quarterly cleanup. Treat “unmatched” as a routing failure worth investigating, not a place to sweep cases you didn’t plan for.
Assignment rule order matters more than most admins give it credit for. Rules evaluate top to bottom, first match wins. I’ve debugged more than one org where a broad early rule silently swallowed cases that a more specific rule further down the list was supposed to catch. The fix isn’t clever Apex. It’s discipline: document rule order, test against real case examples before deploying, and review the full rule list whenever a new rule gets added rather than just appending it to the bottom.
Where automation should stop
Not every routing decision needs Flow or Apex behind it. I’ve seen teams build increasingly complicated Flow logic to handle edge cases affecting a handful of cases a month, while the assignment rules handling most of their volume stay basic and under-tested. That’s backwards. Put the engineering effort into the rules covering the bulk of your case volume. Handle genuine edge cases with a manual reassignment step and a short instruction for agents, at least until the pattern shows up often enough to justify automating it properly.
Presence configuration deserves the same scrutiny as routing logic. If an agent’s Omni-Channel status doesn’t reflect their actual availability (on a call, in a meeting, genuinely free to take work), routing will keep sending them cases they can’t touch, and work will sit in a routed-but-not-worked limbo that’s worse than an honest queue backlog. Get presence statuses right before tuning routing any further. Precision in routing on top of inaccurate presence data just moves the problem somewhere harder to see.
A short list of things worth checking this week
- How many queues actually get touched in a given week, against how many exist in Setup
- Whether skill assignments have been reviewed since your team’s structure last changed
- What happens to a case that matches no assignment rule, and whether anyone would notice
- Whether presence statuses map to real availability, not just to being logged in
None of this needs a platform migration or a six-month project. Most of it is an afternoon pulling case data, a few honest conversations with agents about where they actually lose time, and a willingness to retire queues that stopped earning their place years ago. The org chart will keep changing regardless of what you build. Queues and routing rules designed to survive that, rather than mirror it, are the ones still working eighteen months from now.
Leave a Reply