Every support team I have worked with has a service promise written down somewhere. Two-hour first response on priority cases, next-business-day resolution for everything else — it lives in a contract, a slide deck, or a laminated sheet taped up next to the coffee machine. And almost none of those teams could tell me, on any given afternoon, which of their open cases were about to break that promise.
That gap is what service-level agreements in Dynamics 365 Customer Service are for. Not the PDF kind — the kind that sits on the case itself, counts down in front of the agent, warns before the deadline slips, and records whether you kept your word. In this post we will build one end to end: the KPI, the SLA, the warning actions, and — the part most implementations skip — the timer on the case form. Because an SLA without a timer is a promise filed in a drawer.
Why the Usual Approaches Fall Short
Most teams try to police response times with tooling that lives outside the case. A view sorted by Created On, with agents doing mental math against the priority column. A dashboard the team lead checks twice a day. A cloud flow someone built that emails “this case is getting old” — a smoke alarm with no address.
All of these share the same flaw: the deadline is somewhere other than where the agent is working. The agent is in the case, and the countdown is in a report. A deadline nobody can see is a deadline nobody hits.
The SLA feature closes that gap because Dataverse tracks the clock per case, per KPI, pauses it when you are waiting on the customer, and surfaces it as a live timer on the form. Let’s build it.
Prerequisites
- A Dynamics 365 Customer Service license (Enterprise or Professional) and access to the Copilot Service admin center — the app formerly known as the Customer Service admin center. Same rooms, new name on the door.
- The CSR Manager security role (or equivalent create permissions on SLA, SLA KPI, and SLA KPI Instance).
- Optional but recommended: a customer service schedule (business hours), so a case created Friday at 4:55 PM does not fail its SLA over the weekend.
- As always, build and test in a sandbox first. Mine is my demo environment; yours should not be production.
Step 1 — Decide What You Are Actually Promising
Before touching the admin center, write the promise as one sentence with two numbers: “High-priority cases get a first response within 4 business hours; we want a warning at 2.” Every configuration choice below falls out of that sentence — the KPI (first response), the entity (case), the audience (high priority), the warn time, and the fail time. If you cannot write the sentence, you are not ready to configure the SLA, and no amount of clicking will fix that.
Step 2 — Create the SLA KPI
An SLA KPI is the measurable thing you are timing. Out of the box, the case table already carries lookup fields for the two classics — First Response By KPI and Resolve By KPI — so for cases you do not need to create any fields.
In the Copilot Service admin center, go to Service terms, and under SLA KPIs select Manage. Select New and fill in:
- Name: First Response By KPI
- Entity Name: Case
- KPI Field: First Response By KPI
- Applicable From: Created On — this is the moment the stopwatch starts, so choose deliberately. Created On is the honest choice for a first-response promise.
Select Activate. A draft KPI does nothing; an active one is measuring.
Step 3 — Create the SLA and Its SLA Item
Back under Service terms, open Service level agreements and select New. Give it a name, set the Primary Entity to Case, and save. The SLA is just the folder; the rules live in SLA items.
Select New SLA Item and work through the form:
- KPI: the First Response KPI from Step 2.
- Allow Pause and Resume: Yes, if waiting-on-customer time should not count against you. Decide now — this toggle locks after the first save.
- Business Hours: your customer service schedule, so warn and fail times are computed in working hours.
- Applicable When: Priority equals High. This is the audience filter. Leave it empty and the item applies to every case the SLA covers — legitimate, but do it on purpose.
- Success Conditions: First Response Sent equals Yes. The clock stops when this becomes true.
- Warn and Fail Duration: warn after 2 hours, fail after 4.
⚠️ Important: if the Applicable When condition stops being true after the SLA has triggered — say someone downgrades the priority — the KPI instance is canceled, not failed. That is usually what you want, but it also means a priority downgrade quietly releases the promise. Govern who can edit priority accordingly. Presentation is not protection, and neither is a form field anyone can change.
Step 4 — Wire Up the Warning Actions
On the SLA item, select Configure Actions. This opens a predefined Power Automate flow with three branches: Is Nearing Non-Compliance, Is Succeeded, and Is Non-compliant. Add your actions inside the branches — the classic move is an email to the case owner in the warning branch and one to the queue supervisor in the failure branch.
⚠️ Important: add steps inside the branches, but do not restructure the flow itself — the condition skeleton is how the SLA engine talks to it. Treat it like rented scaffolding: hang what you like on it, do not weld new beams.
Resist the urge to notify everyone about everything. If every case emails three people twice, the mailbox rule that deletes them gets written by Friday. The timer on the form (Step 6) is the everyday signal; email is for the moments a human must intervene.
Step 5 — Activate and Apply
Back on the SLA record, select Activate. An active SLA still applies to nothing until you connect it to cases, and you have two options:
- Set as Default on the SLA record — it now applies to every new case in the organization. Broad, simple, and the right starting point for most teams.
- Entitlements — attach the SLA to specific customers’ entitlements when different customers have bought different promises. Gold gets 2 hours, standard gets 8, and the system keeps the two stories straight.
Note that SLAs attach when a case is created (or when its entitlement is set); activating a new SLA does not retroactively time cases that already exist.
Step 6 — Put the Timer Where Agents Live
This is the step that earns the title of this post, and it is the one I see skipped most often. The SLA can be measuring perfectly and the agent still sees nothing — you have built a scoreboard and hung it facing the wall.
Open the Case main form in the form designer (from your solution — mine lives in a demo solution, yours should live in yours, unmanaged in dev and managed everywhere else). Add a Timer control where the agent’s eye lands, and bind it to the First Response By KPI: the failure time comes from the KPI instance, success is First Response Sent equals Yes, and the warning ties to the nearing-non-compliance state. Save and publish, and every covered case now shows a live countdown that turns yellow at warn and red at fail.
Limitations and Good Habits
- Pause and resume is a day-one decision per SLA item — you cannot flip it later without recreating the item.
- Business hours change the math. A 4-hour SLA against a 9-to-5 calendar can legitimately resolve tomorrow. Explain this to whoever reads the compliance report, before they read it.
- Keep KPIs few. First response and resolution cover most service promises. Every extra KPI is another clock the agent must reconcile, and ten timers on a form is the same as none.
- Watch the canceled instances. A spike in canceled KPI instances usually means someone found the priority-downgrade loophole.
Wrapping Up
The promise your team makes to customers already exists — in the contract, on the slide, by the coffee machine. What we built here moves it onto the case, gives it a clock, and makes it visible at the exact moment an agent decides what to work on next. The configuration took six steps; the behavior change comes from the timer. Deals may age like fruit, but service promises age like milk — the whole point is knowing the date before it turns.
