Posting Interactive Adaptive Cards to Teams from Power Automate

Email approvals are too heavy for many operational decisions, and Teams messages without inputs create follow-up work. The Power Automate action Post adaptive card and wait for a response gives you a middle path: show context, collect structured input, and continue the flow with the responder's data. The trick is designing the card like a small workflow screen, not a decorated message.

Use the wait action when the response drives the flow

Post adaptive card and wait for a response pauses the flow until someone submits the card. You can post to a channel, group chat, or user, depending on the connector action and available options in your tenant. The submitted values become dynamic content for later actions.

Use this when the next step depends on a short response: choose a category, enter a reason, confirm a date, or assign ownership. If you need formal approval history, delegation, reassignment, escalation, and approval center visibility, use the Approvals action instead.

Need	Better choice	Reason
Collect two fields from an operator	Adaptive card	Lightweight and structured
Formal approve or reject audit	Approvals	Built-in approval tracking
Ask a manager for a comment	Adaptive card	Faster than email
Multi-stage approval chain	Approvals	Lifecycle support
Update a work item after response	Adaptive card	Direct data capture

Do not turn every approval into a card. Adaptive cards are excellent for interaction, but they do not replace governance features built into the Approvals connector.

Design the card in the Adaptive Cards designer first

The designer prevents most JSON mistakes. Build the card in the Adaptive Cards designer, choose the Microsoft Teams host app when available, and keep the version conservative. Teams support varies by client and card feature, so avoid using the newest schema feature unless you have tested it across desktop, web, and mobile.

A practical first card includes a title, facts, one text input, one choice input, and an Action.Submit button. Keep labels explicit. The person responding should not need to open the flow or source system to understand the request.

{
  "type": "AdaptiveCard",
  "version": "1.4",
  "body": [
    {
      "type": "TextBlock",
      "text": "Review customer escalation",
      "weight": "Bolder",
      "size": "Medium"
    },
    {
      "type": "FactSet",
      "facts": [
        { "title": "Customer", "value": "Contoso Retail" },
        { "title": "Ticket", "value": "INC-10482" }
      ]
    },
    {
      "type": "Input.ChoiceSet",
      "id": "decision",
      "label": "Decision",
      "style": "expanded",
      "choices": [
        { "title": "Accept", "value": "accept" },
        { "title": "Defer", "value": "defer" }
      ]
    },
    {
      "type": "Input.Text",
      "id": "comment",
      "label": "Comment",
      "isMultiline": true
    }
  ],
  "actions": [
    {
      "type": "Action.Submit",
      "title": "Submit",
      "data": {
        "action": "escalationReview"
      }
    }
  ]
}

Use stable input IDs. The IDs become keys in the response payload. Treat them like an API contract. Rename the visible label whenever you want, but changing decision or comment breaks downstream expressions.

Capture submitted values and the responder

The response contains both card data and user context. After the wait action, use the dynamic content for submit action ID, responder display name, responder email, and the data object. The exact labels vary by connector version, so inspect a test run before writing final expressions.

For predictable downstream handling, compose a normalized response object:

{
  "decision": "accept",
  "comment": "Customer impact is confirmed. Proceed today.",
  "responderEmail": "alex@contoso.com",
  "responderName": "Alex Wilber",
  "submittedAt": "2026-04-29T09:15:00Z"
}

Validate the response before acting. If the comment is required for a defer decision, check it after submission. Adaptive Card required field behavior can vary by host and version, so server-side validation in the flow is still the safe move.

Choose the posting target deliberately

Channel cards create shared visibility. Use them for team queues, operational triage, and decisions where multiple people need context. The downside is that anyone with access may see the card, so avoid sensitive details unless the channel is appropriate.

Chat or user cards are better for targeted asks. Post to a specific user when accountability matters. Post to a group chat when a small working group owns the decision. Be clear in the card text about whether the first response wins or whether a named person should submit.

Target	Best for	Design note
Channel	Queue triage and shared operations	State who should respond
Group chat	Small incident or delivery team	Keep context concise
User	Direct ownership	Include due date and source link
Flow bot	Standard automation identity	Explain why the bot is asking

Avoid hidden decision rules. If the first response continues the flow, say that in the card. If only a specific role should respond, say that too. Teams is a collaboration surface, not a permission model.

Update the card after response

A submitted card should not look open forever. After the flow receives a response, post a follow-up message or update the original card when the action supports it. Show the decision, responder, and timestamp so the conversation has a clear record.

{
  "type": "AdaptiveCard",
  "version": "1.4",
  "body": [
    {
      "type": "TextBlock",
      "text": "Escalation review completed",
      "weight": "Bolder"
    },
    {
      "type": "FactSet",
      "facts": [
        { "title": "Decision", "value": "Accept" },
        { "title": "Responder", "value": "Alex Wilber" },
        { "title": "Comment", "value": "Customer impact is confirmed. Proceed today." }
      ]
    }
  ]
}

Close the loop in the source system too. Update the SharePoint item, Dataverse row, Planner task, or ticket that started the card. Teams should be the interaction layer, not the only system of record.

Version support should shape the card

Teams does not always support every Adaptive Card feature immediately. Choose a schema version that meets the requirement and test it in the clients your users actually use. Inputs, choice sets, text blocks, containers, and submit actions are safe foundations. Exotic layout features can wait.

Keep cards short. Put deep details behind a link to the source record. Make the action button specific, such as Submit decision, Assign owner, or Confirm schedule. Generic buttons create ambiguous audit trails.

Interactive cards work best when they remove one small bottleneck. Design the card, post it to the right audience, capture a normalized response, and update the record. If the decision needs formal approval governance, use Approvals. If it needs fast structured input in the flow of work, Adaptive Cards are the sharp tool.