Support-desk surprises usually have short explanations, because every decision the engines make is driven by a record you can read: the queue, the agent's presence, the SLA policy, the calendar. This page works through the two complaints that cover most tickets — a case that won't route, and an SLA clock behaving unexpectedly — plus the quick answers to the common lifecycle refusals. In each case, find the authoritative record and read it before changing anything.
Read the routing evidence
- 1
Total and Active Queue count configured versus operationally enabled queues.
- 2
Channel Coverage summarises the Channel Types field, which is documentation only: routing never rejects work for arriving on an unlisted channel.
- 3
Resource Group is the first record to open when nobody can be found: check membership, active flag, user link, presence and capacity of each member.
- 4
Routing Model decides ranking (RoundRobin, LoadBalance, Skill, Direct); a Skill queue only filters when the request supplies a required skill.
- 5
Active: inactive queues drop out of membership checks and the snapshot, but an explicitly supplied inactive queue is still routed.
Start a routing diagnosis at the queue register. Resource Group identifies the candidate pool and Routing Model controls selection. Channel Types documents intended ingress but is not validated by the current route service. Active controls active-queue membership and snapshot visibility, but an explicitly selected inactive queue is not rejected solely for that flag. These boundaries matter: verify which queue the caller actually supplied before diagnosing agent state.
Filter to the intended queue, then inspect resource-group membership, each resource-to-user link, the exact required skill supplied by the caller, current presence lease and remaining capacity. Finally open the Resource Work record to see whether it is Pending, Assigned, Accepted, Declined or Transferred. The queue list is configuration evidence; the work record is the evidence of what routing actually attempted.
A case won't route (or stays with the old owner)
Routing offers work; it never forces it. When a routed case seems to go nowhere, walk these checks in order and stop at the first that fails:
Check 1 — Was there a queue to route to?
Routing needs the case's queue field, or a queue (or named agent) chosen when the Route action ran. No queue, no routing — the action says so explicitly. Set the case's queue, or have your automation supply one.
Check 2 — Is the queue alive and staffed?
The queue must name a resource group — without one there are no candidates. For ordinary operation keep it active and remove inactive queues from ingress rules, but note that the current service still processes an explicitly supplied inactive queue. Then inspect the pool: each routable agent must be an active resource linked to a user account. An unlinked resource is skipped because case ownership could not be stamped on acceptance.
Check 3 — Is anyone Available?
Only agents whose presence is Available and whose 300-second presence lease is still live qualify. A staffed queue where every lease is offline or expired creates Pending work. The routing snapshot API reports effective presence and queue backlog; the web Supervisor Console currently focuses on telephony calls rather than generic Resource Work.
Check 4 — Does anyone have capacity?
Each agent has a maximum concurrent workload, and an offer only goes to an agent whose current Assigned or Accepted load plus the new item's weight fits. When the pool is at ceiling, the work is created as Pending. Changing capacity later does not automatically sweep that backlog; routing or reassignment must be invoked again.
Check 5 — On a skill-routed queue: does anyone have the skill?
The filter applies only when the request supplied requiredSkill. It requires an exact Resource Skill name at proficiency 1 or higher on an available, in-capacity member. There is no separate skill catalog. If no required skill was supplied, a Skill queue behaves as least-load selection rather than refusing unskilled agents.
Still with the old owner after all that?
Then inspect whether the work item has been accepted. Ownership transfers on acceptance, not on offer — a case whose Resource Work sits Assigned keeps its previous owner. The generic accept/decline/transfer/reassign APIs exist, but the current telephony Supervisor Console is not a general case-work inbox, so confirm which approved UI or integration exposes those operations in your tenant.
The SLA clock did something unexpected
The due time is later than the target arithmetic suggests
Targets count working minutes on the policy's business-hours calendar: non-working hours, non-working days and linked holidays don't count, and neither does time spent paused (resuming shifts deadlines forward by the paused working time). Recompute against the calendar before doubting the clock. The opposite surprise — deadlines tighter than expected — usually means the policy has no calendar (24×7) or the calendar has no working days configured, which is also treated as 24×7.
The clock didn't pause while the case was waiting
Which statuses pause the clock is per policy — the matched policy's pause-status list, with On Hold, Waiting on Customer and Waiting on Third Party as the default when the list is empty. If the case's waiting status isn't on the matched policy's list, the clock legitimately ran. Check which policy attached (it is on the case) and read its list. Conversely, a clock that "mysteriously" resumed usually moved to an active status — escalating, for instance, resumes a paused clock deliberately.
The wrong policy attached — or none did
Policies are tried from highest rank down; the first active policy whose match formula evaluates true against the case wins, and an empty formula matches everything. A catch-all at too high a rank shadows every specific policy below it. No policy attaching means no active policy matched — check active flags and formulas. And remember: matching happens once, at case creation; policy edits change future cases only, never running clocks.
Warning or breach seems late, or a case escalated itself
Warning and breach transitions are applied by a background check, so a badge flips shortly after the threshold rather than at the exact second. And a breach automatically marks the case escalated (the flag, not the status) — so escalated cases nobody escalated are the SLA engine surfacing broken promises. The case's Case SLA Event records hold the exact entry.
Quick answers to lifecycle refusals
- Can't resolve: the resolution summary is required — fill it.
- Can't close: the close reason is required — fill it.
- Can't reopen: Reopen is accepted only from Resolved, Closed or Cancelled.
- A transition is blocked with everything filled: a tenant-authored status-transition business rule forbids it — ask your administrator which.
- No acknowledgement email reached the customer: without a contact email the acknowledgement is recorded as Draft. With an address it is recorded as Sent before best-effort post-commit dispatch; that status is intent, not delivery proof. Check the address and the outbound mail provider's evidence.
- A whole action or button is missing: that's an access question, not a support-desk one — work through the access triage.
Common questions
Where do I see everything the SLA engine did to a case?
In the case's Case SLA Event records, which log policy application, every pause and resume with timestamps, warnings, breaches, cancellations and milestones met (including met late). They are separate from the Activities timeline, which only carries status changes, assignments and logged activities; open the Case SLA Event list filtered to the case (or a related list on the case layout) — between those events, the SLA tab fields and the timeline, no SLA question about a case should require guesswork.
Pending work is piling up in a queue — what are my options?
Use the routing snapshot API or Resource Work list to distinguish expired/offline presence, exhausted capacity and an undersized group. Freeing capacity or going Available makes an agent eligible for the next selection but does not automatically reroute existing Pending work; invoke an exposed route/accept/reassign workflow. The checked-in Supervisor Console is telephony-specific.
Why did a declined case go to another agent instead of back to the queue?
Because decline immediately calls routing again while excluding the decliner. If nobody else qualifies, the replacement work is Pending. The current decline path does not carry the original required skill into that reroute, so verify the new offer when skill matching matters.