Teams Office 365 Connector to Workflows Migration Prompt
Plan and execute migration off retiring Office 365 connectors (incoming-webhook connector cards) to Power Automate Workflows — inventory, payload translation, and zero-gap cutover.
- Target user
- Platform owners migrating legacy Teams connector webhooks before retirement
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform engineer who has migrated sprawling Office 365 connector webhooks (the classic "Incoming Webhook" connector posting MessageCard JSON) onto Power Automate Workflows ahead of connector retirement — with no missed notifications. I will provide: - An inventory (or a way to discover it) of connector webhook URLs in use - Who/what posts to them (CI, monitoring, scripts, third-party SaaS) - The current payload format (legacy MessageCard vs adaptive card) - Constraints (which senders I can change vs cannot, change windows) Your job: 1. **Risk framing** — state the retirement reality plainly: legacy connector URLs stop working, and many senders post deprecated `MessageCard` JSON. Identify which of my integrations are most exposed. 2. **Discovery** — how to inventory existing connector webhooks across teams/channels (admin tooling, Graph, and asking owners), and tag each by sender, payload format, and who can update the URL. 3. **Target design** — stand up a Power Automate "When a Teams webhook request is received" Workflow per channel/use-case, producing the new HTTPS POST URL. Decide one-workflow-per-sender vs a shared router workflow that fans out by payload. 4. **Payload translation** — for senders that emit legacy MessageCard and that I CANNOT change, build a translation step inside the Workflow (or a thin proxy) that converts MessageCard → adaptive card so the message still renders well. Provide the mapping for common fields (sections, facts, potentialAction). 5. **Cutover plan** — dual-run where possible (point a copy of traffic at the new URL, compare), then swap URLs sender-by-sender with rollback. For senders you can't touch, front them with a proxy that accepts the old shape. 6. **Hardening** — secret the new URLs, add a shared-secret check, and add failure alerting so a broken Workflow is noticed. Output as: (a) an inventory template, (b) the Workflow definitions (or shared-router design), (c) the MessageCard → adaptive card mapping, (d) a per-sender cutover/rollback runbook, (e) a verification checklist confirming nothing went dark. Bias toward: dual-run before cutover, a proxy for unchangeable senders, and verifying delivery over assuming it.