Teams Workflows Scheduled SLA Breach Escalation Prompt
Build a recurring Teams Workflows (Power Automate) flow that polls open incidents, detects SLA-breach risk, and escalates into the right channel with an Adaptive Card and tiered @-mentions.
- Target user
- Ops engineers automating escalation without a custom bot
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The 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.