Unlocking True Interactivity in Teams Cards

Think Adaptive Cards are just pretty dashboards? What if I told
you they can capture real-time feedback, launch workflows, and
even trigger bots—without needing the user to leave Teams?If
you’re tired of static cards that don’t do much, stick around.
We’ll break down the core features that turn your cards into
interactive experiences, with hands-on JSON examples and live
demos. Ready to ditch boring notifications and actually engage
your team?


Beyond Static: What Makes Adaptive Cards Worth Your
Time


If you’ve ever posted a Teams Adaptive Card and called it good
because it looked pretty, you’re not alone. Most Teams channels
have at least a few notifications that were supposed to make life
easier, but really just dress up plain information with a splash
of color or the company logo. I get it—when you first land in the
Adaptive Card playground, sticking an image on a card feels like
a solid win. It looks official, maybe even a little more modern
than the standard Teams post. The problem is, this is where most
people stop. Behind the scenes, those cosmetic changes do very
little to push your workflows forward or actually save time for
people using Teams every day.Now, let’s be honest—Teams is
already full of noise. Channels get flooded with status updates,
system alerts, and reminders. Slapping branding on static cards
doesn’t make them more useful. You’re just adding to the pile.
It’s no wonder that half the team ignores notifications the
second they recognize that familiar rectangle crammed with
nothing but text. Jump over to the next message; the card is just
part of the background hum at this point. But when we talk about
Adaptive Cards, there’s something everyone keeps missing: these
things aren’t designed to just broadcast information. They’re
built as connectors between Teams and your business processes.
They’re not static dashboards to admire—they’re interactive
containers that can actually do some of the heavy lifting for
your team, if you use them the right way.Microsoft actually
measured the difference. Teams users interacting with cards that
respond to their input engage up to three times more often than
with cards that just display static content. You’d think that
with engagement numbers like that, we’d see cards doing more than
announcements and generic reminders. But for most organizations,
building a card starts and stops with “how do I make it look like
it came from our comms department?” That’s missing the entire
point of why Adaptive Cards exist in the first place. The magic
happens when those cards start talking to your systems and
responding to your users—not just looking pretty in the feed.Of
course, there’s a reason a lot of us settle for bringing in
images and calling it a day. Glance at an Adaptive Card’s JSON,
and for a lot of people, that’s where the eyes start to glaze
over. It doesn’t look inviting. But this is the foundation you
need. Every Adaptive Card is just a JSON payload once you peel
away the UI. There’s no way around that. If you can get
comfortable reading and making small tweaks to that structure,
suddenly you’re in total control—which is where things start to
get interesting. You can swap in data, pull in images
dynamically, and decide when a user should see a certain button
or message.There are three basic puzzle pieces to every Adaptive
Card: type, body, and actions. Let’s break that down. The “type”
tells Teams what it’s looking at—a card, or a specific element
inside a card. The “body” is what people see: text, images,
containers, columns, all laid out the way you want. And “actions”
are what take your card from display-only to interactive. That’s
where your buttons, submit actions, or links live. Get familiar
with these parts, and suddenly you’re not stuck copying templates
from Microsoft’s gallery. You can build cards that seem basic at
first, but layer on real value as you iterate.Let’s look at a
quick before and after. Picture a plain card that just lists
“Quarterly Policy Update.” No images, just text. Now, next to it,
a card with your company branding, a friendly icon, and a
highlighted title. Sure, the latter looks more professional.
Maybe you swap the standard background for your corporate color.
That’s fine, but it doesn’t really change how your team interacts
with the information—people still see it as another item to
scroll past.But let’s be clear, cosmetic upgrades are only the
first step. The real advantage with Adaptive Cards comes when you
realize you’re holding a way to glue Teams directly onto your
underlying business processes. These cards aren’t passive. They
can kick off workflows, gather direct input, and feed information
back to your apps with almost zero friction. As soon as you put a
button or input field on the card, the game changes. Now, instead
of someone reading and mentally filing away a policy update, you
can ask for feedback, start an approval, or launch a support
ticket, all in a single click without leaving the
conversation.That leads us to what really matters: once you
understand the structure of a basic Adaptive Card, adding just a
few building blocks can create a foundation for much richer
interactivity. Every small feature you add—be it a text input, a
simple button, or a drop-down—pulls your team one step closer to
doing real work right inside Teams, not just monitoring a steady
stream of announcements. The first step, though, is getting
beyond just making things pretty. If you want Adaptive Cards that
actually make a difference, you need to understand what’s
possible underneath the surface.Next, let’s start laying down
some basics—how small elements like text, images, and thoughtful
branding don’t just decorate the card, but actually pave the way
for making Teams an interactive hub, not just another
notification channel.


From Display to Dialogue: Capturing Input Right in
Teams


You finally have a Teams Adaptive Card that actually looks like
it belongs there—branding in place, layout on point, and the
title doesn’t make anyone’s eyes glaze over. But then reality
sets in. Most cards, even the decent-looking ones, just sit in a
channel waiting for someone to read them and move on. There’s a
reason people tune these out—because after that first glance,
there’s nothing left for them to do. Static cards announce
things. They don’t ask questions, collect insights, or give
anyone a reason to engage. If you’ve been on the receiving end of
a policy update from HR, you know what I mean. A wall of text,
maybe an image, and zero opportunity to react beyond an emoji or
a follow-up message buried in a thread.Let’s say HR wants
employee feedback on a new dress code. The update goes out, and
you hope for replies. What you get is silence, maybe a stray
“thumbs up” if you’re lucky. Static cards just echo through the
channel. Now imagine instead that card includes a text box right
inside the post—a simple question and a spot for employees to
share real opinions. People don’t have to open another doc,
switch over to a survey link, or keep track of some random
Outlook thread. They just answer, right there. Suddenly, Teams
feels like more than just a broadcast tool; it actually starts to
listen.There’s this myth floating around that adding input fields
to Adaptive Cards is difficult. It’s the classic “too much JSON”
problem, as if you’re about to rewrite the Windows registry every
time you want to add a question. In reality, capturing input can
be as simple as dropping in a new block to your card’s JSON. No
huge learning curve, no massive payloads. Take a look at this
basic snippet: just a few lines like `{ "type": "Input.Text",
"id": "policyFeedback", "placeholder": "Share your thoughts..."
}`. That’s it. You’re asking for input, and the card will grab
whatever someone types in. Teams isn’t just pushing info out
anymore; it’s actually holding a conversation with users and
creating a direct channel for feedback.And it’s not just about
free text. Sometimes you need structured responses—maybe a
rating, a number, or a specific date. Adaptive Cards support
several different input types, each tailored for different needs.
Want users to type out their ideas? Use Input.Text. If you need a
headcount for an upcoming event or want to set a budget limit,
switch to Input.Number. Dates are common for things like holiday
requests or follow-ups, and Input.Date plugs right into Teams’
calendar experience, letting people pick without format errors or
manual typing. The kicker? Each input type takes only a small
tweak to your JSON. It’s all about knowing what business outcome
you need and choosing the format that makes life easier for both
sides.Live, it’s actually smoother than people expect. Let’s say
you add that text field for policy feedback and hit send. When
your colleague types in their feedback and hits submit, the
answer is captured instantly—no new tabs, no extra windows, and
nothing lost in translation. Teams acts like the input layer for
your apps, and you stay within the same conversation. The
friction of hopping between tools or copying and pasting answers
just disappears. People start responding more, too, because it’s
the easiest route.But smart as this all sounds, it’s easy to trip
yourself up if you rush. Every input you build—text, number, or
date—needs to be wired up with an “id” tag. This “id” is what
lets your bot or backend grab the actual answer that comes back.
Miss the “id” and the feedback vanishes into thin air, like an
unfiled form. Another place people get stuck: combining different
inputs and not matching the data types. If you gather an email
but mark it as a number input, Teams isn’t going to guess your
intentions. Mobile users add another layer of complexity, with
some layouts crumpling on smaller screens. Always preview your
cards on both desktop and mobile before rolling them out
wide.There’s one tool that can save you headaches early: the
Adaptive Card Designer. It’s a web-based sandbox where you plug
in your JSON, see the card rendered live, and spot errors before
you ever bother with deployment. Not only does it catch syntax
problems, but it also shows how the card responds on different
platforms. For anyone making more than a handful of Adaptive
Cards, it’s an essential part of the process. You wouldn’t push
untested code to production—don’t do it with your cards,
either.Where you land is a workflow that finally captures
structured, actionable data, right at the point where it
matters—while people are reading and reacting in Teams. No more
chasing answers across emails or Forms links, or piecing together
Excel sheets from a half-hearted sample of the team. Your data is
captured in context and ready to be plugged into whatever system
needs it next.Collecting input, though, is only half the game.
The bigger win is what you do with that input once you have it in
hand. The next step is connecting those responses to live
actions—automating follow-ups, routing tickets, or kicking off
more detailed tasks—all directly from inside your Teams card.


Triggering Action: Buttons, Bot Conversations, and the
Hidden Power of Actions


Once your Adaptive Card can grab an answer, the obvious next
question is: what do you want to happen with that input? This is
where most people either overcomplicate or underdeliver. They
either try to plug in something fancy and wind up with a broken
button, or they default to the easy route: slap an “OpenUrl” on a
card and watch as everyone clicks out of Teams into some external
survey or web app. It gets the job done, but you lose all the
context and flow of the conversation. Someone fills out your
form, maybe, but good luck pulling them back to Teams afterwards.
The irony is, Adaptive Cards can do way more here, and most
people never touch the features that let them keep users
engaged.Let’s take a step back and look at what actually happens
when someone taps a button in a card. There are two primary
actions most people use: “Action.OpenUrl” and “Action.Submit.” On
paper, the JSON looks similar. “OpenUrl” has a target link—users
click, a new browser tab opens, and Teams just handwaves that
interaction away. You get to say you sent a link, and maybe your
analytics platform logs a visit, but you’re not building real
interactivity into Teams.Here’s how that looks in the wild. The
“OpenUrl” action might look like this: `{ "type":
"Action.OpenUrl", "title": "Learn More", "url":
"https://contoso.com/policy" }` When a user taps it, they leave
the Teams client. It’s fast, but there’s zero way to collect a
response or trigger Teams-native workflows.Now compare it to: `{
"type": "Action.Submit", "title": "Submit", "data": {
"feedbackType": "policy" } }` With “Action.Submit,” the card
doesn’t just fire off a website—it packages up any data the user
has provided in the card (inputs, dropdowns, selections), tags it
with any hardcoded info you provide in the “data” property, and
delivers it straight to whatever service is listening. This could
be your Teams bot, a Power Automate flow, or even a custom
endpoint. Suddenly, pressing a button isn’t just a dead end—it’s
the start of a process.That’s where the hidden power comes in. If
your org already uses Power Automate or has bots registered in
Teams, you can wire the submit action to trigger any flow you
want. For feedback, you might log it in SharePoint, send a
summary to a manager, or generate a task. For approvals, you can
route an instant decision into your workflow software. The
“Submit” action is effectively the glue between Teams and the
rest of M365, and you don’t have to know any C# or Node.js to get
started—most of this can be built visually or with low-code
tools.Now, Teams 2.0 and updated bots take it further with
“Action.Execute.” Unlike the older “Submit,” this lets bots
respond dynamically. Based on the context—who clicked, what they
entered, even properties of their Teams environment—you can craft
conditional actions right from a single button press. You could
have a card that asks users to RSVP, then instantly shows updated
info based on their response, offers next steps, or branches them
into a separate extended convo with your bot.The real-life
effect? Imagine a support request comes in—user fills out the
problem on a card, presses submit, and the card not only thanks
them but asks a clarifying follow-up, all within the same Teams
thread. Or a survey where the next question adjusts on the fly
depending on the previous answer. That’s the kind of
interactivity that keeps people in Teams, instead of shuffling
them out to awkward secondary websites.Of course, none of this
works unless you wire up the backend logic. This is where people
get tripped up. The “Action.Submit” hands off a payload of all
card data, and your backend—bot, flow, or app—needs to be ready
to accept, process, and respond. If you leave that piece undone,
your button becomes an orphan, with nowhere to send the data. For
bots, you’ll need to catch the activity, analyze the payload, and
decide what message or card to serve up next. With Power
Automate, you map the fields and build your automations from
there. It’s not about fancy code, but about making sure that data
has somewhere meaningful to land. That backend can then reply,
update the card, or kick off new actions automatically.Where
cards really shine is in enabling multi-step business processes.
Maybe it starts with a quick poll, but you use the data to drive
a sequence—logging a request, creating an approval loop, or
looping in additional reviewers as needed. All of it can stay
inside Teams, which is where your users already spend their day.
Over time, you move from using cards as fancy notifications to
building real, workflow-driven interactivity. No more dead-end
links—each click is a live part of your business logic.Now, once
your buttons start driving actual processes in the background,
you’ll want to go a step further. How do you make sure the
experience feels targeted—showing different content or actions
based on who’s interacting, or on changing business rules? That’s
where personalizing cards and layering in logic comes into play.


Personalized and Dynamic: Data Binding and Conditional
Logic


If you’ve ever wondered why most Adaptive Cards end up looking
and acting exactly the same for every user, it’s probably because
they’re built with hardcoded content—whatever went into the
payload when the card was created, that’s what shows up for
everyone. It works fine if you’re just reminding an entire
channel about a holiday party or sending a general notice. But
let’s be honest: most real business scenarios need more nuance.
Everyone’s workday is already jammed with notifications and
status updates; one-size-fits-all messages just disappear into
the flood. At some point, you want your cards to feel
smarter—maybe greet people by name, only show approval options to
the right folks, or even shift their look and feel based on
updates in your backend system. Adaptive Cards were built to do
all that, if you use data binding and conditional logic the right
way.Think about a card welcoming new team members. Hardcoded, it
might say, “Welcome to the team!” and leave it at that. Now
imagine something that pulls in information directly from Teams,
like a personal welcome: “Welcome, Priya!” or “Glad you’re here,
Alex.” It’s a small tweak, but it makes the message land a little
better. That’s data binding in action. Instead of locking
yourself into static values, you drop placeholders—little
template tags—in your JSON. For Teams, that might look like
`"text": "Hello, ${user.name}!"`. At runtime, Teams swaps in the
actual username, so every person gets a card that feels like it
was written for them, not just a generic template reused for
every new hire.The same logic extends to just about any data
point you can get into your card payload. Task lists, deadlines,
project names—if your backend can pass it, you can display it.
Approvals are a classic example where dynamic cards make sense.
Picture a card that needs to check if a user’s task is complete
before showing them a button to send a reminder. If you hardcode
that button, everyone sees it—even those who finished their work
three days ago. But with conditional logic, you can tune the
visibility of elements based on the data in your payload. In
practice, it might look like adding a property to an action or
container: { "type": "Action.Submit", "title": "Remind",
"isVisible": "${task.status !== 'completed'}"}Now, only users who
still have open tasks will see the “Remind” button. Everyone else
gets a cleaner, less cluttered card. Simple, but it makes a
difference—especially once your organization expects personalized
workflows inside Teams.This is where cards go from being digital
flyers to something closer to dynamic web apps. You’re not just
dropping in strings and images; you’re letting the entire card
react to real-world updates. A hiring manager might see a card
with a summary of outstanding candidates, while a new employee
sees a checklist of onboarding tasks—same underlying card, but
the payload changes everything. And because Teams passes context
about the user, the team, and sometimes even specific message
threads, you can get creative about which data shows up, and
when.One demo a lot of folks find useful is watching a card
update in real time as the underlying data changes. Imagine a
status board where project progress bars fill up without anyone
hitting Refresh, or a poll that only allows responses until the
end of the week—after that, the input fields disappear, and a
“Thank you for voting” message takes their place. No more
one-size-fits-all notifications. Suddenly, the card matches the
real workflow, not just the intent.The trick to making all this
work is keeping your logic readable and your data sources
reliable. Overcomplicated bindings can make life miserable when
it’s time to troubleshoot. If there’s one pattern that leads to
headaches, it’s splicing together complex conditional statements
for every single element. Start simple: show or hide elements
based on easily understood fields, sync up what you send in your
payloads and what you reference in the card’s template, and
always test edge cases—like what happens if a field is missing or
null. And never, ever skip mobile testing. The number of cards
that break or render poorly on a phone is still way too high. Use
the Adaptive Card Designer to preview your JSON and make sure it
lands right on both desktop and mobile.Here’s a pro tip that’ll
save you hours: split your layout from your logic with
templating. Adaptive Cards support templates, where one file
describes how your card should look, and another pushes in the
unique data for each user or situation. It’s cleaner, easier to
maintain, and, down the line, far simpler to update. When you get
a request to change a headline or add a field, you’re just
updating the data or template—no need to rework the whole card.
It’s the IT equivalent of decoupling the front end from the
backend, and it keeps your card logic from spiraling into
maintenance debt.What you end up with is more than notifications
wearing a new coat of paint. You get cards that act as true
interactive panels—always personalized, actionable, and hooked
into live business context. Your Teams experience grows into
something that serves different needs automatically: approvals,
feedback, updates, and tasks—all formatted and filtered so users
only see what matters to them. Once you see what’s possible, the
last question is how to keep experimenting—pushing your cards
further, validating new interactive ideas, and using Adaptive
Cards to actually drive change across your Teams environment.


If you've ever posted a Teams update and wondered if anyone even
saw it, Adaptive Cards offer a better way. They move beyond
posters—becoming real tools for input, approvals, and personal
feedback. Once you start layering buttons, logic, and data
bindings, Teams can finally match the workflows you build outside
meetings. It’s not about showing off a fancy card; it’s about
getting real responses, kicking off backend automation, and
serving useful context to each user. The more you experiment with
new card features, the closer Teams gets to feeling like a
workspace that adapts to your team.


Get full access to M365 Show - Microsoft 365 Digital Workplace
Daily at m365.show/subscribe