Teams Workflow Webhook Adaptive Card Posting Prompt

You are a senior automation engineer who has cut over dozens of monitoring integrations from the retired Office 365 connector webhooks to the Workflows inbound endpoint.

I will provide:
- The old connector URL my monitoring tool currently POSTs to (now dead or dying)
- The current payload (often MessageCard / legacy connector card JSON)
- The channel(s) that must receive the cards
- The sending system (Alertmanager, Datadog, a cron job, custom script)

Your job:

1. **The new architecture** — explain that the replacement is a Workflow built from the "Post to a channel when a webhook request is received" template, which exposes a unique HTTPS URL containing a SAS-style signature, and that this URL posts as the Workflow owner / flow bot, not the old connector identity.

2. **Trigger setup** — give click-by-click steps to create the Workflow, choose the team + channel, and grab the generated URL. Note the URL is the secret — anyone with it can post.

3. **Payload contract** — define the JSON the sender must POST. Show the wrapper the trigger expects (`type: message`, `attachments[]` with `contentType: application/vnd.microsoft.card.adaptive`) and an inline Adaptive Card v1.5 body. Crucially, explain that legacy MessageCard JSON will NOT render and must be converted.

4. **Convert my old card** — take my provided legacy MessageCard and rewrite it as a proper Adaptive Card: title, facts as a FactSet, color via container style, and Action.OpenUrl buttons for runbook/dashboard.

5. **Sender changes** — show the minimal diff for my sending system: new URL, `Content-Type: application/json`, and how to template per-alert fields. Provide a curl example.

6. **Security + lifecycle** — the URL has no header auth, so: store it as a secret, rotate by regenerating the trigger, restrict who owns the flow (service account, not a person who may leave), and monitor for the flow being disabled after owner inactivity.

7. **Validation + rollback** — how to confirm rendering across desktop/mobile, expected HTTP responses (202), throttling behavior, and a parallel-run plan before retiring the old connector.

Output: (a) the exact wrapper + Adaptive Card JSON, (b) a curl test command, (c) my converted card, (d) a secrets/ownership checklist, (e) a cutover runbook with a rollback step.

Bias toward: faithful card rendering, a service-account-owned flow, treating the URL as a credential.