Dynamics 365 Customer Service SLA
- Alfredo Iorio
- Jun 3
- 5 min read
A service level agreement (SLA) in Dynamics 365 Customer Service is a rule set that tells the system when to start a clock and when to mark a case as non-compliant.
What SLAs do in Dynamics 365 Customer Service
A configured service level agreement attaches specific time-bound commitments to a case record and displays them as live countdowns on the form. When an SLA is applied to a case, the system creates SLA KPI instances, records that track the status of each performance indicator for that case.
Those instances drive the timer controls agents see. When a KPI instance reaches its warning threshold, agents and supervisors can be notified automatically via Power Automate. When it reaches the failure threshold without the success condition being met, the status moves to Non-compliant.
Multiple SLA KPIs can be triggered at different points within the same case lifecycle. A case might start a First Response By clock at creation, then a separate
Resolution Planned By clock when it moves into a particular stage, and a Resolve By clock running in parallel throughout. Each SLA KPI is independent (pausing one does not pause another) and each gets its own timer on the case form.
SLA KPI items: First Response By, Resolve By, and custom stages
Out of the box, Dynamics 365 Customer Service comes with two standard KPI fields on the Case entity: FirstResponseByKPI and ResolveByKPI. These cover the two most common commitments in a service level agreement: confirming receipt or first contact, and completing resolution.
When a third stage is needed, for example a "Resolution Planned By" commitment that sits between first response and final resolution, you can create it by adding a custom lookup field on the Case entity that points to the SLA KPI Instance entity. That lookup field becomes the KPI field you select when building the new SLA KPI record.
SLA KPIs can also be built for other entities such as leads or work orders, as long as the entity has SLA tracking enabled and the lookup field to SLA KPI Instance exists.
How SLA timers appear on the case form
The timer controls on a case form are driven by quick view forms embedded in the case layout, each pointing to a specific SLA KPI Instance lookup field.
Each quick view form contains a timer control that shows a countdown while the KPI instance is active, then updates to reflect the final status (Succeeded, Non-compliant) once the instance reaches a terminal state.
Configure SLA KPIs in Copilot Service admin center
Navigate to Copilot Service admin center → Operations → Service terms, then select Manage in the SLA KPIs section. This opens the Active SLAKPIs view. Select New to create a KPI record.
The General tab asks for the KPI field, which determines what you are measuring. Save the record first. The Pause Conditions section only appears after the initial save.
If you are working with the standard Case entity, both standard KPI fields are already available in the list. For a custom stage, you need to create the lookup field first in the entity customisation before it appears here.
After filling in the General tab, set the Applicable From value, configure any pause conditions, then select Activate. A KPI that is not activated cannot be used in an SLA item.
Create and configure an SLA and SLA items
From Copilot Service admin center → Operations → Service terms, select Manage in the Service Level Agreements section. The All Service Level Agreements view lists existing SLA records. Select New, give the SLA a name, select the Primary Entity, and save. The SLA Items section appears after the first save.
An SLA record groups one or more SLA items, each of which connects a KPI to a specific set of conditions and timings.
When the SLA is applied to a case, all applicable items become active.
Allow Pause and Resume: how it works and when to use it
Allow Pause and Resume is a toggle on the SLA item, not on the SLA KPI. When you create a new SLA item, you can find this option on the General tab of the New SLA Item dialogue.
Enabling it means the SLA item's clock pauses when the case record enters a status you have designated as on-hold for that entity. When the record leaves that status, the clock resumes from where it paused.
When an SLA KPI instance is paused and then resumed, the original KPI instance is cancelled and a new one is created. The elapsed time is carried forward, but the instance record itself changes.
Use Allow Pause and Resume when your service commitments exclude time spent waiting on the customer or a third party. If your SLA terms state that resolution time does not count hours when the case is in a "Waiting for Details" status, enabling this setting makes the system reflect that. If your SLA measures elapsed calendar time regardless of case status, leave it disabled.
A common reason to pause is time a case spends waiting in a queue for the right team to pick it up.
To learn more about how queues work in Dynamics 365 Customer Service, see this post: Dynamics 365 Customer Service Queues: What They Are and How Agents Use Them.
Configuring Power Automate actions for warnings and failures
Inside each SLA item, Configure Actions opens a Power Automate flow specific to that item. The Switch step inside that flow has a condition branch for each outcome:
Switch condition | What it triggers |
Is Nearing Non-Compliance | Runs when the warning time threshold is reached. Typically used to send an alert email or escalate the case |
Is Succeeded | Runs when the success condition is met before the failure time. Can be used to log confirmation or update a related record |
Is Non-compliant | Runs when the failure time is reached without the success condition being met. Typically used to notify a supervisor or create an escalation task |
Add your actions inside the relevant condition branch. Common implementations include sending an email to the case owner when nearing non-compliance, or posting to a Teams channel when a case goes non-compliant.
Before you build: Holiday Schedules, Customer Service Schedules, and entity prerequisites
A Customer Service Schedule must exist before any SLA item can be configured with accurate business hours. Create the Holiday Schedule first. Navigate to Service Management → Holiday Schedule, select New, and add each non-working day in the Holiday Grid. Then create or edit a Customer Service Schedule under Service Management → Customer Service Schedule and link the Holiday Schedule in the Holiday Schedule field by selecting Observe.
The Customer Service Schedule is what you select in the Business Hours field of each SLA item. It is how the system knows not to count weekends, bank holidays, or out-of-hours time against your SLA timers.
Before building KPIs for a non-standard entity, confirm that SLA tracking is enabled for that entity. In your customisation solution, open the entity settings and check Enable for SLA under Communication & Collaboration, then save and publish. Also confirm that Disable SLA is set to No in the Service Configuration Settings. If this setting is toggled on, SLAs will not run regardless of how they are configured.
Role assignments need to be in place before agents and admins can work with SLA records. Admins need the CSR Manager role (or equivalent) plus Create permission at the business-unit level for SLA and SLA KPI records. Service representatives need the Customer Service Representative role with read privileges at the organisation level for SLA KPI instance records.
Training your service team on Dynamics 365 Customer Service SLA behaviour
If your service team is working with Dynamics 365 Customer Service, enquire about our Corporate Training Services built on your specific configuration and processes.
Comments