Salesforce Omni-Channel: Setup, Routing and Mistakes

Key takeaways

• Salesforce Omni-Channel pushes work items (cases, chats, messaging sessions, leads and more) to the right agent based on capacity, availability and routing rules.
• Start with queue-based routing; add skills-based routing only when you can name the skills you're actually routing on.
• Agentforce agents and Omni-Channel work as a pair: the agent handles first contact, and an Omni-Channel flow routes the escalation to a human with context.
• Most failed launches come from missing pieces (a presence status with no service channel, a queue with no routing configuration), not from the routing model itself.

A case sits unassigned for two hours while six agents show "Available". That's the classic Salesforce Omni-Channel failure, and it's almost never a bug. It's a setup piece nobody checked.

This guide is for service admins and service leaders planning case routing, including routing to Agentforce agents. My argument is simple: start with the most boring routing design that works, and treat the AI handoff as a route you design, not a feature you switch on.

One note on accuracy. Menu names and flow options shift between Salesforce's three yearly releases, so check each step against Salesforce Help and Trailhead for your org's release.

What does Salesforce Omni-Channel actually do?

Omni-Channel is a routing engine that pushes work to agents who have capacity, instead of agents picking from a list.

A work item can be a case, a messaging session, a lead, a voice call or a custom object record. Omni-Channel looks at who is online, how much capacity each person has left, and where the item should go. Then it offers the item to an agent, who accepts or declines.

Three ideas carry everything else:

• Service channel: which object type is being routed (Case, Messaging Session and so on).
• Presence status: whether an agent is online, and for which channels.
• Capacity: how much work an agent can hold at once, measured in units you define.

If you understand those three, the rest is configuration.

How to set up Salesforce Omni-Channel step by step

Setup is seven pieces, and routing silently fails if any one is missing.

1. Enable Omni-Channel. In Setup, open Omni-Channel Settings and turn it on. Enable Skills-Based Routing here too if you plan to use it. Secondary Routing Priority is also an option on this page.
2. Create or confirm service channels. Add a channel for each object you'll route. Case is the usual first one.
3. Create a routing configuration. Set a routing priority, a routing model (Least Active or Most Available are the standard choices), and the capacity each item consumes. Check whether your release offers a push time-out, which controls how long an offer waits before moving on.
4. Create a queue and link it. Add Case as a supported object, attach the routing configuration, and add members. A queue with no routing configuration is just a list, not a router.
5. Create presence statuses. Each status needs the service channels it covers. "Available for cases" with no case channel selected is the single most common reason people never receive work.
6. Set presence configuration and access. Define each agent's total capacity, then give users access to the right statuses through profiles or permission sets.
7. Add the Omni-Channel utility to the Service Console app so agents can go online and accept work.

Then decide how work reaches the queue. You can use case assignment rules, or an Omni-Channel flow with the Route Work action in Flow Builder. I prefer flow for anything new. It's more visible, easier to extend with skills, and it's where the Agentforce handoff lives.

A capacity example (hypothetical): an agent has 10 units. Each case takes 5 units and each messaging session takes 3. That agent can hold two cases, or one case and one chat, but not three cases. You're not guessing a headcount limit; you're encoding how heavy each type of work really is.

If your flow fires on record creation, remember timing. Fields set by other automation might not be populated when Route Work runs. My short guide to the order of execution in Salesforce explains why.

Queue-based vs skills-based routing: which should you use?

Use queue-based routing until you can name a specific skill that queues can't express.

	Queue-based	Skills-based
How it decides	Item goes to a queue; Omni-Channel offers it to a member with capacity	Item carries skill requirements; Omni-Channel finds agents holding those skills
Setup effort	Low: queues, members, routing configuration	Higher: define skills, assign them to users, maintain levels, set requirements per item
Best for	Clear team boundaries (billing, tier 1, premium support)	Language, product expertise, certifications, regulated work
Main risk	Too many queues and overlapping membership	Skill taxonomy that grows and rots; items waiting because nobody has every required skill
Maintenance	Update membership when people move	Update skills whenever people learn, leave or get certified

Skills-based routing is genuinely powerful. It lets one pool of people serve French-language enterprise billing and Spanish-language onboarding without twelve queues. But every skill is a data-maintenance commitment, and the matching is only as good as your records of who knows what.

My take: Most teams reach for skills-based routing too early because it sounds smarter. I'd bet that two or three well-designed queues beat a skills model nobody maintains. Add skills when you can point to a real mismatch, like cases going to the wrong language speaker, and start with two or three skills, not twenty.

A pattern that works: route to a queue by default, and add a skill requirement only on the segment that needs it, such as a language or a product line. Keep a fallback queue so nothing waits indefinitely when no agent matches.

How does Omni-Channel work with Agentforce agents?

Agentforce agents take first contact; Omni-Channel is the route to a human when the agent can't or shouldn't finish the job.

If you're new to the product, start with what Agentforce is. For routing, the key idea is that an Agentforce service agent isn't a replacement for your routing design. It sits in front of it.

The typical flow for messaging:

1. The customer starts a messaging conversation.
2. An Omni-Channel flow routes the session to the Agentforce agent, where your release supports that option in the Route Work action.
3. The agent answers from your knowledge and data, and takes actions it's been permitted to take.
4. When it can't resolve the request, or the subagent's scope requires a person, an escalation hands the conversation to an Omni-Channel flow.
5. That flow routes to a queue, a specific agent, or a skills-based match, and the human sees the conversation history.

The lesson for routing: the escalation path was designed as carefully as the answers. A handoff without context makes customers repeat themselves.

Design questions for the AI route:

• Which subagents must always escalate (refunds above a threshold, legal, complaints)?
• Which queue or skill does each escalation reason map to?
• What happens outside business hours, or when the target queue has nobody online?
• Who owns the item the moment it's escalated?

Cost matters here too. Conversations the agent handles carry usage charges, so run the numbers in the Agentforce pricing calculator before you decide how much volume to put in front of it.

My take: Don't send everything to the agent on day one. Route one low-risk topic, like order status or password help, to the agent and keep everything else on human queues. The agent should earn more volume, the same way a new hire does.

What are the most common Salesforce Omni-Channel mistakes?

Nearly every mistake is a missing link between two pieces that look configured.

• Presence status without service channels. Agents go "Available" and receive nothing.
• Queue without a routing configuration. Items sit in the queue and never get pushed.
• Capacity set too high. Agents get buried, decline items, and your speed-to-answer data becomes noise. Start conservative and raise it with evidence.
• Everyone in every queue. You lose the point of routing, and reporting can't tell you which team is overloaded.
• Skills nobody holds. An item requiring a skill no online agent has just waits. Always have a fallback.
• No testing as a real agent. Admins test as themselves with full permissions, then discover agents lack access to the status or utility.
• Ignoring the handoff. AI-to-human routing that drops context or lands in an unmonitored queue.
• No reporting. Teams go live without checking what actually happened to the work.

For that last one, the data is accessible. The AgentWork object records each routed assignment and its outcome, and PendingServiceRouting holds items waiting to be routed. A quick query during testing shows what's happening:

SELECT WorkItemId, UserId, Status, RequestDateTime, AcceptDateTime
FROM AgentWork
WHERE CreatedDate = TODAY
ORDER BY RequestDateTime DESC

If requests exist but accept times are empty, your offers are timing out or being declined. That points at capacity, push time-out or agent behaviour, not at the routing model.

Pre-launch checklist for Salesforce Omni-Channel

Run this before go-live, with a real agent login, not your admin account.

• Omni-Channel enabled; skills-based routing on only if you use it.
• Service channel exists for every object you route.
• Every queue has a routing configuration, supported objects and members.
• Every presence status lists the right service channels.
• Presence configuration and capacity set; users have access to their statuses.
• Omni-Channel utility is visible in the console for agents.
• Route Work flow tested with at least five realistic records, including edge cases.
• A fallback queue exists, and someone owns it.
• AI escalation paths tested end to end, with context visible to the human.
• Reports or an AgentWork query ready to check speed-to-answer in the first week.
• Supervisors know how to see queue backlogs and reassign work.

If you're building a service career around this, the Salesforce Admin certification plan covers the fundamentals that sit under all of this.

Try this week:

• Draw your current routing on one page: channel, queue, routing configuration, who receives it. Mark every gap.
• Log in as a test agent and see whether a test case actually reaches you.
• Pick one low-risk topic to route to an Agentforce agent, and define its escalation queue.
• Run the AgentWork query above and look at your accept rate.

If you want a second pair of eyes on a routing design, get in touch.

Frequently asked questions

What is Salesforce Omni-Channel?

It's Salesforce's routing capability for Service Cloud and related products. It pushes work items such as cases, chats and messaging sessions to agents based on availability and capacity. Agents see offered work in the console and accept or decline it.

What is the difference between queue-based and skills-based routing?

Queue-based routing sends an item to a queue and offers it to a member with capacity. Skills-based routing attaches skill requirements to the item and matches it to agents who hold those skills. Queues are simpler; skills are more precise but need ongoing maintenance.

Why aren't my Omni-Channel work items being assigned?

Check the usual suspects first: the presence status doesn't include the service channel, the queue has no routing configuration, the agent has no capacity left, or the agent lacks access to the status. Querying AgentWork and PendingServiceRouting shows where items are stuck.

Does Omni-Channel work with Agentforce?

Yes. An Omni-Channel flow can route incoming conversations to an Agentforce service agent where your release supports it, and the agent's escalation can route to a queue, skill-matched agent or specific person. Verify the exact options in Salesforce Help for your release.

Do I need Omni-Channel to use Agentforce for service?

Not for every scenario, but if you want customers handed from an agent to a human with context, you'll want Omni-Channel in the path. Without it, escalation tends to become manual and inconsistent.