Your Teams notifications are dumb. Yeah, I said it. They spam reminders nobody reads, and they look like they were designed in 2003. Here’s the fix: we’re going to walk through three parts — structuring data in Microsoft Lists, designing an Adaptive Card, and wiring it together with Power Automate. Subscribe to the newsletter at m365 dot show if you want the full step‑by‑step checklist.

Once you connect those pieces, the boring alerts turn into slick, clickable mini‑apps in Teams. By the end, you’ll build a simple task card — approve or snooze — without users ever leaving chat.

Sounds good, but first let’s look at why the default Teams notifications are so useless in the first place.

Why Teams Notifications Fail

Ever notice how quick we are to hit “mark as read” on a Teams alert without even glancing at it? Happens all the time. The dirty truth is that most notifications aren’t worth the click — they aren’t asking you to actually *do* anything. They just pile up, little blocks of static text that technically “alert” you, but don’t invite action. Teams was supposed to make collaboration easier, yet those alerts work more like an old-school overhead PA system: loud, one-way, and usually ignored.

Here’s the play-by-play. Somebody sets up a flow — say, an approval request or a reminder to check a task. Teams sends out the ping. But that ping is empty. It’s just words in a box with zero interactivity. The recipient shrugs, clears it, and forgets about it. Meanwhile, that request sits untouched, waiting like an abandoned ticket in the queue. Multiply that by dozens of alerts a week, and congratulations — you’ve built digital background noise on par with standing between a jackhammer and a jet engine.

The fallout shows up fast. A manager needs an approval, but the request is sitting in limbo, so they end up chasing the person in chat: “Hey, did you see that?” That message promptly gets buried under noise about lunch-and-learns, upcoming surveys, or the outage notice no one can action anyway. Before long, muscle memory takes over: swipe, snooze, dismiss. The result isn’t that Teams is broken; the problem is that the notifications running through it were never meant for interaction.

Think of the current system like a fax machine in 2024. Yes, the paper comes out the other side, and technically the information transferred. But nobody brags about using it. Same with Teams alerts: technically functional, but painfully outdated. The real “work” still spills into other channels — endless email trails, chat chasers, and manual spreadsheets. Teams becomes a hallway covered in digital flyers that everyone walks past.

From what we’ve seen across real deployments and support cases, notifications that aren’t actionable get ignored. In practice, when users get hammered with these static “FYI” pings, response rates drop hard — we keep seeing the same pattern across tenants: the more hollow the alerts, the less anyone bothers to act on them. And with that, productivity craters. Missed approvals, overdue tasks, broken handoffs — it all snowballs into “sorry, I didn’t see that” excuses, and the cycle repeats.

Time is where it really hurts. Every useless ping spawns follow-up emails, escalations, manual tracking, and a dozen extra steps that never needed to exist. Teams channels fill with bot posts nobody reads, and actual high-priority alerts sink unseen. The fastest way to torpedo user engagement with your processes is to keep flooding people with alerts that don’t let them resolve anything in place.

One client story hammered this home. They had a Purchase Order approval process wired into Teams, but the messages were generic blurbs with a bland “view request” link. Clicking took you to a site with no context, no instructions, just a blank box waiting for input. One approval ended up sitting untouched for three weeks, holding up procurement until the vendor finally walked away. The lesson was obvious: context and action have to be built into the notification itself, or it fails completely.

The real kicker is that none of this pain is needed. Notifications don’t have to be treated like paper slips shoved under a digital door. They can ask for action directly. They can carry buttons, fields, and context so users can respond instantly. That’s exactly where Adaptive Cards shift the game. Instead of shouting information and hoping someone reacts, the card itself says: here’s the choice, click it now. FYIs turn into “done with one click.”

Bottom line: Teams notifications fail because they’re static. They dump context-free information and leave the user to go hunting elsewhere. Adaptive Cards succeed because they remove that hunting trip. They bring the needed action — approve, update, close — right into the chat window. That’s the difference between annoying noise and useful workflow.

So the big question is, how do you make those cards actually work the way you want? The trick is that smart cards rely on smart data. If your underlying data is messy or unstructured, the cards will feel just as clunky as the static alerts. Next, we’ll dig into the tool most folks underestimate but is actually the foundation of the whole setup: Microsoft Lists. Want a heads-up when each part drops? Subscribe at m365 dot show so you don’t miss it.

The Secret Weapon: Microsoft Lists

So let’s talk about the real foundation of this whole setup: Microsoft Lists. Most folks glance at it and say, “Oh great, another Excel wannabe living in SharePoint.” Then they dump random notes in it, half-fill columns, and call it a day. But here’s the twist — Lists isn’t the sidekick. It’s the engine that makes your Adaptive Cards actually work. If the source data is junk, your cards will be junk. Simple as that.

Adaptive Cards, no matter how sharp they look, are only as useful as the data behind them. If your List is full of inconsistent text, blank fields, and random guesses, the card becomes nonsense. Instead of a clear call to action, you’ve got reminders that confuse people and buttons tied to vague non-answers. That’s not a workflow — that’s digital wallpaper. Structured data is what makes these cards click. Without it, even the fanciest design falls flat.

The pain shows up fast. I’ve seen Lists where an “Owner” column was filled with nicknames, first names, and one that literally said “ask John.” Great, now your card pings the wrong person or nobody at all. Or status fields where one entry says “In Progress,” another says “IP,” and another just says “working-ish.” Try automating that — good luck. The card ends up pulling “Task maybe working-ish” onto a button, and users will either ignore it or laugh at it before ignoring it.

Here’s the cleaner way to think about it. Treat Microsoft Lists like your kitchen pantry. Adaptive Cards are just recipes pulling from those shelves. If the pantry is stocked with expired cans and mystery bags, your dinner’s ruined. But if everything’s labeled and consistent — flour, sugar, rice — the recipe comes out right. Same deal here. A clean List makes Adaptive Cards clear, actionable, and fast.

Let’s ground it in a practical example. Say you want a simple task tracker to drive reminders inside Teams. Make a List with four fields:

* TaskName (single line of text)

* DueDate (date)

* Owner (person)

* ReminderFlag (choice or yes/no)

That’s it. Four clean columns you can wire straight into a card. The card then shows the task, tells the owner when it’s due, and offers two buttons: “Mark Done” or “Snooze.” No guessing. No digging. Click, done. Now compare that to the same list where “Owner” just says “me,” “DueDate” is blank half the time, and “ReminderFlag” is written like “yes??” That card is confusing, and confusion kills engagement.

Column types aren’t window dressing either. They’re the difference between a working card and a dead one. Choice columns give you neat, predictable options that translate cleanly into card buttons. Date/time columns let you trigger exact reminder logic. Use People/Person columns so you can present owner info and, in Teams, humans can recognize the person at a glance — name, and often an avatar. That’s way more reliable than shoving in a random free-text field.

And here’s the pitfall I see again and again: the dreaded Notes column. One giant text blob that tries to capture everything. Don’t do it. Avoid dumping all your process into freeform notes. Use actual column types so the card can render clean, clickable elements instead of just spitting text.

Once you shift your mindset, it clicks. Lists aren’t passive storage. They’re the schema — the definition of what your workflow actually means. Every column sets a rule. Every field enforces structure. That structure feeds into the card design, which then feeds into Power Automate when you wire it together. Get the schema right, and you’re not building a “card.” You’re building a mini-app that looks clean and works exactly how people expect.

The bottom line is this: Microsoft Lists aren’t boring busywork. They’re the hidden layer that makes your notifications into something more than noise. Keep them structured, and your Adaptive Cards stop feeling like static spam and start feeling like tools people use.

Pantry stocked? Next we design the recipe — the Adaptive Card.

Designing Your First Adaptive Card

Designing your first Adaptive Card can feel like opening an IKEA box where the instructions show four screws but the bag has fifteen. In short: a little confusing, and you start to wonder if this thing will collapse the first time someone leans on it. That’s the point where most people stall. You open the editor, you’re staring at raw JSON and random options, and suddenly the excitement drains out. But here’s the fix: you don’t need to become the office carpenter. Microsoft actually gave us a tool that saves you from the misery.

It’s called the Adaptive Card Designer. Think of it as a no‑risk sandbox. You can drag elements around, test layouts, and preview exactly how they’ll look in Teams before you subject anyone else to the experiment. You can load sample data and check the design against real values, which spares you from the pain of fiddling directly with JSON like it’s some obscure side hobby. The Designer won’t build your process for you, but it gives you a safe way to get the card itself right.

Plenty of people still trip here, though. The temptation is to go overboard. They see all the shiny controls and think, “Great, time to impress.” Suddenly their card has six buttons, a dropdown, and text that reads like a policy handbook. And then nobody clicks it. I once saw a card with options like “Approve,” “Reject,” “Defer,” “Escalate,” “Assign,” and — I’m not making this up — “I don’t know.” Result? Everyone ignored it. Fewer choices always means more decisive clicks. If your card forces people to stop and parse ten options, you’ve already lost them.

Here’s a simple contrast. Draft one looks like SharePoint sneezed paragraphs onto the page: long blocks of text, one generic link, and zero context. Draft two shows the task name, the due date, the owner, plus one button: “Approve.” End of story. You don’t need a metric to guess which version got a response. The rule of thumb is short and sharp: design for decision. Ten words, show the owner, show the due date, and add one or two clean buttons. That’s it.

So what are the actual building blocks? Every card is made of three core pieces. First, TextBlocks — just labels and descriptions. They’re how you say “Task due Friday” or “Reimbursement request waiting.” Second, Inputs — these are the dropdowns and comment boxes. That’s where users can select an option or jot a note. Third, Action.Submit — basically the button. Click it and the card submits data into your flow. Easy to remember: Text for info, Input for choice, Submit for action. Just watch out for the naming: Action.Submit sends back property names exactly as you set them. Plan those names so they match what your Flow expects, or you’ll be debugging inputs that don’t line up.

And here’s the critical best practice: every element on your card should tie straight back to your List. Pull the task name from TaskName, map the due date from DueDate, push button choices into ApprovalStatus — everything connected. If you forget, the card becomes a cosmetic prop that looks fine but drives nothing. One practical tip: name your card fields to match List column names, or at least document the mapping before you wire the Flow. It saves hours of head‑scratching later when the card looks right but doesn’t update anything.

That’s really what separates “cool demo” cards from useful ones. A good card carries the exact context the user needs and nothing more. Think frictionless: they see it, parse it instantly, and make a decision in one click. No scrolling, no head‑scratching, no five‑button IRS forms.

But even if you get the design right in the Designer, remember — it’s still just a sketch taped to the wall. It doesn’t actually do anything until you move it into a live workflow. Before you get there, though, test smart. Use the Designer preview for Teams to see how it renders, then pilot with a small group so you can confirm the layout and mapping before unleashing it on the entire org. Nothing kills adoption faster than a broken card posted to hundreds of users at once.

That brings us to the next part of the challenge. A card by itself is static. To actually show up at the right time, to the right people, in the right Teams chat, you need something else handling the delivery. Without that, your perfect design is just a pretty picture stuck in a sandbox.

Power Automate: Wiring It All Together

Power Automate is where everything you’ve built actually starts moving. Think of it less as the flashy part of your project and more as the wiring hidden in the walls. Adaptive Cards may look polished, but without a flow behind them, they’re just decorative posters. Power Automate is the system that makes sure cards show up in Teams at the right time, for the right people.

The trick to making that work is timing. If cards arrive too often, you’ll get muted faster than the coworker who shares memes in the General channel. If they show up too rarely, users forget the process exists. Send them late — like after a deadline has already passed — and you’ve lost credibility entirely. At that point, your reminder feels like an auto-generated “your car warranty expired” email. The workflow is only as good as its timing.

That’s why you need to think carefully about triggers. Use the right trigger so the card lands at the right moment — not every possible moment. Common effective triggers are: item created, a due date approaching, or a specific column value changing. Those reflect real points when someone needs to see the card. They’re not the only triggers available, but they’re a safe place to start. And here’s the golden warning: **Don’t trigger on any change — you’ll spam users.** Someone fixing a stray typo should not light up everyone’s Teams feed.

Here’s the side-by-side. Lazy Flow: “When an item is modified” fires off every single time, no matter what changed. Add a comma? Boom — new card. Correct the spelling of “tomrrow”? Boom — another one. That ends in noise, teaches people to dismiss the alerts, and eventually they mute your flow altogether. Smarter Flow: send a card when a new record is created so owners know about it instantly, and maybe add another trigger for two days before a due date so nobody misses closing. Fewer signals, more relevance. One earns user trust; the other burns it.

Putting it together isn’t complicated once you stop overthinking. Step one: pick the trigger — normally “When an item is created or modified” with the right filters. Step two: swap in your JSON payload. The Adaptive Card Designer hands you the JSON template, and you simply replace placeholder text with List tokens. Step three: connect it to Teams using the “Post adaptive card in a chat or channel” action. That’s the basic loop: trigger, payload, post. Simple, predictable, and effective.

Now for one of the easiest ways to embarrass yourself in front of your team. You run the flow, the run history says “Succeeded,” you’re grinning at how smooth it looks… and no one sees a card in Teams. Why? Because you didn’t check the connector. Before testing, confirm your Teams connector is authenticated as an account with rights to post in the target channel or chat — otherwise the Flow reports success but nothing arrives. Save yourself the red face; it’s the automation equivalent of trying to print with no paper in the tray.

When you do it right, Power Automate is what makes Adaptive Cards real. It takes abstract designs and injects them into people’s workflow. You’ll know it works the first time a task owner clicks “Approve” in the chat feed without needing to open yet another app. That’s when this stops feeling like a neat experiment and actually starts saving time.

But don’t get cocky. The number one mistake is rolling out to everyone on day one. Flows that aren’t tested properly can flood people with duplicates or send nonsense at scale. Test with a pilot user and include de-duplication or guard checks to avoid duplicate sends — that’s how you avoid being the admin who turned Teams into a junk mail machine.

So here’s a mini checklist before you move on:

First: Pick a smart trigger that reflects when action is needed. Secound: Replace the sample JSON with your List column tokens.

Last: Test your connections and run a pilot group before rollout.

If those three pieces line up, you’re no longer in the “neat demo” phase. You’ve got working notifications flowing through Teams. The next challenge, and it’s a bigger one, is making sure people actually take action when they see those cards. That’s where a lot of these projects stumble.

Making People Actually Click

Here’s the dirty little secret about Adaptive Cards: building one doesn’t guarantee people will actually click it. You can polish the JSON, map every field, and make the thing look like a glossy demo, but it still risks being ignored like every other Teams ping. This isn’t a technology gap — it’s a people gap. Users drown in alerts already. If your card feels like just another static FYI, it goes straight into digital trash without a thought. The goal isn’t just delivery — it’s action.

From deployments we’ve seen, passive cards become optional in people’s workflow. And “optional” in an office context basically translates to “never.” If nothing about the card communicates urgency or a clear next step, it gets dismissed. The ones that actually work are lean, sharp, and actionable. They show the user why it matters now, what decision is needed, and how quickly it can be resolved. Miss any of those three ingredients, and that card might as well have stayed in the Designer.

There’s no shortage of cautionary tales. HR once tried using a card for vacation approvals. Sounds like a slam-dunk: manager sees the request, taps a button, done. Instead, they added a laundry list of options. By the time users finished scanning the choices, confusion set in and nobody acted. The process stalled until they gave up and went back to email. That’s a classic signal: if managers freeze, you put too many choices on the card. Keep it to one or two actions — max.

So here’s the rule. Approve or Decline. Snooze or Complete. Maybe slip in a “Remind Me Later” for the edge case. That’s it. Two buttons at most. The more options you shove in, the less likely anyone moves forward. The card should feel almost effortless, like closing a pop-up. Except instead of dismissing it, the user advances the workflow. Simple equals clicks.

Context is the other part most admins overlook. A neat-looking card without proper context is functionally useless. Add the due date right on the card so users know if it’s urgent. Show who owns the task so it feels personal. And if possible, display the current task status so nobody assumes someone else already handled it. These details look cosmetic, but they decide whether a person clicks or swipes the card away. In our experience, the three pieces people scan first — deadline, name, and status — are the difference between acted-on and ignored.

Here’s the painful blunder: an approval card with no due date. To the user, that reads as “do this whenever.” And “whenever” silently converts to “not today.” Soon, managers are chasing approvals over chat, spamming reminders, and accidentally recreating the very noise you were trying to solve. You didn’t automate productivity — you automated nagging.

The best cards avoid this entirely by being frictionless. They present one clean action with immediate payoff. No extra clicks, no redirecting to another app, no ten-step chase. The workflow literally happens in the same Teams message that announced the task. That speed turns cynicism into adoption — because users realize the fastest way to be done is to just click the option in front of them.

Here’s a repeatable gut check to stop overcomplicating things: the Three-Second Test. Show your card to someone who hasn’t seen it before. If they can’t tell what to do in under three seconds, simplify it. Cut words, reduce buttons, add clarity. That rubric saves you from pushing out guesswork disguised as automation. It’s simple, repeatable, and brutal enough to keep your designs honest.

At the end of the day, Adaptive Cards aren’t made for admin brag slides or tech demos. They’re staff helpers baked directly into Teams. Build them right, and they make work faster with almost no thought from the user. Build them wrong, and they’re just another ignored notification your org learns to mute. Great design plus clean Lists plus smart triggers = adopted workflows.

And that’s what this whole system builds toward: Teams not as a noisy alerts feed, but as a workspace where actual work moves forward inside the message itself.

Conclusion

So here’s where we land: the tech is nice, but the win comes from execution. Three steps — no magic. One: structure your List with clean columns. Two: design a minimal card with only the context and buttons that matter. Three: wire it into a smart Flow and pilot it before you unleash it on the entire tenant. Do that, and the system works. Skip it, and you’re just automating noise.

Once you’ve nailed the basics, you can layer in extras. Augmenting cards with AI to surface smarter suggestions is possible — but only after the foundations don’t wobble.

Subscribe to the newsletter at m365 dot show and follow M365.Show for MVP livestreams. Because nothing says “fun” like learning from other people’s Flow disasters instead of causing your own.

This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit m365.show/subscribe