The omni-channel routing service assigns a Resource Work record to an eligible resource. A queue names a resource group and routing model; routing a case through an action or automation creates a work item and either offers it to a selected resource or leaves it Pending. The work record stores its channel, but the current selection service does not validate that value against the queue's Channel Types. The same service can route entities other than Case.
Read the screen
- 1
Routing Model ranks eligible agents: Direct, RoundRobin, LoadBalance (the default shown) or Skill.
- 2
Channel Types documents intended sources (Call, Email, Chat, SMS); routing does not check it, so ingress automation must choose the right queue.
- 3
Resource Group is the agent pool; only its active, user-linked, Available members with spare capacity can be offered work.
- 4
Description: state the queue's business purpose and escalation boundary for the administrators who maintain ingress rules.
- 5
Active controls active-queue membership and the supervisor snapshot; an explicitly selected inactive queue is still processed, so also remove it from ingress rules.
Queues are records: open Queues from your support app's navigation and select New to see the form above. It records the intended business boundary. Resource Group supplies the candidate pool and Routing Model decides how eligible candidates are ranked; when the model is blank, the service uses LoadBalance. Channel Types documents the channels intended for the queue but is not an eligibility check in RouteAsync, so ingress automation must choose an appropriate queue.
The Active control is used by active-queue membership checks and the supervisor snapshot, but the current route service does not reject an explicitly selected inactive queue. Treat deactivation as an operational signal and remove that queue from ingress rules as well. Before enabling it, verify membership, optional skill requirements, agent capacity and presence leases, then route a controlled case and inspect the resulting Resource Work record.
Who is eligible
For an agent to be offered a piece of work, every one of these must hold:
- Membership — the agent belongs to the queue's agent pool (its resource group).
- Active and linked — the agent's resource record is active and linked to a user account (so ownership can be stamped).
- Presence — the agent's presence is Available. Agents set their own presence, optionally with a reason; any other status takes them out of the push rotation without touching work they already hold.
- Capacity — each agent has a maximum concurrent workload, and each work item carries a weight (a case counts one). The offer only goes to an agent whose current open load plus the new item still fits.
- Skill, when supplied — on a Skill queue, the filter applies only when the routing request supplies
requiredSkill; it matches the Resource Skill name exactly with proficiency 1 or higher.
If nobody qualifies, the work record is created as Pending. The service does not run an automatic sweep when presence or capacity later changes; another route/accept/reassign operation must move the work. The supervisor snapshot API reports pending counts, but the current web Supervisor Console is telephony-specific rather than a general Resource Work backlog screen.
The routing models
| Model | How the agent is picked |
|---|---|
| Direct | A routing request with a named directResourceId pushes straight to that resource and bypasses queue membership, active-resource, presence, skill and capacity checks. Merely setting the queue model to Direct does not name an agent; without a direct resource it falls through to least-load selection. |
| Round robin | The eligible agent who was offered work least recently |
| Load balance | The eligible agent carrying the least open load (the default) |
| Skill | Least-load selection, restricted by exact skill name only when the request supplies a required skill; without one it behaves as least-load selection |
Accept, decline, transfer, reassign
An offer is a question, not an assignment — ownership moves only on acceptance:
- Accept — the work becomes the agent's, and for a case this is the moment the case's Assigned To and Owner are stamped to the accepting agent. Until then the case's ownership is unchanged, by design.
- Decline — the work is immediately re-routed, excluding the one who declined. The current decline path does not carry the original required-skill argument into that reroute, so skill-sensitive processes should verify the replacement assignment.
- Transfer — an agent or supervisor moves the work either to a specific colleague (offered to them directly) or back through another queue (re-routed by that queue's model). The original item is closed as transferred and a new offer is created, so the trail shows both legs.
- Reassign — a supervisor re-points a live work item at another agent outright; it returns to the offered state for the new agent to accept.
A work item's status tells you where it is in this dance: Pending (waiting for an agent), Assigned (offered), Accepted, Declined, Transferred, Closed.
Operational visibility
The routing API exposes a supervisor snapshot: pending count per active queue and effective presence, maximum workload and current open load per resource, all as of a timestamp. Reassign is also exposed by the omni-channel API. The checked-in web Supervisor Console visualises live telephone calls and agents; it is not a general Resource Work accept/decline/transfer/reassign console. Use an approved app page or integration over the generic endpoints if your tenant needs that surface.
Agents who staff at least one active queue are eligible for the telephony/messaging workspace dock. That dock should not be read as proof that generic case work offers are rendered there.
Common questions
The case was routed — why does it still show the old owner?
Because routing only offers. Ownership is stamped when the agent accepts; until then the offer can be declined or reassigned without ever having disturbed the record. If a case seems stuck with its old owner, look for its work item still sitting in Assigned (offered, unaccepted) or Pending.
What happens when everyone is busy or offline?
The work item remains Pending against the queue. The snapshot API reports it, but presence and capacity are checked only when routing runs; becoming Available does not by itself trigger a new offer. Explicitly route again, accept/pull it through an exposed workflow, or reassign it.
Can one agent be in several queues?
Yes — queues reference agent pools, and an agent can belong to several. Their capacity is one number across everything they hold, so work from a second queue doesn't overload them: the capacity gate counts all their open items regardless of which queue pushed them.