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 same checks we run on real client environments. Further down, a dedicated troubleshooting reference sets out the exact pause and resume logic, a diagnostic flowchart with the four questions that change what you do next, the Dataverse queries that read SLA KPI instance history, and the misconfigurations behind intermittent pauses and false breach warnings.
Common causes of 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.
Step-by-step: diagnose and fix the pauses
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.
Troubleshooting random pauses: the logic the SLA engine actually follows
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.
Auditing 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.
Common misconfigurations that 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. |
False breach warnings, and how they were 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.
Frequently Asked Questions
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.
SLAs still misbehaving? We rescue them.
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'll fix the configuration behind them.