An SLA policy in xMatix is a promise with a clock: respond within so many working minutes, resolve within so many more. The moment a case is created, the engine picks the best-matching active policy, computes the due date-times against a business-hours calendar, and creates a milestone per promise to track it. From then on the clocks run themselves — pausing when the case waits on someone else, warning before a deadline, recording a breach when one passes — and every event is stored against the case as a Case SLA Event you can read back.
Where to find it
SLA policies are ordinary records: open SLA Policies from the navigation of the app that hosts your support desk (in the demo tenant it sits in the CRM app), or search for it in the App Launcher. Business hours, holidays and custom milestones are separate records in the same app. Field-by-field meanings are in the support configuration reference; this page explains how the engine uses them. Reading and editing policies requires the SLA Policy entity permissions on your security profile, and the case-side fields (SLA Policy, SLA Status, due and achieved dates) need read access on Case.
Read the screen
- 1
Summary cards count total and active policies and average the response and resolution targets in minutes.
- 2
Rank: active policies are tried from the highest rank down; Default breaks ties between equal ranks.
- 3
Match Formula is an expression over the case (here Priority and Type); the literal true, or a blank formula, matches every case, so keep such catch-alls at a low rank.
- 4
Pause Statuses lists the case statuses that stop this policy's clock; blank means the built-in waiting statuses apply.
- 5
Warning %, First Response and Resolution minutes create the milestones; a zero target means that milestone is not tracked.
- 6
Active and Default: only active policies are matched; exactly one low-rank default with a blank formula makes a safe catch-all.
Start in All SLA Policy, where the list exposes every column that matters at once: business-hours calendar, rank, pause statuses, match formula, warning threshold, first-response and resolution targets, active state and default flag. The summary cards count total and active policies and average the targets. Use this view to audit overlap before creating another policy: two active policies with the same rank whose formulas both evaluate true are separated only by the Default flag, so a register with several true formulas at different ranks is a deliberate ladder, not an accident. A policy appearing here proves configuration exists, not that it matched a particular case.
- 1
Business Hours names the calendar (time zone, working days, daily window, linked holidays) every target is computed against; none means 24x7.
- 2
Match Formula is evaluated against the new case; this one only claims High-priority Product Issue cases.
- 3
First Response and Resolution are working minutes from case open (240 = 4 working hours, 4320 = 9 working days on an 8-hour calendar).
- 4
Pause Statuses is empty here, so the built-in waiting statuses (On Hold, Waiting on Customer, Waiting on Third Party) pause the clock.
- 5
Warning % (80) sets the point at which a milestone flips to Warning: at 80% of the target's working minutes.
- 6
Active and Default checkboxes; Rank is not on this layout, so check it in the list view when two policies could both match.
Open a policy to verify its Key Information — match formula, first-response and resolution minutes, pause statuses and warning percentage — together with the business-hours calendar in the header and the Active and Default controls. Rank is not on the default record layout; read it from the list. Review formula and rank as one selection rule, then check the time targets against the named calendar. Editing a policy changes which future cases match and when they breach; cases that already carry it keep their existing attachment and due dates.
The New SLA Policy form opened from the list's New button carries Name, Business Hours, Match Formula, First Response (min), Pause Statuses, Warning % (defaulting to 80) and the Active/Default controls. Rank and Resolution (min) are not on that create layout, so set them afterwards — inline in the list or on the saved record — before you rely on the policy.
How a policy is chosen
Each policy has a match formula — an expression evaluated against the case, such as Priority == "High" && Type == "Product Issue" — and a rank. At case creation, active policies are tried from the highest rank down, with Default breaking equal-rank ties, and the first whose formula evaluates true wins. A blank formula, or the literal true, matches every case, so keep a catch-all at a low rank. A formula that fails to evaluate (for example, it names a field that does not exist) is treated as false, and the engine moves to the next policy. The chosen policy is stamped on the case and is not re-matched later; if no policy matches, the case simply has no SLA status.
When the policy attaches, its business-hours calendar is copied to the case's Business Hour field unless the case already names one, and the case's SLA Status starts at OnTrack.
Milestones
Two milestones are built in, each enabled by giving it a target in working minutes (zero means not tracked):
- First response — met the first time the case moves into In Progress (which stamps the first-response time), or whenever the first-response date is otherwise recorded.
- Resolution — met when the case moves to Resolved (which stamps the resolution date).
Beyond these, a policy can define custom milestones (Milestone Config records): each has its own target in working minutes from case open, an optional warning percentage (falling back to the policy's), an order, an active flag and a completion formula. On every save of the case the completion formula is evaluated, and the milestone is marked Met the first time it is true. A custom milestone with no completion formula can only end by cancellation when the case closes, so always give it one.
Each milestone moves through Pending → Warning → Breached, or to Met when completed; it is Paused while the clock is stopped. Meeting a milestone after its deadline sets its status to Met and keeps its breach flag set; closing or cancelling a case cancels milestones that are still open.
The case-level SLA Status is a rollup of milestone statuses: Breached if any milestone is breached, else Warning, else Paused, else OnTrack while anything is open, and Met once nothing is open. Because the rollup reads statuses rather than the late flag, a case whose milestones were all met late reads Met; inspect the milestone's breach flag or its met (late) event for reporting on late completions.
- 1
A Sense nudge announces the first-response breach for this case number with the due time in UTC; Open case jumps to the record.
- 2
The SLA tab groups the policy fields (SLA Details) and the milestone dates (SLA Dates) of this case.
- 3
SLA Status is the case rollup of its milestones: OnTrack, Warning, Paused, Breached or Met. The SLA Policy lookup beside it names the matched policy when one attached at creation.
- 4
Escalated is set automatically when the rollup turns Breached, so escalation business rules can react.
- 5
First Response Due is the deadline computed in working time at case creation; First Response Date stays empty until the case first moves to In Progress.
- 6
Stopped Since records when the clock was paused (by a waiting status or Pause SLA); on resume the due dates shift by the working minutes paused.
On an actual case, the SLA tab is the applied evidence. SLA Details holds the SLA Policy lookup (the matched policy, when one attached at creation), the SLA Status rollup, the Business Hour calendar and the Escalated flag; SLA Dates shows First Response Due, First Response Date, Resolution Due, Resolution Date and Stopped Since. Diagnose a disputed deadline from these fields and the case's SLA events; the policy list alone cannot tell you what attached or what happened after attachment.
Business hours and holidays
Every due date is computed in working time, not wall-clock time, against the business-hours calendar named on the policy. A calendar defines a time zone, working days and a daily working window; a policy with no calendar runs 24×7. Holidays linked to a calendar are skipped entirely — a four-working-hour target starting an hour before a holiday weekend lands three hours into the next working day, not on the weekend.
Pauses are measured the same way: when a paused case resumes, each deadline moves forward by the working minutes the case sat paused, and the case's First Response Due and Resolution Due are updated to match.
Pausing and resuming the clock
The clock pauses two ways:
- Automatically by status. Each policy lists the statuses that stop its clock; when the list is empty the built-in waiting statuses — On Hold, Waiting on Customer, Waiting on Third Party — pause, and returning to an active status (New, Assigned, In Progress, Escalated, Reopened) resumes. The list is per policy, so a strict policy can keep the clock running even while a case waits.
- Manually. The Pause SLA and Resume SLA case actions stop and restart the clock explicitly, for situations the status list does not capture. They are also available as steps in a case macro.
Pausing stamps Stopped Since on the case and moves open milestones to Paused; resuming clears it, shifts the deadlines and returns the milestones to Pending. Every pause and resume is written as a Case SLA Event with its timestamp, and each milestone accumulates the total minutes it spent paused — so a breach dispute can be answered from the record, not from recollection.
How breaches surface
Warnings and breaches are applied by a background job, so a milestone flips to Warning or Breached shortly after its threshold passes rather than at the exact second. A breach does three things: the milestone is marked breached, the case's SLA Status turns Breached, and the case is marked Escalated automatically — so escalation automations your administrator has authored as business rules can react to it. Where Sense AI nudges are enabled, the breach also appears as a nudge banner on the case and in the agent's home feed.
The full trail — policy applied, warnings, pauses, resumes, breaches, milestones met or cancelled — is stored as Case SLA Event records linked to the case and its milestone, each with an event type, a UTC timestamp and a short detail line such as FirstResponse breached (due 2026-08-07 11:30:00Z). These records are not mixed into the case's Activities timeline, which only carries status changes, assignments and the activities agents log; open the Case SLA Event list (or a related list on the case, if your layout includes one) or report on the entity to read them.
Common questions
Why is the due time later than the target suggests?
Because targets are in working minutes. Hours outside the calendar's working window, non-working days and linked holidays do not count, and neither does time the case spent paused. A "4 hours" first response promised late Friday afternoon is legitimately due Monday morning on a Monday–Friday calendar.
The case sat waiting on the customer — why didn't the clock stop?
Check the policy's pause-status list. Which statuses pause the clock is configured per policy; if the status the case sat in is not on the matched policy's list (and is not one of the defaults when the list is empty), the clock keeps running. An agent can always stop it explicitly with Pause SLA.
We changed the SLA policy — why do existing cases still show old deadlines?
Policies attach once, at case creation, and existing milestones keep the due dates computed then. Policy edits govern cases created afterwards. This is deliberate: a promise already made to a customer does not silently move.
Can a milestone be met and breached at the same time?
Yes — met late. The milestone status becomes Met and its breach flag stays true. The case-level rollup can therefore read Met once nothing remains open; reports that distinguish on-time from late completion must inspect the milestone's breach flag or its met (late) SLA event.
The case shows an SLA Status but no SLA Policy — how?
SLA Status is a stored field, so cases imported or created with a status but without going through policy matching can carry one without a policy. Only cases created through the application with an active matching policy have the policy, milestones and events behind the status.