How to Fix Random SLA Timer Pauses in Dynamics 365 Customer Service
A troubleshooting guide to the real causes behind SLA KPI timers that pause without warning, and how to stop the false breach alerts they trigger.
Random SLA timer pauses in Dynamics 365 Customer Service almost always come down to a handful of causes: pause-and-resume status rules, business-hours calendars, background workflows or Power Automate flows, and custom plugins that update the case. This guide walks through how to find which one is at play and how to fix it, so you stop getting false breach alerts and your agents' SLA KPIs stay accurate. Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy that rescues and optimizes broken Customer Service implementations, and these are the checks we run on client environments. A reference further down adds the exact pause logic and Dataverse audit queries.
What commonly causes random SLA timer pauses?
Pause-and-resume status rules
The single most common cause. In Customer Service admin (Service Configuration Settings, "Pause and resume SLA on status"), you nominate one or more case statuses, typically "On Hold" and "Waiting for Details", that pause every active SLA KPI. Any process that moves a case into one of those statuses will stop the timer. If a status is on that pause list unintentionally, timers look like they stop at random.
Business hours / customer service calendar
An SLA KPI can be calculated against a customer service schedule (business hours). Outside working hours the timer legitimately pauses. A calendar with the wrong working days, wrong time zone, or holiday schedule attached to the SLA makes those pauses appear arbitrary to anyone reading the clock in a different time zone.
Background workflows and Power Automate flows
A classic workflow or a Power Automate cloud flow that updates the case, for example flipping the status reason to an on-hold value when an email arrives, or on assignment, will pause the SLA as a side effect. Because these run asynchronously, the pause can land seconds after an agent's action and feel disconnected from it.
Custom plugins on Update of the case
A registered plugin or custom API that writes to the case state, status reason, or an SLA-related field during Update can pause or reset the KPI. Plugins firing on a shared message (e.g. Update of incident) are easy to overlook when auditing SLA behaviour.
Enhanced SLA condition and KPI configuration
With Enhanced SLAs, each SLA item has Applicable When, Success, Pause, and Warning/Failure conditions plus its own KPI. A mismatch between the applicable-when and pause conditions, or overlapping SLA items competing on the same case, can produce a timer that starts, pauses, and resumes in ways that look random until the conditions are read carefully.
How do you diagnose and fix the pauses step by step?
Work through these in order. Each step narrows down the cause; steps 5 to 7 apply and validate the fix.
Confirm which SLA is active and its type
Open the affected case and check the Enhanced SLA Details (timeline / SLA KPI Instances) or the case's SLA field. Identify whether you are on a Standard or Enhanced SLA and exactly which SLA record and KPI applies. Random-looking behaviour is often two different SLAs or KPIs acting on the same case.
Review the pause-and-resume status configuration
In the Customer Service admin center, open Service Configuration Settings and inspect "Pause and resume SLA on status." Note every status reason that pauses SLAs. If a status is on this list that agents move cases into during normal work, the timer will pause every time, so remove statuses that should not pause the clock.
Audit the case status-reason transitions
Enable and read auditing on the incident (case) entity for the status and status reason fields. Walk the audit history of an affected case to see exactly when it entered a paused status and what made that change, whether a user, a workflow, a flow, or a plugin. This pinpoints the trigger instead of guessing.
Verify the business-hours calendar and time zone
Open the customer service schedule attached to the SLA (or SLA KPI) and confirm the working days, working hours, holiday schedule, and time zone. Compare them against where your agents and customers actually are. Correct any mismatched time zone or schedule so out-of-hours pauses stop looking random.
Inspect background workflows, flows, and plugins
Review real-time and background workflows, Power Automate cloud flows, and registered plugins/custom APIs that trigger on Update or status change of the case. Look for any that set the status reason to a paused value or write to SLA fields. Temporarily deactivate suspects in a sandbox to confirm which one moves the timer.
Examine the SLA KPI Instance records
Query the SLA KPI Instance records for affected cases and read the failure time, warning time, pause/resume timestamps, and status. Stuck, duplicated, or unexpectedly paused instances confirm the SLA engine itself is behaving as configured, and show whether a re-apply of the SLA is required.
Reproduce, fix, and validate in a sandbox
Reproduce the pause in a non-production environment, apply the fix, such as correcting the pause list, fixing the calendar, or adjusting the offending workflow/flow/plugin, and confirm the KPI now runs and breaches as expected. Only then promote the change to production and re-apply the SLA to open cases if needed.
If your agents are also being dropped in the middle of live conversations, that is a different problem with a different set of causes. Our guide to Omnichannel agent disconnections and chat timeouts works through the platform, identity, routing, network, and browser layers behind it.
One configuration detail worth checking while you are in here: SLA applicable when conditions read columns on the case, so an SLA driven by the product breaks quietly when agents stop filling in the Product lookup because the real list of products lives in a subgrid. Our guide to linking multiple products to a single case covers the three ways to model that and why the primary Product lookup still has to stay populated.
What logic does the SLA engine actually follow when it pauses a timer?
The steps above are the fix. This is the reference behind it, for the case where the obvious checks came back clean and the pauses are still happening. The product documentation covers each of these settings one screen at a time and never joins them up, so what follows is the joined up version: the rules the engine obeys, a flowchart with the questions whose answers change what you do next, the Dataverse queries that prove the answer rather than suggesting it, the misconfigurations behind pauses that look intermittent, and four false breach warnings with the move that cracked each one.
The rules that decide whether a timer pauses
Almost every pause that gets reported as random turns out to be one of these eight rules doing exactly what it says. Reading them in order is usually faster than opening the configuration, because three of them explain behaviour that no amount of staring at the SLA record will account for.
A pause belongs to the case, not to one KPI
The pause list in Service Configuration Settings operates on the case, so the moment a case enters a paused status every active SLA KPI instance attached to it stops together. There is no way to pause the resolve by clock through a status rule and leave first response running. If you need one KPI to keep counting while another stops, the two have to sit on separate SLA items with different applicable when conditions.
Nothing about the deadline changes at the moment of the pause
On the transition into a paused status the platform stamps lastonholdtime on the case and leaves each active KPI instance in a paused state. The warning time and failure time are untouched. That is why a case sitting on hold for a week still shows its original deadline and looks perfectly healthy right up until somebody touches it.
The recalculation happens on the way out
When the case leaves the paused status, the elapsed pause duration is added to onholdtime on the case and the warning time and failure time on each affected KPI instance are pushed out by that duration. Those values are rewritten in place on the existing rows rather than written as history, which is harmless on a form and quietly destructive in a report.
Allow pause and resume is a setting on the SLA, not on the organization
The status list is organization wide, but whether an individual SLA honours it is decided on the SLA record itself. Two SLAs covering different products or entitlements can behave differently on exactly the same status transition. A queue that mixes cases from both then produces pauses on some cases and not others with no pattern an agent can see, and this is the single most common reason the problem reads as random rather than systematic.
Business hours suppress the clock, they do not pause it
When a KPI is calculated against a customer service schedule, minutes outside working hours never count toward elapsed time in the first place. That is a different mechanism entirely: nothing is stamped on the case, onholdtime does not move, and the KPI instance stays in progress. A timer that looks frozen with no on hold time recorded is almost always business hours behaving correctly, and hunting through status rules for it wastes a day.
Working hours live on calendar rules, in a time zone of their own
A customer service schedule is a calendar record whose working pattern sits on calendar rules underneath it: a recurrence pattern, a start time, a duration, an effective interval, and a time zone code that belongs to the rule rather than to whoever is reading the screen. Deadlines are then rendered to each user in the time zone that user has set. A schedule built by an administrator in one region for agents in another is correct in the database and wrong on every screen.
Holiday schedules expire quietly
Holiday closures are calendar rules with their own effective interval, so a holiday schedule populated for one year simply stops applying when that year ends. Nothing errors and nothing warns. The pauses everyone was used to seeing over a closure do not happen the following year, and the result is a wave of breaches that reads as the SLA having suddenly got stricter.
Most of what agents do cannot pause a timer at all
Assigning a case, moving it between queues, adding an email or a note, and merging cases do not pause an SLA by themselves. They matter only when something else reacts to them and writes a status. That is precisely why the audit trail on the status columns, rather than the activity timeline, is the right place to look first.
The diagnostic flowchart
Read it top to bottom. Each box is either something you do or a question whose answer sends you down a different path, and the branches under a question are what to do in either case. There are only four questions here because there are only four points in this diagnosis where the answer genuinely changes the next action. Everything else is work.
- Start hereStep
Pin one case, one KPI instance, one timestamp
Diagnosing this across a population is how it stays unsolved for months. Take a single case that pauses, note its case id, and list every SLA KPI instance regarding it in creation order together with the SLA and SLA item each one came from. Write down the exact minute the timer stopped. Every question below is asked against that one record, and the queries that produce the list are in the next section.
- Gate 1Decision point
Does the case have on hold time recorded?
Read onholdtime and lastonholdtime on the case itself. Those two columns are the platform telling you, without ambiguity, whether a status driven pause ever happened. This gate splits the problem in half and takes about ten seconds, and skipping it is why most investigations start in the wrong place.
On hold time is greater than zeroA status rule paused the clock. Something moved the case into a status on the pause list, and the rest of the work is naming what. Continue to step 2.
On hold time is zero or emptyNothing paused. Either the customer service schedule is suppressing the clock outside working hours, or you are looking at a KPI instance that was cancelled and replaced when the SLA was re-applied. Skip ahead to gate 4 and go straight at the calendar.
- Step 2Step
Read the audit trail on the status columns, not the timeline
With auditing enabled on the case table for statecode and statuscode, the audit history gives you the change, the timestamp, the identity the write ran as, and, where it came through impersonation, the calling user behind it. The activity timeline will tell you none of that. Line the audit timestamp up against the minute you wrote down at the start; they should match to the second, and if they do not you are looking at the wrong transition.
- Gate 2Decision point
Was the status changed by a person or by a process?
The audit row answers this directly, and the two answers lead to completely different work. Do not guess from the case owner, because a background process very often runs as the owner.
By a personThe configuration is the problem rather than any code. A status your agents move cases into during ordinary handling is on the pause list. Either it should not be, or the team is using that status for something it was never meant to signal. Both are fixed in an afternoon and neither needs a developer.
By a processA background workflow, a Power Automate flow, an auto record creation rule, or a plugin is writing the status. Continue to step 3 to name it. The identity on the audit row is the filter that turns a hunt through every automation in the tenant into a short list.
- Step 3Step
Name the process that wrote the status
Search in this order, because it is the order of decreasing visibility: Power Automate run history filtered to the case, system jobs for background workflows regarding that case, auto record creation and update rules on the queue the case arrived through, and last the plugin trace log for steps registered on Update of incident. A plugin on a shared Update message is the answer more often than its position in that list suggests, because it fires on writes that have nothing to do with status and nobody remembers registering it.
- Gate 3Decision point
Do two SLAs or two SLA items apply to the same population?
Compare affected cases against unaffected ones and read which SLA and which SLA item each KPI instance came from. This gate explains intermittency more often than any other, and it is the one that almost never gets asked because the cases look identical on screen.
Two or more are in playCheck allow pause and resume on each SLA record and the applicable when conditions on each SLA item. Cases that an agent cannot tell apart are running under different rules. Align the pause setting, then tighten the applicable when conditions so only one item can ever claim a case.
Exactly one is in playThe behaviour is uniform, so the cause is either the pause list itself or the calendar. If step 3 named a process, fix that first and re-test before touching anything else. Otherwise continue to gate 4.
- Gate 4Decision point
Do the pauses cluster at the same wall clock time?
Plot the pause and resume timestamps by hour of day, converted into the time zone your agents actually work in. Dataverse stores these values in UTC, and a chart that skips the conversion will show you a pattern that is not there and hide the one that is.
They clusterBusiness hours. Open the customer service schedule attached to the SLA KPI, read the calendar rules underneath it, and check the recurrence pattern, the start time, the duration, and above all the time zone code on the rule. A cluster sitting a fixed number of hours away from your working day is a time zone code set to the wrong region.
They scatterNot ordinary business hours, but do not clear the calendar yet. Holiday rules carry their own effective interval, so an unmaintained holiday schedule produces pauses on some dates and not others and scatters very convincingly. Read the holiday entries before you move on.
- Step 4Step
Reproduce it in a sandbox before you change anything
Copy production into a sandbox, recreate the exact transition on a case, and watch onholdtime, lastonholdtime and the KPI instance move together. If it does not reproduce, the trigger is data dependent or identity dependent and you have not found it yet. Test the Friday evening to Monday morning case explicitly while you are in there, because that is where the pause arithmetic and the working hours calendar interact and where the resulting deadline surprises people most.
- OutcomeOutcome
Fix, re-apply the SLA, then re-baseline the report
Correct the pause list, the SLA level pause setting, the calendar rule, or the offending process, then re-apply the SLA to open cases so their KPI instances recalculate. Rebuild whatever report raised the alarm, because the failure times it was reading have now moved and the old numbers will never reconcile with the new ones. Finish by writing down which of the causes it was, since the same environment tends to produce the same one again.
How do you audit SLA KPI instance history in Dataverse?
The SLA KPI Instance table is where the engine writes down what it did, and reading it directly settles arguments that can otherwise run for weeks. These are the queries we run, in the order we run them: one case first, then the paused population across the environment, then the calendar sitting underneath both. Column names are the logical names, so they paste straight into a FetchXML tester, the Web API, or the Dataverse SQL endpoint.
<fetch top="50">
<entity name="slakpiinstance">
<attribute name="name" />
<attribute name="status" />
<attribute name="createdon" />
<attribute name="modifiedon" />
<attribute name="warningtime" />
<attribute name="failuretime" />
<attribute name="succeededon" />
<attribute name="slaid" />
<attribute name="slaitemid" />
<filter type="and">
<condition attribute="regardingobjectid" operator="eq" value="PASTE-CASE-GUID-HERE" />
</filter>
<order attribute="createdon" descending="false" />
<link-entity name="incident" from="incidentid" to="regardingobjectid" alias="c">
<attribute name="ticketnumber" />
<attribute name="statuscode" />
<attribute name="onholdtime" />
<attribute name="lastonholdtime" />
</link-entity>
</entity>
</fetch>Read this top to bottom as a story. The status column carries the out of the box values In Progress, Nearing Noncompliance, Succeeded, Noncompliant, Canceled and Paused, so confirm the integers against your own metadata before you filter on them. onholdtime on the joined case is cumulative minutes and is the number that proves a status pause happened. More than one set of instances for the same case means something re-applied the SLA rather than paused it, which is a different fault with a different fix.
GET {org}/api/data/v9.2/slakpiinstances
?$select=name,status,createdon,modifiedon,warningtime,failuretime,succeededon,
_slaid_value,_slaitemid_value,_regardingobjectid_value
&$filter=status eq 6 and createdon ge 2026-09-01T00:00:00Z
&$orderby=createdon desc
Prefer: odata.include-annotations="*"The annotations header is the part worth keeping. It returns the formatted status label, the display name behind each lookup, and the logical name of the table on the polymorphic regarding lookup, which saves a second round trip per row. Run this once a week during an investigation rather than once, because a paused instance that resumes overnight is invisible to a single snapshot and those are exactly the ones nobody can reproduce.
SELECT
k.name AS kpi_name,
k.statusname AS kpi_status,
k.createdon AS kpi_created_utc,
k.warningtime AS warning_utc,
k.failuretime AS failure_utc,
k.succeededon AS succeeded_utc,
c.ticketnumber,
c.statuscodename AS case_status_reason,
c.onholdtime AS on_hold_minutes,
c.lastonholdtime AS last_on_hold_utc,
s.name AS sla_name,
si.name AS sla_item_name
FROM slakpiinstance AS k
LEFT JOIN incident AS c ON c.incidentid = k.regardingobjectid
LEFT JOIN sla AS s ON s.slaid = k.slaid
LEFT JOIN slaitem AS si ON si.slaitemid = k.slaitemid
WHERE k.createdon >= DATEADD(day, -30, GETDATE())
ORDER BY c.onholdtime DESC, k.createdon DESC;This is the query to point Power BI at rather than importing whole tables. The endpoint exposes a name suffixed column for every choice column, which is why statusname and statuscodename appear here and no option set mapping is needed downstream. The endpoint supports a subset of T-SQL, so if a function is rejected, replace the date expression with a literal date. Sorting by on hold minutes puts the worst offenders on the first page, and in a healthy environment the top of that list is short.
SELECT
c.name AS calendar_name,
cr.pattern AS recurrence_pattern,
cr.starttime AS rule_start_utc,
cr.duration AS duration_minutes,
cr.effectiveintervalstart,
cr.effectiveintervalend,
cr.timezonecode,
tz.userinterfacename AS time_zone_label,
cr.innercalendarid
FROM calendar AS c
INNER JOIN calendarrule AS cr ON cr.calendarid = c.calendarid
LEFT JOIN timezonedefinition AS tz ON tz.timezonecode = cr.timezonecode
ORDER BY c.name, cr.effectiveintervalstart;This is the query almost nobody runs, and it answers the calendar half of the problem in one pass. The recurrence pattern is a rule string, so a working week reads as a list of weekdays and a missing day is visible immediately. The time zone label is the one to check first. The effective interval columns are where an unmaintained holiday schedule confesses, because a holiday entry whose interval ended last year is still sitting there looking configured. Where a rule looks empty, follow innercalendarid, because on a customer service schedule the actual working hours frequently sit on the inner calendar rather than on the rule you are reading.
Building a Power BI view that does not lie to you
We describe this as a build rather than shipping a template file, because the decision that makes the report trustworthy is the snapshot, and a downloadable template would hide exactly that decision behind a working demo. Four choices matter and the rest is ordinary modelling.
Source it from the SQL endpoint, not from whole table imports
Connect Power BI Desktop to the environment through the Dataverse connector and drive it from the thirty day query above, plus the calendar query as a second table. Importing slakpiinstance and incident whole and joining them in the model works on a demonstration environment and falls over on a real one, where the case table is the largest thing in the database.
Convert to agent local time in the model, once
Every datetime here arrives in UTC. Do the conversion in Power Query against a proper time zone, not with a fixed offset column, because a fixed offset is wrong for half the year in any region that observes daylight saving and it will invent a pattern in the hour of day chart that does not exist. This single step is what makes the calendar problems visible.
Snapshot the deadlines daily, because the live values move
Warning time and failure time are rewritten in place on resume. A report reading the live values shows the current deadline with no memory of the previous one, so two refreshes of the same report legitimately disagree and it looks like corruption. Write a daily snapshot of the KPI instance rows through a dataflow and report against the snapshot. Without this the report cannot tell you a warning was ever issued, because the status column only holds the current state.
Four pages are enough
Pause volume by case status reason, which names the status doing the damage. Pause and resume events by hour of day in agent local time, which exposes calendar and time zone faults as a clean cluster. Deadline drift, meaning the gap between when a KPI instance was created and where its failure time now sits, which finds the cases that have quietly been given days of extra runway. And a row level page carrying ticket number, KPI name, SLA name, on hold minutes and both deadlines, so anyone challenging a number can open the case behind it.
Which misconfigurations make the pauses look intermittent?
Organised by the symptom rather than by the setting, because the symptom is what you can match against on the day. Intermittency almost always means one of two things: two SLAs or SLA items behaving differently on cases that look the same, or a calendar rule that only applies on certain dates.
| Misconfiguration | What makes it look random | How to confirm it and fix it |
|---|---|---|
| A working status is on the pause list | Timers stop several times a day, always just after an agent touches the case, and the accumulated on hold time is large. | Read the pause list in Service Configuration Settings against the status reasons your team genuinely uses. Remove any status that is part of ordinary handling, and move the waiting signal onto a separate column so reporting keeps it without the clock paying for it. |
| Allow pause and resume set differently on two SLAs | Two cases that are indistinguishable to an agent behave differently, and nobody can find a rule that predicts which ones pause. | List the SLA on each affected and unaffected case, then compare the pause setting on the SLA records themselves. Align them, or make the difference deliberate and write it down where the service desk can see it. |
| Overlapping applicable when conditions on SLA items | A case carries more than one in progress KPI instance for the same intent, and two different deadlines appear on the dashboard. | Run the single case query and count the instances that are in progress. Tighten the applicable when conditions so exactly one item can claim a case, then re-apply the SLA to the open population. |
| Calendar rule time zone left at the provisioning default | Pauses and resumes cluster at the same two times every day, a fixed number of hours away from the actual working day. | Read timezonecode on the calendar rules behind the customer service schedule and compare it against where the agents sit. Rebuild the schedule in the correct time zone rather than shifting the hours by hand to compensate, because a hand shifted schedule breaks again at the next daylight saving change. |
| Business hours applied to one KPI and not another | First response behaves itself while resolve by breaches overnight, or the reverse, on the same case. | Open each SLA item and check which ones have a customer service schedule set. Set it consistently across items unless the difference is intentional, and if it is intentional, say so on the SLA item name. |
| Holiday schedule never maintained after go live | A wave of breaches on the first working day after a closure, and pauses that happened last year not happening this year. | Run the calendar query and read effectiveintervalstart and effectiveintervalend on the holiday entries. Populate the coming years and give the annual renewal to a named internal owner rather than leaving it with whoever implemented the system. |
| An auto record creation rule setting a paused status on inbound email | The clock stops seconds after a customer replies, with no agent anywhere near the case, and starts again when somebody opens it. | Take the identity from the audit row behind the status write, then read the auto record creation and update rules on the queue the case arrived through. This one is easy to miss because the rule looks like intake configuration rather than SLA configuration. |
| A plugin registered on Update of the case | Pauses that follow no pattern in the interface but always coincide with a particular kind of write, very often from an integration. | Enable the plugin trace log, reproduce the write in a sandbox, and read the steps registered on Update of incident. Filter the step to the specific columns it needs instead of leaving it firing on every update, which is the underlying fault in most of these. |
| Something re-applying the SLA | The timer appears to reset rather than pause, and older KPI instances are sitting in a cancelled state behind the current ones. | Order the KPI instances for the case by creation date. More than one generation means a process wrote to the SLA field on the case, usually a workflow or a flow, and the fix is upstream of the SLA configuration entirely. |
What caused false breach warnings, and how were they resolved?
Four investigations where the SLA was reported as broken and the fault turned out to be somewhere else. Each one is here for the move that cracked it rather than for the outcome.
Warning emails at three in the morning for a team that works nine to five
- What was reported
- A support desk began receiving SLA warning notifications in the middle of the night, on cases that had been open for less than an hour of working time. The deadlines shown on the cases themselves looked correct and nothing had actually breached.
- What it actually was
- The customer service schedule had been built in an environment provisioned with a default from another region, and the calendar rules underneath it carried a time zone code eight hours away. The KPI failure times were computed perfectly correctly against those hours. The arithmetic was right and only the definition of the working day was wrong, which is why every check of the SLA configuration itself came back clean.
- How it was resolved
- The schedule was rebuilt with the correct time zone code on the rules rather than the hours being shifted by hand, which would have broken again at the next daylight saving change. The SLA was re-applied to the open cases and out of hours notification volume went to zero the same day.
Two cases, same customer, same product, one breach and one not
- What was reported
- Agents had been reporting random pauses for months. The examples they sent were always pairs of cases that looked identical on screen, one of which had paused over a weekend and one of which had not.
- What it actually was
- Two SLAs were in play, because a second entitlement had been added a year earlier for one product line, and only one of the two had allow pause and resume switched on. Weekend on hold time counted against one SLA and not against the other. Nothing on the case form showed which SLA had been applied, so the difference was invisible to everyone reporting the fault.
- How it was resolved
- The pause setting was aligned across both SLAs and the applicable when conditions on the SLA items were tightened so a case could only ever be claimed by one of them. The SLA name was added to the case form and to the service dashboard, which is the change that stopped it recurring, because the next difference of this kind is now visible on the day it is introduced.
A wave of breaches on the second of January
- What was reported
- On the first working day of the year a service manager arrived to roughly forty cases marked noncompliant, almost all of them created during the holiday closure.
- What it actually was
- The holiday schedule attached to the customer service schedule had been populated once, during implementation, with the dates for that year only. The calendar rules carrying those dates had an effective interval that had quietly run out. Nothing errored, nothing appeared anywhere in the interface, and the closure counted as ordinary working time.
- How it was resolved
- The holiday entries were populated for the coming years, the affected KPI instances were reviewed so the genuinely missed cases could be separated from the phantom ones before anybody reported the month, and the annual renewal was handed to a named internal owner. The maintenance job takes minutes. The reason it gets missed is that nothing in the product ever asks for it.
A report that disagreed with the record it was reading
- What was reported
- A weekly SLA report showed cases breaching that were comfortably inside their deadline when opened. Refreshing the report changed the numbers again, and two people running it an hour apart got different answers.
- What it actually was
- Warning time and failure time on a KPI instance are rewritten in place every time a case resumes. A report reading the live values gives you the current deadline and no memory of the previous one, so any figure captured before a pause disagrees with the record afterwards and any comparison between two refreshes looks like corruption. The SLA configuration was never the problem.
- How it was resolved
- A daily snapshot of the KPI instance rows was written through a dataflow, so the report could compare the deadline as it stood on a given day against the deadline now, and the live report was rewritten to state the current deadline only. The pauses underneath turned out to be entirely legitimate. What was broken was the reporting model, which is the answer more often than anyone expects when the complaint is false breach warnings rather than stopped clocks.
Those four accounts are illustrative composites of engagements rather than named clients, with the details rounded. The shapes are the ones we meet most often, including the last one, where nothing was wrong with the SLA at all.
If the SLA behaviour is one of several things in the environment that nobody can fully explain, the pauses are a symptom rather than the problem. Our Dynamics 365 Health Check and technical audit runs the same evidence first method across configuration, security, performance, data quality, integrations and process alignment, at a fixed price, and hands back a prioritized action plan you own and can give to any partner. Where the answer needs building rather than documenting, whether that is a plugin registered on Update of the case that has to be filtered properly or an entitlement and calendar model that has to be rebuilt, that is Dynamics 365 development and CRM consulting work, and the same MB-230 certified people do both.
What should you do when customers are billed from SLA breach reports that are wrong?
If customers are billed or credited from Dynamics 365 SLA breach reports that nobody trusts, stop billing from the report until the numbers are verified, because an incorrect breach charged to a customer does more damage than a late invoice. Then untangle the policies in a fixed order: inventory every SLA and SLA item, find which one actually applied to each case by reading its SLA KPI Instance records, check pause conditions and business hours against the calendar in the contract, and correlate paused timestamps with the case audit history. Produce a corrected breach list per customer, bill from one temporary metric you can prove, and rebuild on an enhanced SLA design built for high volume.
Everything earlier on this page is about why a timer behaves as it does. Once invoices, service credits, or penalties are calculated from those timers, the question changes from which setting is wrong to which customers were billed the wrong amount, and the order of work changes with it. Evidence and a trusted number come before any fix, because the fix itself rewrites the figures you billed from.
Stop billing from the SLA report until it is verified
Tell finance in writing that SLA breach figures are suspended as a basis for invoices, service credits, and penalty calculations, name who can lift the suspension, and agree what happens to invoices in the meantime: hold the SLA line, or bill the base charge and reconcile the SLA component later. A customer charged for a breach that did not happen, or denied a credit it was owed, is a contractual and reputational problem that outlasts any delay. Take a dated export of the current report and of the SLA KPI Instance rows behind it before anything changes, because re-applying an SLA or fixing a calendar rewrites the warning and failure times in place and the figures you already billed from will no longer be reproducible.
Inventory every SLA and SLA item, active or not
List every SLA record in the environment with its type, whether it is active, whether it is the default, whether allow pause and resume is on, and which entitlements or rules apply it. Under each one list its SLA items with the applicable when condition, the success condition, any pause condition on the item, the warning and failure durations, and the customer service schedule set on the item. Include deactivated SLAs, because KPI instances created while they were active are still in the data your report reads. The inventory is usually the first time anyone sees all the policies side by side, and overlaps, forgotten test SLAs, and items with no schedule where the contract assumes business hours tend to be visible within the first read.
Find which SLA actually applied through SLA KPI Instance records
Do not trust the SLA lookup on the case form. It shows the current value, it can be changed after the fact, and it says nothing about which item produced the timer. For each billed customer, read the SLA KPI Instance rows regarding their cases for the billing period, with the SLA and SLA item each instance came from, its status, and its warning, failure, and succeeded times, using the single case and thirty day queries earlier on this page. Group by customer and by SLA. Cases with more than one generation of instances, cancelled instances behind current ones, or instances from an SLA the contract never mentions are the ones whose billed figures are most likely wrong.
Check pause conditions and business hours against the contracted calendar
Take the service hours, time zone, public holidays, and clock stop rules from the signed contract or service schedule for each customer, not from the system. Compare them with the customer service schedule and holiday schedule attached to each SLA item, reading the calendar rules and their time zone codes with the calendar query above, and with the statuses on the pause list and any pause conditions on the SLA items. The contract typically allows the clock to stop only while waiting on the customer, and often uses the customer country for holidays. Write down every difference per customer: hours the system counts that the contract does not, pauses the system takes that the contract does not allow, and holidays that expired or belong to the wrong region.
Correlate paused timestamps with the audit history of each case
Because warning and failure times are rewritten on every resume, the KPI instance on its own cannot tell you how long a case was paused or why. Rebuild the timeline from the audit history on the status columns of the case: each transition into and out of a paused status, with its timestamp and the identity that made it, then check the sum of those paused intervals against onholdtime on the case. Mark each paused interval as contractually allowed, such as a genuine wait for the customer, or not allowed, such as an agent parking a case or a flow setting a hold status on inbound email. Where auditing was off for part of the period, say so on the customer record and fall back to activity timestamps rather than presenting an estimate as fact.
Produce a corrected breach list per customer
For each case in the billing period, recompute elapsed time from timestamps the SLA engine does not rewrite, such as case created on, the first qualifying response activity, and the resolution date, counted only inside the contracted calendar and minus only the contractually allowed pauses from the previous step. Compare the result with what the system reported and put every case into one of three groups: breach confirmed, reported as breached but not a breach under the contract, and a real breach the system missed. Total the groups per customer. What to do about each group, whether to issue a credit, reverse a charge, or disclose a missed breach, is a commercial and contractual decision for finance and account owners, and the list exists so they can make it on evidence.
Bill from one temporary metric you can prove while the policies are rebuilt
Do not try to fix every KPI before invoices resume. Pick the single measure that the contracts depend on most, usually resolution or first response within contracted business hours, compute it from the same raw timestamps and contracted calendar used for the corrected list, and write the result into new columns on the case with the date it was calculated and who verified it. Never reuse the SLA columns or KPI instance fields for this. Finance bills from that metric alone, labelled as temporary, until the rebuilt SLAs have run in parallel with it for a full billing period and agree. The manual determination columns and evidence pack described in our automation triage guide work the same way here.
Where a flow or other automation has been writing the wrong breach values rather than the SLA engine simply being misconfigured, the containment comes first: the manual breach flag, quarantine, and auditor evidence checklist are set out in the emergency triage for broken automations in our rescue services guide.
What enhanced SLA design survives tens of thousands of tickets a month?
The corrected breach list settles the past. The rebuild has to stop the same arithmetic going wrong again at a volume where nobody can check cases by hand. These are the design rules we apply when an SLA model has to carry billing, and the feature details behind them move between releases, so confirm them against the current Microsoft documentation for your environment.
One SLA per contract tier, selected by data rather than by agents
Model each distinct contractual commitment as one enhanced SLA, applied through the entitlement or a column stamped at case creation such as contract tier or priority, and remove agent edit rights on whatever selects it. When the SLA a case receives depends on a value an agent can change halfway through, every edit can re-apply the SLA, cancel the existing KPI instances, and start new ones, which is the pattern that makes a billing report irreproducible at volume.
Applicable when conditions that can never overlap
Write SLA item conditions so exactly one item can claim a given KPI on a given case, keyed on a small number of stable columns, and test the boundaries with sample cases for every tier and priority before go live. Overlapping conditions do not fail loudly. They produce two timers and two deadlines, and a report that sums them bills the customer twice.
Clock stop rules that mirror the contract, and nothing else
Only the waiting states the contract recognizes should pause a timer. Keep the organization level pause list to those statuses, and where your version supports pause conditions on individual SLA items, use them to express a tier whose contract stops the clock differently, checking the current Microsoft documentation for what your environment offers. Everything else an agent wants to signal, such as parked, escalated internally, or awaiting a third party the customer did not cause, belongs in a separate column that reporting can see and the clock ignores.
A calendar per contracted region, with an owner for its holidays
Build one customer service schedule per contracted time zone and hours pattern, attach the holiday schedule for that region, and populate holidays several years ahead with a named internal owner for the annual renewal. Name each schedule after the contract terms it represents, so anyone reading an SLA item can match it to the contract without opening the calendar rules.
Light warning and failure actions
At high ticket volume every warning and failure action runs for a large number of KPI instances. Keep those actions to notifications and a single flag, avoid writing back to case status or the SLA lookup from them, because those writes can pause or re-apply the very SLA that triggered them, and watch flow and background job queues after go live rather than assuming they keep up.
Billing reads a daily snapshot, not the live KPI instances
Write the KPI instance rows and the case columns billing needs into a daily snapshot, as described in the Power BI section above, and give finance a billing view built on that snapshot with the SLA, SLA item, contracted calendar, and paused minutes on every row. Run the rebuilt SLAs in parallel with the temporary metric for at least one full billing period, and switch finance over only when the two agree case by case.
Rebuilding SLAs, entitlements, calendars, and the reporting finance depends on, as one piece of work alongside queues and routing, is part of our Dynamics 365 Customer Service implementation service, delivered remotely from Yerevan, Armenia, directly or white-label for Microsoft partners.
What do people ask about SLA timer pauses?
Why does my Dynamics 365 SLA timer pause randomly?
The most common reason is that the case has entered a status that is on the "Pause and resume SLA" list in Service Configuration Settings, often "On Hold", usually set by an agent, a background workflow, a Power Automate flow, or a plugin. Business-hours calendars and time-zone mismatches are the next most common cause. Auditing the status-reason changes on an affected case almost always reveals the trigger.
How do I stop false SLA breach and pause alerts for my agents?
Remove any status from the pause-and-resume list that agents move cases into during normal handling, align the SLA's customer service schedule and time zone with where your agents work, and fix any workflow, flow, or plugin that changes the case status as a side effect. Then re-apply the SLA to affected cases so the KPI recalculates correctly.
Does a business-hours calendar cause SLA timers to pause?
Yes. When an SLA KPI is calculated against a customer service schedule, the timer legitimately pauses outside working hours and on holidays. If the calendar has the wrong time zone or working days, those pauses look random to anyone reading the clock elsewhere. Check the schedule attached to the SLA or KPI first.
Can a Power Automate flow or plugin pause an SLA timer?
Indirectly, yes. SLA timers do not have a direct "pause" action, but any workflow, Power Automate flow, or plugin that updates the case status to a value on the pause list will pause every active SLA KPI. Because these run in the background, the pause can appear seconds after an unrelated action and feel random.
Can Solzet fix a broken Dynamics 365 Customer Service SLA setup?
Yes. Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy based in Yerevan, Armenia, with MB-230 (Customer Service) certified consultants. We run exactly these diagnostics on client environments as part of our project rescue and optimization work, then correct the SLA, calendar, workflow, and plugin configuration and validate it in a sandbox before go-live.
How do I audit SLA KPI instance history in Dynamics 365?
Query the SLA KPI Instance table directly rather than reading the case form. For one case, run a FetchXML query over slakpiinstance filtered on regardingobjectid, selecting status, createdon, warningtime, failuretime and succeededon, and link to the case for ticketnumber, statuscode, onholdtime and lastonholdtime. For the whole environment, use the Web API with the annotations Prefer header, or the Dataverse SQL endpoint if you are feeding Power BI. onholdtime on the case is cumulative minutes and is the column that proves a status driven pause actually happened. This page carries all four queries in full.
What is the difference between an SLA pause and business hours suppressing the timer?
They are separate mechanisms and they leave different evidence. A pause comes from a case status on the pause list: the platform stamps lastonholdtime, accumulates onholdtime on the case, and pushes the warning time and failure time out by the paused duration when the case resumes. Business hours never pause anything; minutes outside the customer service schedule simply do not count toward elapsed time, nothing is stamped on the case, and the KPI instance stays in progress. A timer that looks frozen with no on hold time recorded is business hours, not a pause.
Why do SLA pauses happen on some cases and not on others that look identical?
Usually because two SLAs or two SLA items are in play. Allow pause and resume is a setting on the individual SLA record rather than on the organization, so two SLAs covering different products or entitlements can behave differently on exactly the same status transition, and nothing on the case form shows which SLA was applied. The other common source of intermittency is a holiday calendar rule whose effective interval has expired, which produces pauses on some dates and not others. Compare the SLA and SLA item behind the KPI instances on an affected case against an unaffected one.
Why do the SLA deadlines in my report keep changing?
Because warning time and failure time on an SLA KPI instance are rewritten in place every time a case resumes, rather than being written as history. A report reading the live values shows the current deadline with no memory of the previous one, so a figure captured before a pause disagrees with the record afterwards and two refreshes can legitimately disagree with each other. Snapshot the KPI instance rows daily through a dataflow and report against the snapshot. This is a frequent cause of false breach warnings where the SLA configuration itself is correct.
Our Dynamics 365 SLA breach reports are wrong and we bill customers from them. What do we do first?
Stop billing from the report until the numbers are verified, and tell finance in writing who can lift that suspension. An incorrect breach charged to a customer, or a credit wrongly withheld, does more damage than a late invoice. Take a dated export of the report and the SLA KPI Instance rows behind it before changing anything, because fixing a calendar or re-applying an SLA rewrites warning and failure times in place. Then inventory every SLA and SLA item, identify which one applied to each billed case from its KPI instances, and compare pause rules and business hours against the contract.
How do we find out which SLA actually applied to a case in Dynamics 365?
Read the SLA KPI Instance records regarding the case rather than the SLA field on the case form. Each instance carries the SLA and SLA item that created it, its status, and its warning, failure, and succeeded times, while the case field shows only the current value and can be changed afterwards. More than one generation of instances, cancelled instances behind current ones, or instances from an SLA the contract does not mention all mean the figure a report showed for that case is suspect. Group the instances by customer and SLA for the billing period to see the pattern across a whole account.
How do we check SLA business hours against the calendar in a customer contract?
Take the service hours, time zone, public holidays, and clock stop rules from the signed contract for each customer, then compare them with the customer service schedule and holiday schedule attached to each SLA item. Read the calendar rules and their time zone codes directly, because the screen renders times in the reader time zone. Check the holiday entries have not expired and belong to the right country, and check the statuses on the pause list against what the contract allows to stop the clock, which is usually only waiting on the customer. Record every difference per customer.
How do we produce a corrected SLA breach list for each customer?
Recompute elapsed time for every case in the period from timestamps the SLA engine does not rewrite, such as case creation, the first qualifying response, and resolution, counted only inside the contracted calendar and minus only the pauses the contract allows. Rebuild the paused intervals from the audit history on the case status columns and check them against onholdtime. Then sort every case into breach confirmed, reported but not a contractual breach, and a real breach the system missed, and total each group per customer. Credits, reversals, and disclosure are then commercial decisions made on evidence.
What should finance bill from while the SLA policies are being rebuilt?
One temporary metric that can be proved, usually resolution or first response within contracted business hours, computed from raw case and activity timestamps against the contracted calendar and written into new columns on the case with a calculation date and a named verifier. Never reuse the SLA or KPI instance fields for it. Label it as temporary, and keep it until the rebuilt enhanced SLAs have run in parallel for a full billing period and agree with it case by case.
How should enhanced SLAs be designed to stay accurate at high ticket volume?
One SLA per contract tier, applied from the entitlement or a column stamped at creation that agents cannot edit, so SLAs are not re-applied midway through a case. SLA item conditions that can never overlap. Clock stop rules that match the contract and nothing else, with other waiting signals kept in separate columns. One customer service schedule per contracted region with maintained holidays. Warning and failure actions kept light and never writing back to case status. And billing that reads a daily snapshot of KPI instances rather than live values, which are rewritten on every resume.
We recommend the right solution: Dynamics 365 (Customer Engagement, Business Central or Finance and Operations), Power Platform, or a custom-built CRM. One team for CRM, ERP and the integration between them.
SLAs still misbehaving? Can we rescue them for you?
Solzet's MB-230 certified Dynamics 365 Customer Service consultants run these exact diagnostics as part of our project rescue and optimization work. Tell us what your timers are doing and we will fix the configuration behind them.