Adaptive Card AI Generator

What is an Adaptive Card?

An Adaptive Card is a block of UI described as JSON rather than as markup for one specific platform. You send the payload; the host application renders it using its own styling. The same card looks native in Microsoft Teams, in a Viva Connections dashboard, and in Outlook, because each host ships its own renderer and applies its own theme, spacing, and font stack.

Every card has the same skeleton: a $schema, type: "AdaptiveCard", aversion, a body array of elements, and an optional actions array. The body holds elements such as TextBlock, Image, FactSet,ColumnSet, and Input.*. There is no CSS and no custom font — that constraint is the point, because it is what lets one payload render correctly everywhere.

The version field is the thing that breaks cards

More cards fail on version than on anything else. The version you declare is the schema your card requires, and a host that implements a lower version will refuse to render it or fall back to plain text. Teams has historically trailed the published schema, so a card built against the newest version in the online designer can preview perfectly and then arrive in Teams as an empty bubble.

The practical rule: target the lowest version that supports the elements you actually use, and treat the designer preview as necessary but not sufficient. Elements introduced after your declared version can be guarded with fallback, and requires lets you mark an element as host-dependent so the rest of the card still renders.

Where Adaptive Cards appear in Microsoft 365

• Teams bots and messaging extensions — cards posted into a conversation, and the dialogs (formerly task modules) opened from them.
• Power Automate — the Post adaptive card actions for Teams, including the wait-for-response variants that block a flow until someone clicks a button in the card.
• Viva Connections — Adaptive Card Extensions render their quick view from a card template, though the ACE surface supports a deliberately narrow subset of elements.
• Outlook actionable messages — the same JSON, but a separate approval and sender verification process, and a schema version that lags Teams.

One migration worth knowing about: Office 365 connectors and the old incoming-webhook route into Teams have been retired in favour of Power Automate Workflows. If you maintain a script that POSTs a card JSON to a webhook.office.com URL, that is the pattern being replaced, and the card payload itself carries over to the Workflows equivalent largely unchanged.

Separating the card from its data

Hand-building a payload per record does not scale. Adaptive Card Templating splits the layout from the values: you write the card once with ${placeholders} bound to fields, then bind a data object at send time. In an SPFx web part or a bot you use theadaptivecards-templating package; in Power Automate you interpolate dynamic content into the JSON directly. Either way the card becomes a template you can review, and the data stays in one place.

Submit versus Execute

Action.OpenUrl is a link. Action.Submitposts the card's input values back to whatever sent it — the simple choice, and the right one for a flow that is waiting on a response.Action.Executeis the universal-actions model: it requires a bot behind the card, and in exchange the bot can return a refreshed card so everyone viewing the message sees the updated state. If you want an approval card that visibly changes to "Approved by…" for the whole channel rather than only for the person who clicked, Action.Execute with a refresh block is what does it.

Things that go wrong

• Images do not appear.Image URLs must be publicly reachable over HTTPS. A link to a SharePoint asset that requires authentication renders as a blank space, because the Teams renderer fetches it without the viewer's credentials.
• The card is silently truncated or rejected. Teams caps the payload size, so large base64-inlined images or long FactSet tables are a real limit rather than a theoretical one.
• It looks right in the designer and wrong in Teams. Almost always the declared version, or an element the host does not implement. Test in the actual host before shipping.
• Inputs come back empty. Every Input.* needs an id; without one the value is not included in the submit payload.