Adaptive cards in Teams

What it does

Adaptive cards are JSON-defined blocks of UI that render natively in the host that receives them. In Power Automate the Teams connector posts them as the Flow bot, either fire-and-forget or as a card the flow waits on, which is how you collect a decision or a few fields from someone without building a form.

Key facts

Four relevant actions: post a card to a user, post a card to a channel, and the "and wait for a response" variants of each.
The waiting actions pause the flow until someone responds. For a user card that's the named recipient; for a channel card it's anyone in the channel who responds first.
Dynamic content comes back for one response per recipient per card. Once submitted, the flow continues and further submissions are ignored.
Cards posted without a "wait for a response" action can't collect data. Every button except Action.OpenUrl returns an error, and Action.Submit on a non-waiting card shows an error to the user.
Posting to a user by email address works even if the recipient isn't in the Teams instance. Posting to a channel requires the flow maker to have access to that Teams instance.
After submission the card resets and looks identical unless Update message and Should update card are configured. Only what's in the Update message box appears on the replacement card.
Adaptive cards aren't available in DoD environments.
Cards are authored in JSON; the adaptive card designer at adaptivecards.io produces the payload you paste in.

When to use / skip

Reach for these when you need a lightweight decision or a handful of inputs from someone already living in Teams — approve/reject with a comment, pick a category, confirm a record. Skip them for anything with real approval semantics: reassignment, delegation, audit history and a mobile approvals experience all come free with the Approvals action and cost you real effort to rebuild on cards. Skip them too for anything with more than a screenful of inputs; that's a Power App.

Configuration decisions

Card to a user or to a channel — channel cards mean whoever responds first owns the outcome, which is either exactly what you want or a governance problem.
Whether the flow waits, and if so what the timeout and escalation path is when nobody responds.
What the update message says after submission, and whether it names the responder.
Whether responder identity matters enough to add an Office 365 Users lookup after the response to resolve the profile.
Where the card JSON lives — inline in the action, or in an environment variable so it can be changed without editing the flow.

Gotchas

The submitting user's details aren't on the card itself. You get them from the dynamic content of the wait action, and often need the Office 365 Users connector to turn an ID into a name.
Without an update message the card sits there looking unanswered, and people submit it again. The second submission goes nowhere and they log a ticket.
A waiting card holds the flow run open. Long waits interact badly with flow run duration limits and with the client's expectation that the flow "finished".
Channel cards are visible to everyone in the channel. Anything on the card is disclosed to the whole channel — a real problem for HR and finance scenarios.
Card JSON that renders perfectly in the designer can still render differently in Teams mobile. Test on a phone before sign-off.

Consultant notes

Position cards as a notification-plus-decision mechanism, not as an approvals platform. When a client asks for "approvals in Teams", find out whether they mean the Approvals action or a card — the answer changes the estimate substantially.
Warn about the channel disclosure point explicitly in design. It's the one that gets escalated after go-live.
Cards age badly when nobody owns the JSON. Keep it out of the flow definition where you can, and name an owner.

Worth revisiting if the Teams connector gains new card actions, or if the client moves approvals onto a different rail