Blog/Omni-Channel routing: the five places it usually goes wrong

Omni-Channel routing: the five places it usually goes wrong

A troubleshooting guide for presence, capacity, skills, priority, and ownership so cases actually route.

Ravi Patel12/15/20252 min readService CloudRoutingOperations

Omni-Channel issues are maddening because everything looks “set up”… and then nothing routes.

When someone says “agents are available but cases are stuck,” I stop guessing and walk the same path every time. There are only a few common failure points, and you can isolate them quickly if you check them in order.

This is that order.

1) Presence model

Check:

  • user has a Presence Configuration
  • the Presence Status accepts the channel
  • agents are in the correct console app with the Omni widget

A status labeled “Available” can still accept no channels.

2) Is the work item eligible to route?

For Cases, you typically need:

  • ownership by a queue Omni is monitoring
  • a routing configuration attached (service channel setup)

Use Omni Supervisor:

  • does the work item appear?
  • is it waiting?
  • priority/age reasonable?

If it never shows, the break is earlier (assignment rules, ownership changes, config mismatch).

3) Capacity math (the hidden blocker)

Presence Config has capacity. Routing Config consumes units.

If:

  • agent capacity = 5
  • case consumes = 5
    Then agents can only take one case at a time.

Pick a simple model first; tune later.

4) Skills routing: debug like a feature flag

If skills are involved:

  1. remove skill requirements — does routing work?
  2. add one required skill back
  3. confirm users have the skill (and level, if you use levels)

If each case requires 6 skills, you’ve built a deadlock.

5) Priority starvation

If one channel is always high priority, other work can sit forever. Fix with:

  • priority tuning
  • queue separation
  • concurrency limits

6) Stop fighting ownership

Choose the model:

  • queue owns; Omni pulls
  • Omni assigns; agent owns

Automation that changes OwnerId after creation is a common source of “routing weirdness.”

Fast checklist

  • work appears in Omni Supervisor
  • agent status accepts the channel
  • queue membership correct
  • capacity supports expected concurrency
  • skills not over-constraining
  • priorities not starving
  • no automation rewriting owner after create

Want help implementing this?

If you have a backlog and want steady delivery without surprise projects, we can handle admin-sized work under a monthly subscription.