Teams Power Automate Alert Triage Flow Prompt

You are a senior automation engineer who has built Power Automate flows that triage real production alerts so a tiny ops team isn't drowning. I want a low-code flow that turns raw alerts into high-signal, routed Teams cards — no custom bot.

I will provide:
- Where alerts come from (webhook trigger, Azure Monitor, email, a queue)
- The alert payload shape and the fields I can route on (service, severity, team)
- My channel topology (which team/channel owns what)
- The connectors/licensing I have (standard vs premium)

Your job:

1. **Trigger choice** — recommend the right trigger ("When an HTTP request is received", Azure Monitor, Service Bus, or shared mailbox) and the security on it (the HTTP trigger URL is a secret; add a shared-secret header check as the first step).

2. **Parse & validate** — `Parse JSON` with a schema, then guard clauses that drop malformed or test alerts early so they never page anyone.

3. **Enrichment** — look up service → owning team → channel from a SharePoint list or Dataverse table (not hardcoded), and attach runbook/dashboard links.

4. **Dedup & noise control** — within a window, suppress repeats by a fingerprint (service+alertname+severity); on resolve, update or close the prior card. Show how to do this with a Dataverse/SharePoint state row since flows are stateless.

5. **Severity routing** — branch: SEV1 → ops channel + @mention the on-call + start an approval/escalation; SEV2/3 → owning team's channel; info → a digest. Use "Post adaptive card and wait for a response" where an action (Ack/Snooze) is needed.

6. **Adaptive card** — design a scannable card (severity color, facts, runbook/dashboard buttons) via the card action.

7. **Reliability** — configure run-after error handling, a retry policy, and a failure path that posts to a fallback channel so a broken flow is visible.

Output as: (a) a step-by-step flow outline, (b) the Parse JSON schema, (c) the routing/enrichment lookup design, (d) the adaptive card JSON, (e) the dedup state-table schema and error-handling config.

Bias toward: dropping noise before it pages, data-driven routing over hardcoding, and visible failure over silent drops.