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-application-and-precedence.md
feature-sla-application-and-precedence.mdv1 · history
CurrentApplies to AllUpdated 6 days agoSource Microsoft Learn ↗

What it does

An SLA reaches a record in one of four ways: applied automatically by a workflow, flow or plug-in; inherited from the entitlement on the case; selected manually in the SLA field; or picked up from the SLA marked as default for that table. Only one can win.

Key facts

  • The precedence order is automatic first, then the entitlement's SLA, then the default SLA. If an automatic rule sets one, the entitlement's SLA never gets a look in.
  • Only one SLA can be applied to a record. Apply a different one and the previously applied SLA is cancelled, taking its running KPI instances with it.
  • The SLA lookup is not on any form by default. If you want manual selection, an administrator has to add it.
  • Automatic application from a flow or plug-in works by setting the SLA lookup to the SLA record's GUID — for example writing to slaid in a pre-update plug-in. Hard-coded GUIDs do not survive a solution move unless the SLA is deployed with the same ID.
  • A default SLA is set with Set As Default from the SLA list under Service terms. One default per table.
  • By default, once an SLA KPI instance reaches a terminal state — Succeeded or Noncompliant — it is not re-evaluated. Recalculate SLA on terminal status, in Service Configuration Settings under Other SLA Settings, changes that.
  • With recalculation enabled, a change to the Applicable When conditions or to the SLA item can produce a new KPI instance. A Succeeded instance can be revisited; a Noncompliant one still is not.
  • Service Configuration Settings also carries a Disable SLAs toggle. Set to Yes, nothing applies anywhere, with no error.
  • Entitlement-driven application relies on the case entitlement plug-in steps — PreOperationIncidentCreateEntitlement, PostOperationIncidentCreateEntitlement and their update equivalents. Inactive steps mean no SLA and no message.
  • Where an SLA is not applying, the documented suspects are: no default SLA, a null Applicable From value, Applicable When conditions that do not actually match the data, inactive SDK steps, SLAs disabled globally, an unpublished SLA workflow, and a calendar last saved in the legacy web client.

When to use / skip

Every implementation has to pick a model here, so this is not optional so much as easy to get wrong by not deciding.

Default SLA alone is right for a single service level across all customers. Entitlement-driven is right when service levels are sold per customer. Automatic application via flow or plug-in should be a last resort — reserve it for genuinely conditional cases, such as an SLA that depends on a product or a contract type that is not modelled as an entitlement, and accept that you now own that code.

Manual selection is worth exposing on the form during a pilot and worth hiding afterwards. Agents choosing their own SLA is not a design, it is a reporting problem waiting to happen.

Configuration decisions

  • Which of the four routes is the primary model, and whether more than one is in play at once.
  • Whether the SLA lookup appears on the form at all, and who can edit it.
  • Whether a default SLA exists as a safety net beneath entitlement-driven application. Usually yes.
  • Whether Recalculate SLA on terminal status is on. It changes reopened-case behaviour materially.
  • How SLA records are deployed between environments, given that automatic application usually depends on their IDs.
  • What happens when a case is reopened: new SLA, resumed SLA, or nothing.

Gotchas

  • Changing the SLA on a live record cancels the running instance. Whatever the countdown said is gone, and the new SLA starts from its own Applicable From value, which may already be in the past.
  • Option set values and text compared in Applicable When are matched exactly. After a solution import from another environment, mismatched option set values are a classic cause of SLAs that apply in test and not in production.
  • A null Applicable From column means no SLA at all, with no warning anywhere. This bites after data migration, where Created On is set but a custom start column is not.
  • The Disable SLAs setting is easy to flip during a performance investigation and easy to forget to flip back.
  • Precedence surprises people: adding an automatic rule silently overrides every entitlement-based SLA on that table.
  • Terminal instances are frozen unless recalculation is enabled, so a reopened case sits there showing a stale Succeeded result.

Consultant notes

  • Draw the precedence order on one slide during design. It takes two minutes and prevents the most expensive argument in this feature area.
  • If you have to apply SLAs from code, look the SLA up by name rather than embedding a GUID, and say so in the design document.
  • Check the entitlement and SLA SDK steps in the production environment as part of go-live, not after the first complaint.
  • Before handing over, run the "no SLA applied" checklist once against real data — default set, Applicable From populated, workflows published, calendar saved in Unified Interface. It catches nearly all of them.

Worth another look if the terminal-state recalculation setting ever becomes the default behaviour.

Was this accurate?
Related
SLA definitions and KPI items04-slas-and-entitlementsSLA success, warning and failure actions04-slas-and-entitlementsEntitlements and support terms04-slas-and-entitlementsSLA pause and resume04-slas-and-entitlementsCase status reasons and status reason transitions01-case-managementBusiness hours and holiday schedules for SLAs04-slas-and-entitlements