Almanac
Microsoft/d365csDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Customer Service: implementation notes, gotchas, and configuration decisions beyond the official docs — across case management, queues and routing, knowledge base, SLAs, omnichannel, agent experience, Copilot, analytics, and administration.

d365cs/04-slas-and-entitlements/feature-sla-pause-and-resume.md
feature-sla-pause-and-resume.mdv1 · history
CurrentApplies to AllUpdated 6 days agoSource Microsoft Learn ↗

What it does

Pause and resume stops an SLA KPI clock while a record sits in a status you have nominated as "on hold" — typically waiting on the customer — and restarts it with a recalculated warning and failure time when the record comes off hold. It is an enhanced SLA feature only.

Key facts

  • Pause conditions can be defined at three levels: the table, the SLA KPI, and the SLA item. The SLA item wins over the KPI, and the KPI wins over the table.
  • Table-level pause statuses live in the Copilot Service admin center under Service terms, Other SLA Settings, Manage, in the Service Configuration Settings view. That set applies to every SLA on that table.
  • To override at KPI or item level you have to switch Override Criteria to Yes. Leave it off and the table-level setting keeps applying, even if you have typed conditions in.
  • Allow Pause and Resume must be enabled on the SLA KPI's General tab before KPI-level pause conditions do anything.
  • On resume, the running SLA KPI Instance is cancelled and a brand new instance is created. It is not the same record continuing.
  • Standard SLAs cannot pause. Allow Pause and Resume has to be set to Do Not Allow.
  • Pause time is only netted off within business hours. Pause outside working hours and nothing is credited, because nothing was being counted.
  • Documented behaviour: pause and resume both inside working hours extends warning and failure times; pause inside working hours and resume outside does not count the held time; pause outside and resume inside triggers a recalculation.
  • The SLA KPI Instance carries On-hold duration, Active Duration (min) and Elapsed Time (min). These are calculated asynchronously, so the form often needs a refresh before they show.
  • The SLA timer control auto-refreshes for pause and resume state changes; other transitions may need a manual refresh.

When to use / skip

Turn it on if the client's contract measures their own responsiveness rather than wall-clock age — which is nearly every contract with a "waiting on customer" concept. Without it, every case that waits three days for a customer reply is non-compliant, the SLA reporting is worthless, and agents start closing and reopening cases to game it.

Skip it where the commitment is genuinely elapsed-time, such as a hard "resolved within 24 hours of logging regardless" promise. Also skip it where the on-hold status is not disciplined: if agents park everything On Hold, pause and resume turns the SLA into a metric that only ever measures agent activity and never measures customer outcome. That is a process problem, but it will be blamed on your configuration.

Most Customer Service projects that use SLAs at all end up using pause.

Configuration decisions

  • Which statuses count as on hold, and whether that is one global answer or differs per SLA. Do the table-level one first and only override where a contract genuinely differs.
  • Whether pause is defined by simple status or by richer conditions on the record or a related table.
  • Whether Allow Pause and Resume goes on the SLA item — remember it is fixed after the item's first save.
  • Whether resolution KPIs pause as well as response KPIs. Response usually should not pause; resolution usually should.
  • How you will report given that pausing produces multiple SLA KPI Instances per KPI. Decide the reporting shape before anyone builds it.
  • Whether agents can set on hold freely, or whether it requires a reason code.

Gotchas

  • Because resume cancels and recreates the instance, any report that counts instances, or joins to a stored instance GUID, gets confused after the first pause. Report on the record, not the instance ID.
  • Pausing on a holiday or overnight looks broken — the countdown appears not to move, then does not credit any time back. This is by design; the clock was already stopped.
  • The Allow Pause and Resume toggle cannot be flipped after the SLA item is saved. Rebuilding items mid-project because of this is depressingly common.
  • Warning actions are not re-fired if the warning time had already passed before the pause, so a resumed case can go straight from in-progress to failed with no warning email.
  • Table-level pause statuses are global. Change them for one team's SLA and you have changed them for everyone's.
  • Paused On can appear null on an instance that is genuinely on hold; Microsoft documents this separately. Don't build logic on that column alone.

Consultant notes

  • Demo a case going on hold and coming back, with the timer visible. It is the single most convincing SLA demo and it settles most arguments about elapsed time.
  • Agree the on-hold status list with the service manager in writing. It is the setting most likely to be quietly changed after go-live.
  • Tell the client that pause is netted against business hours, not the calendar, and show the arithmetic once. It prevents a fortnight of "the timer is wrong" tickets.
  • Before go-live, run a case through pause and resume in the target environment and confirm the new instance appears with the expected recalculated failure time.

Worth another look if the pause behaviour stops cancelling and recreating the KPI instance.

Was this accurate?
Related
Business hours and holiday schedules for SLAs04-slas-and-entitlementsSLA definitions and KPI items04-slas-and-entitlementsHow SLAs get applied, and the precedence order04-slas-and-entitlementsSLA success, warning and failure actions04-slas-and-entitlementsEntitlements and support terms04-slas-and-entitlementsCase status reasons and status reason transitions01-case-management