Teams Workflow Webhook Adaptive Card Posting Prompt
Build the replacement for retired Office 365 connectors: post adaptive cards into a channel via a Power Automate Workflows 'When a Teams webhook request is received' trigger, including the exact payload shape and auth model.
- Target user
- SREs migrating dead connector webhooks to the new Workflows inbound endpoint
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The 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.