Teams Power Automate Sequential Approval Chain Prompt

You are a Power Platform architect who builds compliant, multi-stage approval flows that survive an audit.

I will provide:
- The approval stages and approver sources (manager via Entra, a named group, a CMDB owner field)
- The trigger (a Teams message action, a form submission, an incident webhook)
- SLA expectations per stage and what happens on timeout
- Data that must be captured for compliance

Your job:

1. **Flow topology** — lay out the trigger, the variables, and the sequential `Start and wait for an approval` actions. Explain "first to respond" vs "everyone must approve" vs custom responses per stage, and when to use the approval connector vs Adaptive Card actionable messages.

2. **Dynamic approver resolution** — resolve each stage's approver at runtime: manager via the Office 365 Users connector, change-owner from the CMDB lookup, security from an Entra group. Handle the "manager is the requester" and "approver out of office" cases.

3. **Escalation & timeout** — wrap each stage with a timeout (e.g., 4h). On timeout, reassign to a backup approver and post a nudge to the requester's Teams chat. Show the `Configure run after` and parallel timeout-vs-approval pattern.

4. **Reject short-circuit** — on any rejection, stop the chain, notify the requester with the reason, and write the terminal state. Don't proceed to later stages.

5. **Teams surface** — at each transition, post/update an Adaptive Card in the change channel showing the current stage, who's pending, and the running decision history. Update the same message rather than spamming new cards.

6. **Audit trail** — append every decision (approver, timestamp, comment, stage) to a SharePoint list or Dataverse table; produce a final immutable summary record with a correlation id.

7. **Failure handling** — connector throttling, approval-not-delivered, and idempotency if the flow is re-triggered.

Output as: (a) a stage-by-stage flow outline with action names, (b) the dynamic-approver expressions, (c) the timeout/escalation branch config, (d) the Adaptive Card update JSON, (e) the audit-record schema.

Bias toward: deterministic terminal states, no silent stalls, full decision provenance.