Support behavior is driven by records you author: queues identify candidate pools, SLA policies decide what is promised, business hours decide how time is counted, optional resource skills narrow routed work, and deduplication rules decide what counts as a duplicate. This page maps the consequential configuration and its current enforcement boundaries.
Queues and agent pools
Queues are managed at Setup → Feature Hub → Service → Telephony → Queues. A queue's fields:
| Field | Meaning |
|---|---|
| Name, description | What agents and supervisors see |
| Routing model | Direct, RoundRobin, LoadBalance (the default when unset) or Skill |
| Channel types | Describes intended channels — email, chat, voice, SMS, web; the current route service does not validate this field |
| Resource group | The agent pool: routing candidates are this group's members |
| Active | Controls active-queue membership and supervisor-snapshot inclusion; an explicitly selected queue is not currently rejected by the route service solely because it is inactive |
The agent pool is a resource group. For each member to be routable, three things must be true of their resource record: it is active, it is linked to a user account (routing stamps case ownership from that user), and its presence is Available at routing time. An agent's capacity — the maximum concurrent work they can hold — lives on their routing profile; the routing engine refuses to push past it.
Agents who staff at least one active queue are eligible for the telephony/messaging workspace dock. The generic routing service exposes snapshot and reassign endpoints, while the checked-in web Supervisor Console is a telephony call console rather than a general Resource Work backlog.
Skills
Skill-routed queues match the Name stored directly on each Resource Skill, with proficiency 1 or higher. There is no separate skill master in this implementation, so govern spelling yourself: matching is exact, and a typo quietly disqualifies the agent. The skill filter runs only when the routing caller supplies a required skill; selecting the Skill model alone does not create that requirement.
SLA policies
SLA policies, their custom milestones, business hours and holidays are records in the CRM settings app. A policy's fields:
| Field | Meaning |
|---|---|
| Active / Default | Only active policies match; default flags your catch-all |
| Match formula | Expression on the case (e.g. Priority == "High"); empty matches every case |
| Rank | Higher rank wins when several policies match |
| Business hours | The calendar due dates are computed against; empty = 24×7 |
| First response minutes | Working-minute target; 0 = not tracked |
| Resolution minutes | Working-minute target; 0 = not tracked |
| Warning percent | How far through a target the Warning fires (default 80) |
| Pause statuses | Comma-separated case statuses that stop this policy's clock |
Design the set as an ordered ladder: specific promises at high ranks, one formula-less default at the bottom. Remember that policies attach at case creation and are not re-matched — edits govern future cases.
Custom milestones extend a policy beyond the two built-in clocks. Each names its policy and defines: a target in working minutes from case open, its own warning percent, an ordering, an active flag, and a completion formula — an expression on the case that, once true, marks the milestone met.
Business hours and holidays
A business-hours record defines the working calendar SLA math runs against: a time zone, the working days, and the daily window (day start and day end). A calendar with no working days configured is treated as 24×7 — so an accidentally blank calendar weakens no promise, it just stops excluding anything.
Holidays are shared records (payroll uses the same entity). For a holiday to count in SLA math it must be linked to the business-hours calendar it blocks — the SLA calculator skips exactly the holidays linked to the policy's calendar, not every holiday in the tenant. Maintain the year's list per calendar you actually promise against.
Duplicate-detection rules
Deduplication rules are authored at Setup → Feature Hub → Platform → DeDuplication Rules and take precedence over the built-in case matcher. The built-in matcher uses contact, account or phone and excludes only status exactly Closed plus already merged records. A rule names its entity, an all/any match logic, and ordered conditions — each a field plus a match method: exact, case-insensitive, starts-with, contains, or first/last-N-characters for fuzzy keys.
Macros and case actions
Macros are authored at Setup → Feature Hub → Service → Macros — see Build and run macros for the builder. Case capabilities are entity actions, so who can execute them is a security profile decision. Remember that a team member's descriptive Access Level does not grant that permission.
Common questions
In what order should a new support desk be configured?
Calendar first, promises second, people third: business hours and holidays, then SLA policies, then resource groups, active resources with user links and presence profiles, then Resource Skill names and queues. Finally configure ingress automation so it supplies the intended queue and, where required, the exact skill name.
Why does the routing model default matter?
A queue with no routing model set behaves as LoadBalance — least-loaded eligible agent. That is a sensible default, but if you intended round-robin fairness or skill gating, set it explicitly; the model is per queue, so different queues can distribute differently.
Can one agent pool back several queues?
Yes — queues reference resource groups, and several queues can share one. Capacity keeps this safe: an agent's workload ceiling counts everything they hold across all queues.