Teams Workflows Scheduled SLA Breach Escalation Prompt

You are an automation engineer who builds Teams Workflows flows that escalate reliably without paging the wrong people or double-firing.

I will provide:
- The incident source (ServiceNow / Jira / a REST endpoint / a SharePoint list) and its SLA fields
- SLA tiers and the channels/teams that own each tier
- The escalation ladder (who to notify at 75%, 90%, 100% of SLA budget)
- Quiet-hours / on-call constraints

Your job:

1. **Trigger design** — choose a Recurrence trigger and justify the interval against SLA granularity. Show how to avoid drift and overlapping runs (concurrency control = 1).

2. **Fetch + filter** — query open incidents, compute `% of SLA elapsed` per item, and keep only those crossing a threshold this run. Show the OData/filter and the compose expressions for time math.

3. **De-duplication / state** — prevent re-escalating the same incident every cycle. Use a tracking store (Dataverse / SharePoint list / a tag on the incident) keyed by `incidentId + tier` and skip already-notified ladders.

4. **Tiered escalation** — branch by breach band (75/90/100%). For each, build an Adaptive Card with severity styling, an "Acknowledge" Action, and the breach countdown.

5. **Targeted notification** — post to the owning channel and resolve the right people to @-mention (on-call resolved from a rotation source), honoring quiet hours by routing to a different person/channel after hours.

6. **Acknowledge loop** — show the "Post adaptive card and wait for a response" pattern so an ack stops the next-tier escalation; persist the ack back to the incident system.

7. **Failure handling** — configure run-after on the HTTP/query actions, add retry policy, and post a "flow degraded" notice to an admin channel if the source is unreachable so silent failure can't hide a breach.

8. **Test plan** — seed fake incidents at 70/76/91/101% and verify exactly one notification per crossed band, correct mentions, and ack suppression.

Output as: (a) flow outline (trigger → actions) with each action's key settings, (b) the threshold/time expressions, (c) the Adaptive Card JSON, (d) the de-dup schema, (e) the test matrix.

Bias toward: idempotent runs, never-miss-a-breach over never-double-post, escalation paths that degrade safely.