✅ Build Deploy and Change Approval Workflows in Microsoft Teams

Approval gates are where a lot of DevOps automation goes to die. Either they’re so heavyweight that people route around them, or they’re so casual (“just thumbs-up in chat”) that there’s no record when an auditor comes knocking. Teams sits in the sweet spot: it’s where people already are, and with adaptive cards you can build an approval that’s one click and fully auditable.

Here’s how I build approval workflows that engineers don’t resent and compliance actually trusts.

The shape of a good Teams approval

Every approval I build has the same anatomy:

1. A trigger — a pipeline, a script, or a request form fires it.
2. A context-rich card — the approver sees what they’re approving and why without leaving Teams.
3. Action buttons — Approve / Reject, ideally with a comment.
4. A blocking wait — the requester (pipeline) pauses until a decision.
5. An audit record — who, when, what decision, what comment.

Miss #2 and people rubber-stamp. Miss #5 and you’ve built chat, not governance.

The approval card

Context is everything. An approval card with just “Approve this deploy? [Yes] [No]” gets blind-clicked. Give the approver what they need to decide:

{
  "type": "AdaptiveCard",
  "version": "1.5",
  "body": [
    { "type": "TextBlock", "text": "Deploy approval: checkout-api", "weight": "Bolder", "size": "Large" },
    {
      "type": "FactSet",
      "facts": [
        { "title": "Version", "value": "v2.8.1 (from v2.8.0)" },
        { "title": "Environment", "value": "production" },
        { "title": "Requested by", "value": "alice@corp" },
        { "title": "Changes", "value": "12 commits, 3 migrations" },
        { "title": "Tests", "value": "✅ passed" }
      ]
    },
    {
      "type": "Input.Text",
      "id": "comment",
      "placeholder": "Optional comment",
      "isMultiline": true
    }
  ],
  "actions": [
    { "type": "Action.Submit", "title": "Approve", "data": { "decision": "approve" } },
    { "type": "Action.Submit", "title": "Reject", "data": { "decision": "reject" } }
  ]
}

The diff summary, migration count, and test status turn a rubber stamp into an actual decision. The Input.Text captures why a reject happened, which is gold during a retro.

Wiring it up: two solid options

Power Automate is the fastest path. “Post adaptive card and wait for a response” blocks the flow until someone clicks, then your branch logic returns the result to the calling pipeline via an HTTP response. No server to run. I cover the broader flow patterns in Power Automate for DevOps.

A custom bot (Bot Framework) gives you more control — richer logic, your own storage, Action.Execute callbacks. Reach for it when approvals need to integrate deeply with your platform. For most teams, the flow is enough.

Either way, your CI pipeline calls the approval endpoint and waits:

- name: Request prod approval
  run: |
    DECISION=$(curl -s -X POST "$APPROVAL_URL" \
      -H "Content-Type: application/json" \
      -d "{\"service\":\"checkout-api\",\"version\":\"v2.8.1\"}")
    [ "$DECISION" = "approve" ] || exit 1

The audit trail is the whole point

Log every decision to durable storage — a SharePoint list, a database, anything that isn’t chat scrollback. Record approver identity, timestamp, decision, comment, and the request payload. When someone asks “who approved the change that broke prod on the 11th,” you run a query and answer in ten seconds instead of scrolling a channel.

This is also what makes Teams approvals pass an audit: the evidence is structured and immutable, not a message someone could edit.

Where AI helps — and where it must not

AI is genuinely useful on the requester’s side of an approval: summarizing what a change actually does so the approver decides faster. A model can turn “12 commits, 3 migrations” into “adds a nullable column, bumps a timeout, no schema-breaking changes” — and that summary goes in the card for the human to read.

What AI must never do is be the approver. The point of an approval gate is human accountability; a model auto-approving defeats it entirely. Use AI to make the human’s decision better-informed, never to replace the human. The prompt library has change-summary prompts that fit this exactly.

Guardrails that keep approvals honest

A few rules I enforce:

• Approver ≠ requester. The card should reject self-approval. Alice can’t approve Alice’s deploy.
• Timeouts have a safe default. If nobody responds in N minutes, default to reject, never approve. A silent channel must not ship to prod.
• Severity-tiered approvers. A config tweak needs one approver; a schema migration needs two and a senior. Encode the policy, don’t rely on judgment at 5pm Friday.
• Idempotent triggers. A retried pipeline shouldn’t spawn five approval cards.

Start with the gate that scares you most

Don’t approval-gate everything — that breeds resentment and route-arounds. Find the one change type where a bad decision hurts most (prod schema migrations, IAM changes, anything irreversible) and put a clean, context-rich, audited Teams approval in front of it. Prove it’s fast and trustworthy, and the team will ask you to extend it. A good approval feels like a safety net, not a speed bump.

AI may summarize a change to inform an approver, but it must never auto-approve. Human accountability is the entire purpose of an approval gate.