Omni-Channel routing gets blamed for a lot of things it didn’t cause. A case sits in queue for twenty minutes, an agent swears they were available, and someone opens a ticket saying “routing is broken.” Nine times out of ten, the routing engine did exactly what it was configured to do. The configuration just stopped matching how the team actually works, months ago, and nobody noticed until a customer complained.
I’ve debugged this pattern on more than one contact-centre org now. The fix is rarely a routing change. It’s usually somewhere upstream of routing: presence, capacity, or a queue that quietly drifted out of sync with the team roster.
Start by checking what “available” actually means
Omni-Channel routes work based on presence status, and presence status is only as reliable as the configuration behind it. The most common failure I see: an agent’s presence status is marked “Available,” but the status options aren’t tied to the actual channels the agent can handle. They’re online, green light showing, but their service presence status was built for phone and chat, not the new async channel someone added six months ago. The routing engine has no way to know that. It just sees “Available” and sends work.
Same problem shows up in reverse. A status like “In a Meeting” or “Training” should decline new work, but if it wasn’t explicitly configured to do that, agents sit there accumulating case assignments while genuinely unavailable. Nobody built it wrong on purpose. Someone added a new presence status for a one-off project eighteen months ago, used the default settings, and it’s been quietly misrouting work ever since.
What to actually check
Go through every Service Presence Status record and confirm, for each one, exactly which channels it allows and whether it’s marked to decline incoming work. Don’t trust the label. “Available – Chat Only” doesn’t restrict anything unless the configuration says so. This takes maybe thirty minutes and it’s the single highest-value audit you can run on a struggling routing setup.
Capacity models that were right on day one
Capacity-based routing works well until the assumptions behind it stop holding. A common one: capacity weights were set when the average case took four business days to resolve. Then the team restructured and a chunk of cases started reopening within hours, sometimes the same day. The capacity model never changed. It still assumes a case closes and frees up capacity. In practice, agents are juggling three or four reopened cases that look closed to the model but are very much open to the customer.
The result is agents who look underutilised on paper, routing more work to them, while they’re actually buried. This one’s hard to catch from the routing side because every signal routing looks at says the agent has room. You have to go looking at reopen rates and average handle time by case type, not at the routing config itself.
Queue membership that nobody owns
Queues drift. Someone leaves the team and their manager removes their licence, but forgets to pull them off the three queues they were on. Someone joins and gets added to the “general” queue on day one, then never gets added to the specialised queues they were actually hired to work. Six months later, routing decisions are being made against a membership list that reflects an org chart from last year.
This is the one I’d flag hardest, because it’s invisible until you specifically go look. Nobody gets an error. Routing just quietly sends slightly less work to the right people and slightly more to the wrong ones, and the gap compounds. A quarterly audit of queue membership against the actual team roster catches this before it becomes a pattern someone has to explain to leadership.
A smaller version of the same problem
Skills-based routing has the identical failure mode at a more granular level. Skills get assigned when someone’s onboarded and almost never reviewed again. An agent who moved off a product line two years ago is still being routed cases for it, because the skill record was never updated. Treat skills like permission sets: they need a review cadence, not a one-time setup.
Routing configuration changes that never got tested
This is the one that should worry admins most. Routing configuration in Salesforce is declarative, which makes it feel low-risk. It isn’t. A single change to routing priority, or to how overflow is handled after a time limit, can shift work distribution across an entire team, and there’s usually no automated test watching for that.
Before any routing change goes to production, simulate it against a realistic volume pattern, not just a happy-path manual test with one case. Push through a burst of work that mimics a busy Monday morning and watch where it lands. Check the overflow path specifically: what happens when the primary queue is full and work has to spill somewhere else. That’s the path that gets touched least often in testing and breaks most often in production, usually at the exact moment volume spikes and you can least afford it.
Where I’d actually start
If routing feels broken and you don’t know why, don’t start with the routing configuration itself. Start with presence statuses and confirm they decline work when they should. Then check queue membership against the current team roster. Then look at capacity assumptions against actual reopen and handle-time data. In most cases I’ve worked, the routing engine was never the problem. It was faithfully executing rules built on assumptions that stopped being true a long time before anyone noticed.