SLA success, warning and failure actions

What it does

Every SLA item can fire actions at three moments: when the KPI succeeds, when it reaches the warning threshold, and when it fails. On enhanced SLAs those actions live in a Power Automate flow generated from the SLA item; on standard SLAs they are classic workflow steps.

Key facts

The three branches are named Is Succeeded, Is Nearing Non-Compliance and Is Non-compliant. They appear as cases in a Switch inside a predefined flow that Dynamics generates when you select Configure Actions on the SLA item.
You must save the SLA item before the warning and failure sections will accept actions.
Microsoft's guidance is to add steps inside the Switch branches and leave the surrounding flow alone. Editing the generated skeleton breaks the SLA rather than the flow.
msdyn_SendEmailFromTemplate is the supplied action for the common case, taking From, To Item, Cc Item, Regarding and Template. Everything else is ordinary Dataverse or connector actions.
The user who owns or activates the SLA action flows, and SLAInstanceMonitoringWarningAndExpiryFlow, needs prvReadSLAKPIInstance and prvWriteSLAKPIInstance at global scope. Business-unit scope is not enough.
Standard SLAs have a fixed action list: Send Email, Create Record, Update Record, Assign Record and Change Status. No Power Automate.
Actions run asynchronously. Warning and failure times set to under an hour are documented as likely to be processed late.
Once a KPI instance reaches a terminal state — Succeeded or Noncompliant — no further actions fire for it, and Paused On and elapsed time stop being calculated.
Success actions run only if the success criteria are met before the failure time. Meet them afterwards and you get nothing.
Warning is a duration on the SLA item, not a percentage. If you want "80% of target" you calculate it yourself and hard-code it.

When to use / skip

Use actions for the thin, mechanical things: notify the owner, notify the queue manager, flag the record, escalate a priority. That is what they are good at and it demos well.

Skip them as a general automation layer. Every action you bury inside a generated per-SLA-item flow is one more thing that is invisible in the solution, awkward to test and easy to lose in a deployment. If the escalation logic is genuinely complicated, have the SLA action do one thing — set a column, or call a single custom action — and put the real logic in a normal, source-controlled flow triggered by that change. Your future self will thank you when the SLA is rebuilt.

Also skip warning actions entirely on short SLAs. A warning at 45 minutes on a one-hour target, processed asynchronously, arrives roughly when the failure does.

Configuration decisions

Who gets told: record owner, queue owner, a named escalation group, or the customer. Customer-facing failure emails are a business decision, not a technical one.
Whether failure changes data on the record — escalating priority, setting a flag, reassigning — or is purely a notification.
Where the logic lives: in the SLA action flow itself, or in a separate flow that the SLA action triggers.
Which email templates and which sending mailbox, including whether the From is a queue rather than a user.
Whether you configure warning actions at all, given the duration involved.
How the flows are moved between environments, and which account will own them in production.

Gotchas

The generated flows carry connection references owned by whoever clicked Configure Actions. Deploy with that person's personal connection and it will fail the first time they leave.
Deactivating and reactivating an SLA can leave action flows in a draft state. The SLA then runs and silently does nothing at warning or failure.
Actions do not fire retrospectively. Add a failure action to a live SLA item and instances already past their failure time never trigger it.
Pause and resume recalculates the failure time and the warning time, except where the warning has already passed — so a resumed case can skip its warning notification altogether.
Notification fatigue is real. An escalation email on every high-priority case failure sounds fine in workshop and becomes a mail rule within a fortnight.
If the SLA item's success criteria and Applicable When conflict, the instance cancels and no branch ever runs. Cancelled is not failed, so nothing is reported either.

Consultant notes

Demo the failure path, not the success path. Clients care about what happens when it goes wrong, and it is the part that most often turns out to be misconfigured.
Agree early who owns the escalation mailbox. It is usually the thing that holds up go-live, not the SLA config.
Tell the client plainly that actions are near-real-time, not real-time, and that sub-hour targets will drift. Better said in design than discovered in UAT.
Check flow ownership and connection references as part of the go-live checklist, alongside the usual "is the SLA active".

Worth revisiting if Microsoft moves SLA actions off per-item generated flows onto something solution-aware.