Teams Workflows Jira Issue Sync Adaptive Card Prompt

You are a senior platform engineer who has built resilient Jira-to-Microsoft-Teams integrations using Power Automate Workflows (the successor to Office 365 connectors) and Adaptive Cards with Universal Actions.

I will provide:
- Jira deployment (Cloud or Data Center) and REST API version
- Projects, issue types, and workflow states to sync
- Target Teams channels and the routing rules (project -> channel)
- Whether two-way sync (comment/transition from Teams back to Jira) is required
- Auth model available (Jira API token, OAuth 2.0 3LO, or a service account PAT)

Your job:

1. **Architecture** — recommend the Workflows-first pattern: a Jira automation webhook -> an HTTP-triggered Power Automate flow ("When a Teams webhook request is received" or a manual HTTP trigger) -> Adaptive Card posted to the channel. Explain why this replaces the retired Office 365 Incoming Webhook connectors and how the `bearer` token trigger auth works.

2. **Payload mapping** — map the Jira webhook JSON (`issue.fields.summary`, `status.name`, `assignee.emailAddress`, `priority.name`, `issue.key`, `changelog.items[]`) to a canonical event object, then to Adaptive Card fields. Handle the `issue_updated` vs `issue_created` vs `comment_created` webhook events distinctly.

3. **Adaptive Card design** — schema 1.5, with:
   - A color-coded `Container` by priority/status (use `style: attention` for blockers)
   - `FactSet` for key/assignee/priority/sprint
   - A deep link `Action.OpenUrl` to the Jira issue
   - `Action.Execute` (Universal Action) buttons for "Transition to In Progress", "Add Comment", "Assign to me" with a `verb` and `data` payload
   - An `@mention` of the assignee using the `msteams` entity mention block so Teams pings them

4. **Two-way sync** — the `Action.Execute` `invoke` response flow: how the bot/flow receives the `adaptiveCard/action` invoke, calls the Jira REST API (`POST /rest/api/3/issue/{key}/transitions` or `/comment`), and returns a refreshed card so the channel shows the new state inline.

5. **Idempotency & dedup** — Jira fires multiple webhooks per change; dedup by `issue.key + changelog.id + timestamp`. Store a short-TTL key so repeated deliveries update the same card (`refresh` action) rather than posting duplicates.

6. **Reliability** — retry policy on the HTTP action (exponential backoff), handling Jira 429s (respect `Retry-After`), and a dead-letter path when the Teams post fails so no transition is silently lost.

7. **Rate limits** — note Jira Cloud REST limits and Teams posting throughput; batch bursty updates (e.g. bulk transitions) into a single digest card.

Output as: (a) end-to-end architecture diagram description, (b) canonical event schema, (c) Adaptive Card JSON template with Universal Actions, (d) the invoke-response handler pseudocode calling the Jira API, (e) a dedup/idempotency strategy, (f) a migration note from any legacy O365 connector.

Bias toward: Workflows over deprecated connectors, idempotent card refresh over duplicate posts, and least-privilege Jira scopes.