Case Routing in Salesforce: How to Assign Cases by Skill, Workload and SLA Without Apex

An unowned case is not a queue item. It's a customer waiting, an SLA clock running, and - in most support orgs - a number that only becomes visible once it's already gone red.

‍

Salesforce gives you plenty of tools for getting cases to agents. What it doesn't give you, out of the box, is a single place to express the three things that actually determine a good assignment: skill, workload and SLA. This article covers how to combine them, in what order to build them, and how far you can get declaratively before Apex becomes the answer.

‍

For the broader picture, our guide to routing cases in Salesforce covers the full landscape. This one goes deep on the three-variable model.

What is case routing in Salesforce?

Case routing in Salesforce is the automated assignment of incoming Cases to the queue, agent or team best placed to resolve them - evaluated against the case's attributes (type, product, priority, channel, entitlement), the agent's capability and current capacity, and the service-level target attached to the case.

‍

Case assignment is the act of setting an owner. Case routing is the decision system that determines what the owner should be. The distinction matters because Salesforce's native tooling is much stronger at the first than the second.

Why Assignment Rules run out of road.

Case Assignment Rules are the default starting point, and they're genuinely fine for simple orgs. Four structural limits determine when you outgrow them:

‍

One active rule, first match wins. Only one case assignment rule can be active at a time, and evaluation stops at the first matching entry. Rule order becomes load-bearing, and a rule set that started as twelve entries becomes an ordering puzzle nobody wants to touch by entry ninety.

‍

No capacity awareness. Assignment Rules will happily hand a fourteenth case to an agent already drowning while a colleague sits at two. The rule can only see the case record; it has no view of the agent's queue.

‍

No availability awareness. Rules don't know who is on shift, on lunch, on leave or in another timezone. A case routed to an agent who logged off four hours ago is technically assigned and practically abandoned. This is the same problem as routing by availability on the sales side.

‍

Stateless and one-shot. They fire on creation (and optionally on update) and then they're done. They don't monitor the case, don't notice it hasn't been accepted, and don't re-route when priority escalates.

The three variables, in build order.

Build them in this sequence. Each one depends on the one before it, and teams that start with SLA rules on top of a vague skills model end up with alerts they can't act on.

1. Skill: can this agent solve it?

Start with the taxonomy, not the routing. You need a case classification that maps cleanly to agent capability: product or module, technical domain, language, customer tier, and any compliance or certification constraint. Then build the skills matrix that maps agents to those dimensions, with proficiency levels rather than a binary yes/no.

‍

The trap here is over-specification. Require four skills at high proficiency and you'll create a case that exactly one person in the company can take - which is fine until they're on leave, at which point the case sits in a queue nobody is watching. Design a fallback ladder from day one: ideal match, acceptable match, any qualified agent, general queue with escalation. Our skills-based routing guide goes into the matrix design in detail.

2. Workload: can they take it right now?

Workload is where declarative case routing usually gets abandoned, because it needs state that Assignment Rules don't have. Three things to model:

‍

• Capacity units, not case counts. A password reset and a data-corruption escalation are both "one case" and nothing like the same load. Weight cases by expected effort - Omni-Channel's capacity model supports this, and it's the single highest-value refinement most support orgs are missing.
• Availability windows. Working hours, shift patterns, timezone, break status, presence. An agent who is technically logged in but on a two-hour call is not available.
• Rebalancing behaviour. What happens when a case is assigned to someone who then goes offline without accepting it? A timed reassignment - accept within N minutes or the case returns to the pool - prevents the most common silent failure in case routing.

3. SLA: when does it have to be answered?

Entitlements and Milestones give you the SLA framework natively. The mistake is treating them purely as measurement. Your SLA target should be an input to the routing decision, which means:

‍

• Tier your targets by customer entitlement and case priority, and store the target on the case so routing can read it.
• Route the tightest clock first. When a queue has depth, order by remaining SLA time, not creation time. FIFO is fair; SLA-weighted is correct.
• Escalate before the breach, not at it. An escalation that fires at 100% of the window is a notification of failure. Fire at 60% and 85% to a different destination - a senior agent, a team lead, a broader queue.
• Handle out-of-hours explicitly. A case arriving at 22:00 against a four-hour business-hours SLA needs a defined behaviour: follow-the-sun handoff, on-call routing, or a clock that pauses. Choose one, because the alternative is a breach nobody could have prevented.

‍

Case Assignment Rules

Covers: nothing beyond basic field-based matching
One active rule, first-match, stateless. Fine for simple, stable routing.

Omni-Channel

Covers: skill (skills-based routing) · workload (capacity, presence) · SLA in part
The strongest native option. Configuration is spread across presence statuses, routing configurations, service channels and skills — expressive, but a lot of surface to maintain.

Flow

Covers: skill if you build it · workload in part · SLA with Milestones
Can orchestrate almost anything. You're building and owning the logic, and complex routing Flows become fragile as the rule set grows.

Entitlements & Milestones

Covers: SLA only
Defines and tracks the target. Doesn't influence which agent gets the case.

Distribution Engine

Covers: skill · workload · SLA
Expresses all three in one rule set, with re-routing, availability and a full audit log.

‍

Doing it declaratively: what each native tool covers.

The honest summary: you can get skill and workload from Omni-Channel and SLA from Entitlements, and you can bridge them with Flow - no Apex required. What you end up maintaining is a routing decision distributed across four configuration surfaces, where changing one team's coverage means touching three of them. That's the real cost, and it's a maintenance cost rather than a capability one.

‍

Distribution Engine consolidates the three variables into a single declarative rule set: skills and proficiency, weighted capacity and working hours, SLA-aware ordering and escalation, timed re-routing when a case isn't accepted, and an audit log showing why every case went where it did. Same objects, same org, one place to change the rules. For service teams, our service use case page covers the wider triage picture.

The failure modes worth designing against.

• The orphaned case. Assigned to an agent who never accepts it, sitting in a personal queue that no dashboard reports on. Fix with timed acceptance and automatic return to pool.
• The specialist bottleneck. One agent holds a rare skill; every case needing it queues behind them. Fix with fallback ladders and a deliberate cross-training plan that your skills matrix actually reflects.
• The reopened case that re-routes. A customer replies to a closed case, it reopens, and routing sends it to a new agent with no history. Sticky ownership on reopen should be the default, with a fallback if the original agent has left.
• Priority escalation mid-life. A P3 becomes a P1 on hour six. If routing only ran at creation, the case is now in the wrong place with the wrong clock. Re-evaluate on priority change.
• Queue depth invisibility. Cases sitting unassigned in a queue are usually invisible until someone complains. Monitor queue age percentiles, not averages - the mean is dragged down by the easy wins.

‍

Several of these overlap with the patterns in our piece on common case management mistakes.

Measuring case routing, properly.

• Time to assignment - creation to owner set. Should be seconds. If it's minutes, routing is running in a batch or a Flow is retrying.
• Time to first response - the number customers actually feel.
• SLA attainment by tier - split by entitlement and priority; an aggregate figure hides the tier that's failing.
• Reassignment rate - cases that changed owner before first response. Above roughly 15% and your skills model or your capacity model is wrong.
• Capacity variance - spread of active load across agents on the same team. Wide variance means workload routing isn't working, regardless of what the assignment counts say.
• First contact resolution by skill match - the payoff metric. If routing to the right skill isn't improving FCR, your skills taxonomy doesn't reflect what actually makes cases hard.

The bottom line: three variables, one rule set.

Case routing gets difficult when the three inputs live in three systems. Skill sits in an Omni-Channel config, workload lives in the agents' heads, and SLA sits in a dashboard that reports what already went wrong. None of that requires Apex to fix - it requires deciding that skill, workload and SLA are one decision rather than three, and building the routing that treats them that way. Get the taxonomy right, weight your capacity honestly, make the SLA an input, and define every fallback before you need it.

Fancy giving Distribution Engine a try?

You can trial Distribution Engine for free, or get in touch if you'd prefer to chat.

Related articles

• How to Route Cases in Salesforce in 2026
• Common Case Management Mistakes (and How Sales & RevOps Leaders Can Avoid Them)
• What is Salesforce Workflow Automation? Complete Guide for 2026
• Route Leads by Availability: Mastering Team Hours in Salesforce

Frequently asked questions.

How do you route cases in Salesforce by skill?

Skills-based case routing is configured through Omni-Channel: define skills, assign them to agents with proficiency levels, and attach required skills to cases through Flow or field-based logic so the routing engine only offers each case to qualified agents. Always define a fallback for cases where no qualified agent is available, or the case will sit in the queue indefinitely.

Can you do case routing in Salesforce without Apex?

Yes. Omni-Channel handles skills and capacity declaratively, Entitlements and Milestones handle SLA tracking, and Flow can orchestrate the logic between them. The trade-off is maintenance rather than capability - the routing decision ends up spread across several configuration surfaces, so a single change to team coverage means editing in multiple places. A dedicated routing tool consolidates all three into one rule set.

What's the difference between Case Assignment Rules and Omni-Channel routing?

Case Assignment Rules are stateless and field-based: one active rule, first matching entry wins, no awareness of agent workload or availability. Omni-Channel is a live routing engine that considers agent presence, capacity and skills, and pushes work to agents in real time. Assignment Rules suit simple, stable routing; Omni-Channel suits environments where who is available and how busy they are should influence the decision.

How should SLA affect case routing?

SLA should be an input to routing, not just a reporting layer. Store the target on the case, order queues by remaining SLA time rather than creation time, and set escalation triggers at around 60% and 85% of the window so a senior agent or wider queue picks the case up before it breaches. Define out-of-hours behaviour explicitly, otherwise overnight cases breach through no fault of any agent.

How do you stop cases being assigned to unavailable agents?

Combine presence-based routing with working hours and a timed acceptance rule. Only route to agents who are present and within their shift, and if an assigned case isn't accepted within a defined window, return it automatically to the pool for reassignment. Without that timeout, a single agent logging off mid-shift silently strands every case sitting in their personal queue.

‍