SLA definitions and KPI items

What it does

An SLA is a container record holding a set of SLA items. Each item pairs an SLA KPI (a datetime target such as First Response By or Resolve By) with an Applicable When filter, success criteria, a warning duration and a failure duration. When a record matches, the platform spins up an SLA KPI Instance and counts down against the SLA's business hours.

Key facts

Two types exist. Standard SLAs work only on Case, do not support pause and resume, and write their timings to datetime columns on the case itself. Enhanced SLAs work on any SLA-enabled table, support pause and resume, and track state in SLA KPI Instance records.
SLA Type is forced to Enhanced for anything other than Case. On Case you can still pick Standard, but there is no good reason to on a new build.
SLAs authored in the legacy web client are deprecated. Author in Unified Interface, under Service terms in the Copilot Service admin center, and migrate anything inherited.
Applicable From is set once on the SLA record, not per item. Every KPI in that SLA starts its clock from the same column, so a "response from creation, resolution from first assignment" design needs two SLAs, not two items.
Applicable From, warning and failure columns must be DateTime datatype. Date-only columns are rejected.
For any given KPI, only the first matching SLA item applies. Later items with overlapping Applicable When conditions never fire.
Microsoft recommends no more than 15 SLA items per SLA for performance, and documents a practical ceiling of around 100. Treat 15 as the real number.
Tables enabled for SLAs out of the box include Account, Contact, Lead, Opportunity, Quote, Order, Invoice, Email, Phone Call and Appointment, alongside Case. Recurring appointments are excluded.
A custom table needs the "Setting up service level agreements" table property ticked plus a lookup column to SLA KPI Instance before any SLA item will bind to it.
Do not customise the SLA, SLA KPI or SLA Item forms. They are configuration surfaces, and customising them is explicitly called out as unsupported.

When to use / skip

If the client has a support contract with response and resolution commitments, you need this. There is no sensible way to hand-roll countdown timers that respect business hours, holidays and on-hold periods, and every attempt to do so with flows and calculated columns ends badly.

Skip SLAs where the client's "SLA" is really an internal aspiration nobody reports on. In that case a view sorted by age costs nothing and breaks nothing. Also skip them on tables where the commitment is genuinely per-customer rather than per-record type — that is what entitlements are for, and you attach the SLA to the entitlement instead.

Be sceptical of SLAs on non-Case tables. They work, but the agent-facing timer control and the analytics are built around cases, so on Lead or Opportunity you are doing more custom work than the demo suggests.

Configuration decisions

Which KPIs you actually track. First Response By and Resolve By ship with Case; anything else means a custom datetime column plus a custom SLA KPI Instance lookup, created before you can reference it.
The Applicable From column per SLA, and therefore how many separate SLA records the design needs.
How you segment: one SLA with many items filtered by priority and customer type, versus several SLAs selected by entitlement. Segmenting by entitlement usually ages better.
Whether pause and resume is on. This is set on the SLA item and cannot be changed after the item is first saved.
Which business hours schedule the SLA points at, or whether it runs 24/7 by leaving it blank.
Success criteria that are genuinely observable in data. "Customer happy" is not a success condition; "First Response Sent equals Yes" is.

Gotchas

Allow Pause and Resume is effectively a one-way door on an SLA item. Decide before the first save, or rebuild the item.
If Applicable When and Success Criteria contradict each other, the SLA cancels itself the moment it applies. The classic version is Applicable When "Status equals Active" with Success Criteria "Status does not equal Active".
Putting a frequently updated column in Applicable When causes constant cancellation and re-creation of KPI instances. Keep those conditions on stable fields.
Activating an SLA generates background workflows. If those are left unpublished — common after a solution import — the SLA silently never applies.
Standard and enhanced SLAs report differently. Standard writes onto the case, enhanced writes onto SLA KPI Instance. Any reporting built on case columns quietly stops working when you migrate to enhanced.
Item ordering matters and is not obvious in the UI. Put the narrowest Applicable When first.

Consultant notes

Get the client to write down the actual contractual wording before you configure anything. Half the time "4 hour response" turns out to mean four working hours in the customer's time zone, not yours.
Demo the SLA timer on a case rather than the admin screens. Nobody signs off on an SLA item form.
Push back hard on more than a handful of items per SLA. It is the single most common cause of "cases are slow to save".
Before go-live, check that every SLA is Active, its workflows are published, and the Applicable From column is populated on real data — a null there means no SLA, with no error.

Worth another look if Microsoft finally retires standard SLAs outright, or if the supported-table list grows.