Episodes

  • How Data Goblins Wreck Copilot For Everyone

    How Data Goblins Wreck Copilot For Everyone
    Sep 23 2025
    Picture your data as a swarm of goblins: messy, multiplying in the dark, and definitely not helping you win over users. Drop Copilot into that chaos and you don’t get magic productivity—you get it spitting out outdated contract summaries and random nonsense your boss thinks came from 2017. Not exactly confidence-inspiring. Here’s the fix: tame those goblins with the right prep and rollout, and Copilot finally acts like the assistant people actually want. I’ll give you the Top 10 actions to make Copilot useful, not theory—stuff you can run this week. Quick plug: grab the free checklist at m365.show so you don’t miss a step. Because the real nightmare isn’t day two of Copilot. It’s when your rollout fails before anyone even touches it.Why Deployments Fail Before Day OneToo many Copilot rollouts sputter out before users ever give it a fair shot. And it’s rarely because Microsoft slipped some bad code into your tenant or you missed a magic license toggle. The real problem is expectation—people walk in thinking Copilot is a switch you flip and suddenly thirty versions of a budget file merge into one perfect answer. That’s the dream. Reality is more like trying to fuel an Olympic runner with cheeseburgers: instead of medals, you just get cramps and regret. The issue comes down to data. Copilot doesn’t invent knowledge; it chews on whatever records you feed it. If your tenant is a mess of untagged files, duplicate spreadsheets, and abandoned SharePoint folders, you’ve basically laid out a dumpster buffet. One company I worked with thought their contract library was “clean.” In practice, some contracts were expired, others mislabeled, and half were just old drafts stuck in “final” folders. The result? Copilot spat out a summary confidently claiming a partnership from 2019 was still active. Legal freaked out. Leadership panicked. And trust in Copilot nosedived almost instantly. That kind of fiasco isn’t on the AI—it’s on the inputs. Copilot did exactly what it was told: turn garbage into polished garbage. The dangerous part is how convincing the output looks. Users hear the fluent summary and trust it, right up until they find a glaring contradiction. By then, the tool carries a new label: unreliable. And once that sticker’s applied, it’s hard to peel off. Experience and practitioner chatter all point to the same root problem: poor data governance kills AI projects before they even start. You can pay for licenses, bring in consultants, and run glossy kickoff meetings. None of it matters if the system underneath is mud. And here’s the kicker—users don’t care about roadmap PowerPoints or governance frameworks. If their very first Copilot query comes back wrong, they close the window and move on. From their perspective, the pitch is simple: “Here’s this fancy new assistant. Ask it anything.” So they try something basic like, “Show me open contracts with supplier X.” Copilot obliges—with outdated deals, missing clauses, and expired terms all mixed in. Ask yourself—would they click a second time after that? Probably not. As soon as the office rumor mill brands it “just another gimmick,” adoption flatlines. So what’s the fix? Start small. Take that first anecdote: the messy contract library. If it sounds familiar, don’t set out to clean your entire estate. Instead, triage. Pick one folder you can fix in two days. Get labels consistent, dates current, drafts removed. Then connect Copilot to that small slice and run the same test. The difference is immediate—and more importantly, it rebuilds user confidence. Think of it like pest control. Every missing metadata field, every duplicate spreadsheet, every “Final_V7_REALLY.xlsx” is another goblin running loose in the basement. Leadership may be upstairs celebrating their shiny AI pilot, but downstairs those goblins are chewing wires and rearranging folders. Let Copilot loose down there, and you’ve just handed them megaphones. The takeaway is simple: bad data doesn’t blow up your deployment in one dramatic crash. It just sandpapers every interaction until user trust wears down completely. One bad answer becomes two. Then the whispers start: “It’s not accurate.” Soon nobody bothers to try it at all. So the hidden first step isn’t licensing or training—it’s hunting the goblins. Scrub a small set of records. Enforce some structure. Prove the tool works with clean inputs before scaling out. Skip that, and yes—your rollout fails before Day One. But there’s another side to this problem worth calling out. Even if the data is ready, users won’t lean in unless they actually *want* to. Which raises the harder question: why would someone ask for Copilot at all, instead of just ignoring it?How Organizations Got People to *Want* CopilotWhat flipped the script for some organizations was simple: they got people to *want* Copilot, not just tolerate it. And that’s rare in IT land. Normally,...
    Show More Show Less
    18 mins
  • GitHub, Azure DevOps, or Fabric—Who’s Actually in Charge?

    GitHub, Azure DevOps, or Fabric—Who’s Actually in Charge?
    Sep 22 2025
    Here’s a statement that might sting: without CI/CD, your so‑called Medallion Architecture is nothing more than a very expensive CSV swamp. Subscribe to the M365.Show newsletter so you i can reach Gold Medallion on Substack!Now, the good news: we’re not here to leave you gasping in that swamp. We’ll show a practical, repeatable approach you can follow to keep Fabric Warehouse assets versioned, tested, and promotable without midnight firefights. By the end, you’ll see how to treat data pipelines like code, not mystery scripts. And that starts with the first layer, where one bad load can wreck everything that follows.Bronze Without Rollback: Your CSV GraveyardPicture this: your Bronze layer takes in corrupted data. No red lights, no alarms, just several gigabytes of garbage neatly written into your landing zone. What do you do now? Without CI/CD to protect you, that corruption becomes permanent. Worse, every table downstream is slurping it up without realizing. That’s why Bronze so often turns into what I call the CSV graveyard. Teams think it’s just a dumping ground for raw data, but if you don’t have version control and rollback paths, what you’re really babysitting is a live minefield. People pitch Bronze as the safe space: drop in your JSON files, IoT logs, or mystery exports for later. Problem is, “safe” usually means “nobody touches it.” The files become sacred artifacts—raw, immutable, untouchable. Except they’re not. They’re garbage-prone. One connector starts spewing broken timestamps, or a schema sneaks in three extra columns. Maybe the feed includes headers some days and skips them on others. Weeks pass before anyone realizes half the nightly reports are ten percent wrong. And when the Bronze layer is poisoned, there’s no quick undo. Think about it: you can’t just Control+Z nine terabytes of corrupted ingestion. Bronze without CI/CD is like writing your dissertation in one single Word doc, no backups, no versions, and just praying you don’t hit crash-to-desktop. Spoiler alert: crash-to-desktop always comes. I’ve seen teams lose critical reporting periods that way—small connector tweaks going straight to production ingestion, no rollback, no audit trail. What follows is weeks of engineers reconstructing pipelines from scratch while leadership asks why financials suddenly don’t match reality. Not fun. Here’s the real fix: treat ingestion code like any other codebase. Bronze pipelines are not temporary throwaway scripts. They live longer than you think, and if they’re not branchable, reviewable, and version-controlled, they’ll eventually blow up. It’s the same principle as duct taping your car bumper—you think it’s temporary until one day the bumper falls off in traffic. I once watched a retail team load a sea of duplicated rows into Bronze after an overnight connector failure. By the time they noticed, months of dashboards and lookups were poisoned. The rollback “process” was eight engineers manually rewriting ingestion logic while trying to reload weeks of data under pressure. That entire disaster could have been avoided if they had three simple guardrails. Step one: put ingestion code in Git with proper branching. Treat notebooks and configs like real deployable code. Step two: parameterize your connection strings and schema maps so you don’t hardwire production into every pipeline. Step three: lock deployments behind pipeline runs that validate syntax and schema before touching Bronze. That includes one small but vital test—run a pre-deploy schema check or a lightweight dry‑run ingestion. That catches mismatched timestamps or broken column headers before they break Bronze forever. Now replay that earlier horror story with these guardrails in place. Instead of panicking at three in the morning, you review last week’s commit, you roll back, redeploy, and everything stabilizes in minutes. That’s the difference between being crushed by Bronze chaos and running controlled, repeatable ingestion that you trust under deadline. The real lesson here? You never trust luck. You trust Git. Ingestion logic sits in version control, deployments run through CI/CD with schema checks, and rollback is built into the process. That way, when failure hits—and it always does—you’re not scrambling. You’re reverting. Big difference. Bronze suddenly feels less like Russian roulette and more like a controlled process that won’t keep you awake at night. Fixing Bronze is possible with discipline, but don’t take a victory lap yet. Because the next layer looks polished, structured, and safe—but it hides even nastier problems that most teams don’t catch until the damage is already done.Silver Layer: Where Governance Dies QuietlyAt first glance, Silver looks like the clean part of the Warehouse. Neat columns, standard formats, rows aligned like showroom furniture. But this is also where governance takes the biggest hit—because the mess ...
    Show More Show Less
    18 mins
  • Your Power Automate Approval Flow Isn’t Audit-Proof

    Your Power Automate Approval Flow Isn’t Audit-Proof
    Sep 22 2025
    Here’s the catch Microsoft doesn’t highlight: Power Automate’s run history is time‑limited by default. Retention depends on your plan and license, and it’s not forever. Once it rolls off, it’s gone—like it never ran. Great for Microsoft’s servers. Terrible for your audit trail. Designing without logging is like deleting your CCTV before the cops arrive. You might think you’re fine until someone actually needs the footage. Today we’ll show you how to log approvals permanently, restart flows from a stage, use dynamic approvers, and build sane escalations and reminders. Subscribe to the newsletter at m365 dot show if you want blunt fixes, not marketing decks. Because here’s the question you need to face—think your workflow trail is permanent? Spoiler: it disappears faster than free donuts in the break room.Why Your Flow History VanishesSo let’s get into why your flow history quietly disappears in the first place. You hit save on a flow, you check the run history tab, and you think, “Perfect. There’s my record. Problem solved.” Except that little log isn’t built to last. It’s more like a Post-it note on the office fridge—looks useful for a while, but it eventually drops into the recycling bin. Here’s the truth: Power Automate isn’t giving you a permanent archive. It’s giving you temporary storage designed with Microsoft’s servers in mind—not your compliance officer. How long your runs stay visible varies by plan and license. If you want the specifics, check your tenant settings or Microsoft’s own documentation. I’ll link the official retention guidance in the notes—verify your setup, because what you see depends entirely on your license. Most IT teams assume “cloud equals forever.” Microsoft assumes “forever equals a storage nightmare.” So they quietly clean house. That’s the built-in expectation: logs expire, data rolls off, and your history evaporates. They’re doing housekeeping. You’re the one left without receipts when auditors come calling. Let’s bring it into real life. Imagine HR asks for proof of a promotion approval from last year. Fourteen months ago, your director clicked Approve, everyone celebrated, and the process moved on. Fast forward, compliance wants records. You open Power Automate, dig into runs... and there’s nothing left. That tidy approval trail you trusted has already been vacuumed away. That’s not Microsoft failing to tell you. It’s right there in the docs—you just don’t see it unless you squint through the licensing fine print. They’re clear they’re not your compliance archive. That’s your job. And if you walk into an audit with holes in your data, the meeting isn’t going to be pleasant. Now picture this: it’s like Netflix wiping your watch history every Monday. One week you know exactly where you paused mid-season. Next week? Gone. The system pretends you never binged a single show. That’s how absurd it looks when an auditor asks for approval records and your run history tab is empty. The kicker is the consequences. Missing records isn’t just a mild inconvenience. Failing to show documentation can trigger compliance reviews and consequences that vary by regulation—and if you’re in a regulated industry, that can get expensive very quickly. And even if regulators aren’t involved, leadership will notice. You were trusted to automate approvals. If you can’t prove past approvals existed, congratulations—you’re now the weak link in the chain. And no, screenshots don’t save you. Screenshots are like photos of your dinner—you can show something happened, but you can’t prove it wasn’t staged. Auditors want structured data: dates, times, names, decisions. All the detail that screenshots can’t provide. And that doesn’t live in the temporary run history. Here’s a quick reality check you can do right now. Pause this video, go into Power Automate, click “My flows,” open run history on one of your flows, and look for the oldest available run. That’s your retention window. If it’s missing approvals you thought were permanent, you’ve already felt the problem firsthand. Want to know the one-click way to confirm exactly what your tenant holds? Stick around—I’ll show you in the checklist. So where does this leave you? Simple: if you don’t build logging into your workflows, you don’t have approval history at all. Pretending defaults are enough is like trusting a teenager when they say they cleaned their room—by Monday the mess will resurface, and nothing important will have survived. The key takeaway: Power Automate run history is a debugging aid, not a record keeper. It’s disposable by design, not permanent or audit-ready. If you want usable records, you have to create your own structured logs outside that temporary buffer. And this isn’t just about saving history. Weak logging means fragile workflows, and fragile workflows collapse the first time you push ...
    Show More Show Less
    20 mins
  • Why Leadership Thinks Copilot Is Useless (And Where the Numbers Back Them Up)

    Why Leadership Thinks Copilot Is Useless (And Where the Numbers Back Them Up)
    Sep 21 2025
    Here’s something spicy: most organizations think Copilot is underused… not because users hate it, but because no one’s checking the right dashboard. Subscribe at m365.show if you want the survival guide, not the PPT bingo. We’ll check which Copilot telemetry matters, where users actually click, and how prompts reveal who’s using it for real work. Often the signals you need live in a different pane—let’s show you where to look in your tenant. This isn’t a pep rally; it’s a reality check with the data points that count. And once you’ve seen that, we need to talk about the reports leadership is already waving in their hands.The CFO’s Report Doesn’t LieEver had that moment when the CFO barges in, waving a glossy admin report like it’s courtroom evidence, and asks why the company shelled out for a Copilot license nobody seems to use? Your stomach drops, because you’re not just defending an IT budget line—you’re defending your job. And here’s the kicker: the chart they’re holding isn’t wrong, but it’s not telling the story they think it is. The leadership bind is simple: licenses cost real money, so execs want hard proof that Copilot isn’t just another line item in the finance system. Microsoft does provide reports, but what those charts measure isn’t what most people assume. Log into the admin center and you’ll see nice graphs of sign-ins and “active users.” Sounds impressive until you realize it’s basically counting how many times someone opened Word, not whether they actually touched Copilot once they were in there. This is where the data trips people up. That report showing 2,000 Word sign-ins? Leadership reads that as 2,000 instances of Copilot lighting up productivity. Reality: it just means 2,000 people still have Word pinned to their taskbar and clicked it once. No one tells them that Copilot activity is captured in separate telemetry. So while the chart says “adoption,” in truth Copilot might be sitting unused like an expensive treadmill doubling as a coat rack. Now, to be fair, Entra AD does exactly what it promises. It focuses on identity and sign-in telemetry—it tells you who walked through the door and which app they technically opened. What it does not do, by default, is surface the action-level data that proves Copilot adoption. Put simply: it’ll show you that John launched Word, but it won’t show you that John asked Copilot to crank out a three-page summary to save himself an afternoon. Always check your tenant’s docs or Insights pane for what’s actually available, because the defaults don’t go that far. Here’s one clean metaphor you can safely use with leadership: those reports are counting swipes of a gym membership card. They don’t show whether anyone touched the treadmill, lifted weights, or just grabbed a chocolate bar from the vending machine. That one line paints the picture without drowning in analogies. So what do you say when finance is breathing down your neck with pretty graphs? Here’s the leadership-ready soundbite: “Sign-in counts show who opened the apps. Copilot adoption means showing who actually used prompts and actions. I can pull behavioral reports for that—if our tenant has telemetry enabled.” That’s a safe, honest line that doesn’t oversell anything but tells executives you can provide a real answer once you’ve got the right data enabled. And this is where your action item comes in. Don’t waste time trying to prove adoption from identity numbers. Instead, verify whether your tenant has Copilot Insights or usage reports that surface prompts and actions. If it does, prep a side-by-side demo for the CFO or CIO: slide one shows a bland graph of “sign-ins,” slide two shows actual prompts being used in Outlook, Word, or Teams. The contrast makes your point in about 30 seconds flat. Because at the end of the day, raw sign-in and license charts will always frame the wrong narrative. They’re a door count, not a usage log. What leadership really needs to see are the actions that prove value—the moments where Copilot shaved hours off real workflows, not just opened an application window. And that sets up the bigger story. Because Microsoft doesn’t give you just one way to see Copilot activity—they give you two different dashboards. One is the guard at the door. The other is the camera inside the building. And only one of them will tell you whether Copilot is actually changing how people work.Entra AD vs. Insights: The Tale of Two DashboardsMicrosoft gives you two main dashboards tied to Copilot adoption: Entra AD and Insights. At first glance they both look polished enough to screenshot into a slide deck, but they don’t measure the same thing. If you confuse them, you’ll end up telling execs a story that sounds great but falls apart the minute someone asks, “Okay, but did anyone actually use Copilot to get work done?” Here’s the split. Entra AD primarily records identity ...
    Show More Show Less
    18 mins
  • The Power BI Gateway Horror Story No One Warned You About

    The Power BI Gateway Horror Story No One Warned You About
    Sep 21 2025
    You know what’s horrifying? A gateway that works beautifully in your test tenant but collapses in production because one firewall rule was missed. That nightmare cost me a full weekend and two gallons of coffee. In this episode, I’m breaking down the real communication architecture of gateways and showing you how to actually bulletproof them. By the end, you’ll have a three‑point checklist and one architecture change that can save you from the caffeine‑fueled disaster I lived through. Subscribe at m365.show — we’ll even send you the troubleshooting checklist so your next rollout doesn’t implode just because the setup “looked simple.”The Setup Looked Simple… Until It Wasn’tSo here’s where things went sideways—the setup looked simple… until it wasn’t. On paper, installing a Power BI gateway feels like the sort of thing you could kick off before your first coffee and finish before lunch. Microsoft’s wizard makes it look like a “next, next, finish” job. In reality, it’s more like trying to defuse a bomb with instructions half-written in Klingon. The tool looks friendly, but in practice you’re handling something that can knock reporting offline for an entire company if you even sneeze on it wrong. That’s where this nightmare started. The plan itself sounded solid. One server dedicated to the gateway. Hook it up to our test tenant. Turn on a few connections. Run some validations. No heroics involved. In our case, the portal tests all reported back with green checks. Success messages popped up. Dashboards pulled data like nothing could go wrong. And for a very dangerous few hours, everything looked textbook-perfect. It gave us a false sense of security—the kind that makes you mutter, “Why does everyone complain about gateways? This is painless.” What changed in production? It’s not what you think—and that mystery cost us an entire weekend. The moment we switched over from test to production, the cracks formed fast. Dashboards that had been refreshing all morning suddenly threw up error banners. Critical reports—the kind you know executives open before their first meeting—failed right in front of them, with big red warnings instead of numbers. The emails started flooding in. First analysts, then managers, and by the time leadership was calling, it was obvious that the “easy” setup had betrayed us. The worst part? The documentation swore we had covered everything. Supported OS version? Check. Server patches? Done. Firewall rules as listed? In there twice. On paper it was compliant. In practice, nothing could stay connected for more than a few minutes. The whole thing felt like building an IKEA bookshelf according to the manual, only to watch it collapse the second you put weight on it. And the logs? Don’t get me started. Power BI’s logs are great if you like reading vague, fortune-cookie lines about “connection failures.” They tell you something is wrong, but not what, not where, and definitely not how to fix it. Every breadcrumb pointed toward the network stack. Naturally, we assumed a firewall problem. That made sense—gateways are chatty, they reach out in weird patterns, and one missing hole in the wall can choke them. So we did the admin thing: line-by-line firewall review. We crawled through every policy set, every rule. Nothing obvious stuck out. But the longer we stared at the logs, the more hopeless it felt. They’re the IT equivalent of being told “the universe is uncertain.” True, maybe. Helpful? Absolutely not. This is where self-doubt sets in. Did we botch a server config? Did Azure silently reject us because of some invisible service dependency tucked deep in Redmond’s documentation vault? And really—why do test tenants never act like production? How many of you have trusted a green checkmark in test, only to roll into production and feel the floor drop out from under you? Eventually, the awful truth sank in. Passing a connection test in the portal didn’t mean much. It meant only that the specific handshake *at that moment* worked. It wasn’t evidence the gateway was actually built for the real-world communication pattern. And that was the deal breaker: our production outage wasn’t caused by one tiny mistake. It collapsed because we hadn’t fully understood how the gateway talks across networks to begin with. That lesson hurts. What looked like success was a mirage. Test congratulated us. Production punched us in the face. It was never about one missed checkbox—it was about how traffic really flows once packets start leaving the server. And that’s the crucial point for anyone watching: the trap wasn’t the server, wasn’t the patch level, wasn’t even a bad line in a config file. It was the design. And this is where the story turns toward the network layer. Because when dashboards start choking, and the logs tell you nothing useful, your eyes naturally drift back to those firewall rules you thought were ...
    Show More Show Less
    19 mins
  • You're Probably Using Teams Channels Wrong

    You're Probably Using Teams Channels Wrong
    Sep 20 2025
    Let’s be real—Teams channels are just three kinds of roommates. Standard channels are the open-door living room. Private channels are the locked bedroom. Shared channels? That’s when your roommate’s cousin “stays for a few weeks” and suddenly your fridge looks like a crime scene. Here’s the value: by the end, you’ll know exactly which channel to pick for marketing, dev, and external vendors—without accidentally leaking secrets. We’ll get into the actual mechanics later, not just the surface-level labels. Quick pause—subscribe to the M365.Show newsletter at m365 dot show. Save yourself when the next Teams disaster hits. Because the real mess happens when you treat every channel the same—and that’s where we’re heading next.Why Picking the Wrong Channel Wrecks Your ProjectEver watched a project slip because the wrong kind of Teams channel got used? Confidential files dropped in front of the wrong people, interns scrolling through data they should never see, followed by that embarrassing “please delete that file” email that nobody deletes. It happens because too many folks treat the three channel types like carbon copies. They’re not, and one bad choice can sink a project before it’s out of planning mode. Quick story. A company handling a product launch threw marketing and dev into the same Standard channel. Marketing uploaded the glossy, client-ready files. Dev uploaded raw test builds and bug reports. End result: marketing interns who suddenly had access to unfinished code, and developers casually browsing embargoed press kits. Nobody meant to leak—Microsoft didn’t “glitch.” The leak happened because the structure guaranteed it. Here’s what’s going on under the hood. A Standard channel is tied to the parent Team. In practice, that means the files there behave like shared storage across the entire Team membership. No prompts, no “are you sure” moments—everyone in the Team sees it. That broad inheritance is great for open collaboration but dangerous if you only want part of the group to see certain content. (Editor note: verify against Microsoft Docs—if confirmed, simplify to plain English and cite. If not confirmed, reframe as observed admin behavior.) Think of that open spread as leaving your garage wide open. Nothing feels wrong until the neighbors start “borrowing” tools that were supposed to stay with you. Teams works the same way: what goes in a Standard channel gets shared broadly, like it or not. That’s why accidental data leaks feel less like bad luck and more like math. And here’s the real pain: once the wrong files land in the wrong channel, you’re stuck with cleanup. That means governance questions, compliance headaches, and scrambling to rebuild trust with the business. Worse—auditors love catching mistakes that could have been avoided if the right channel was set from the start. Choosing incorrectly doesn’t just create an access problem; it sets the wrong perimeter for every permission, audit log, and policy downstream. The takeaway? The channel type is not just a UI label. It’s your project’s security gate. Pick Standard and expect everyone in the Team to have visibility. Pick Private to pull a smaller group aside. Pick Shared if you’re bringing in external partners and don’t want to hand them the whole house key. You make the call once, and you deal with the consequences for the entire lifecycle. Here’s your quick fix if you’re running projects: decide the channel type during kickoff. Don’t leave it to “we’ll just create one later.” Lock down who can even create channels, so you don’t wake up six months in with a sprawl of random standards leaking files everywhere. That single governance move saves you from a lot of firefighting. So yes—wrong channel equals wrong audience, and wrong audience equals risk. Pretty UI aside, that’s how Teams behaves. Which raises the next big question: what actually separates these three flavors of channels, beyond the fluffy “collaboration space” jargon you keep hearing? That’s where we’re heading.Standard, Private, and Shared: Cutting the Marketing FluffMicrosoft’s marketing team loves to slap the phrase “collaboration space” on every channel type. Technically true, but about as helpful as calling your garage, your bedroom, and your driveway “living areas.” Sure, you can all meet in any of them, but eventually you’re wondering why your neighbor is folding laundry on your lawn. The reality is, Standard, Private, and Shared channels behave very differently. Treating them as identical is how files leak, audits fail, and admins lose sleep. So let’s cut the fluff. Think of channels less as “spaces” and more as three different security models wearing the same UI. They all show you a chat window, a files tab, and some app tabs. But underneath, the way data is stored and who sees it changes. Get those differences wrong, and you’re not running a ...
    Show More Show Less
    17 mins
  • Live Data in SPFx: Why Yours Isn’t Moving

    Live Data in SPFx: Why Yours Isn’t Moving
    Sep 20 2025
    Question for you: why does your SPFx web part look polished, but your users still ignore it? Because it’s not alive. They don’t care about a static list of names copied from last week—they want today’s data, updated the second they open Teams. In this video, we cover three wins you can actually ship: 1) connect SPFx to Graph and SharePoint securely, 2) make your calls faster with smaller payloads and caching, and 3) make updates real-time with webhooks and sockets. And good news—SPFx already has Graph and REST helpers baked in, so this isn’t an OAuth death march. Subscribe to the M365.Show newsletter at m365.show so you don’t miss these survival guides. Now, let’s take a closer look at why all that polish isn’t helping you yet.When Pretty Isn’t EnoughYou’ve put all the shine on your SPFx web part, but without live data it might as well be stuck behind glass. Sure, it loads, the CSS looks modern, the icons line up—but it’s no more useful than a lobby poster. Users figure it out in seconds: nothing moves, nothing changes, and that means nothing they can trust. The real issue isn’t looks—it’s trust. A dashboard is only valuable if it reflects reality. The moment it doesn’t, it stops being a tool and becomes a prop. Show users a “status board” that hasn’t updated in months, and you’ve trained them to stop checking it. Put yourself in their shoes: would you rely on metrics or contact info if you suspect it’s outdated? Probably not. That’s why static dashboards die fast, no matter how slick they appear. Here’s the simplest way to understand it: imagine a digital clock that’s frozen at 12:00. Technically, the screen works. The numbers display. But nobody uses it, because it’s lying the moment you look at it. In contrast, even a cheap wall clock with a ticking second hand feels alive and trustworthy. Our brains are wired to equate motion or freshness with reliability, which is exactly why your frozen SPFx display gets ignored. And the trap is deeper than just creating something irrelevant. When you polish a static web part, you actually amplify the problem. The nice gradients, the sleek tiles, the professional presentation—it broadcasts credibility. Users assume what they’re seeing is current. When they realize it’s six months old, that credibility collapses. Which hurts worse than if you had rolled out a plain text list. This isn’t just theory—it’s documented in Microsoft’s own SPFx case studies. One common failure pattern is the “team contacts” dashboard built as a static list. It looks helpful: one page, all the people in a group, with phones and emails. But if you’re not pulling straight from a live directory through Microsoft Graph or REST, those names go bad fast. Someone leaves, a role changes, numbers rotate—and suddenly the dashboard routes calls into a void. That’s not just dead data; it’s actively misleading. And as the research around SPFx examples confirms: people data always goes stale unless it’s pulled live. That one fact alone can sink adoption for otherwise solid projects. What makes it sting is how easy it is to avoid. SPFx already has the plumbing for exactly this: SharePoint REST endpoints, Microsoft Graph integration, and PnP libraries that wrap the messy parts. The pipes are there; you just have to open them up. Instead of your web part sitting frozen like a brochure, it can act like a real dashboard—a surface that reflects changes as they happen. That’s the difference between users glancing past it and users depending on it. And that’s really the message here: don’t waste your hours fiddling with padding values or button styling when the fix is turning on the live data feeds. SPFx wasn’t designed for static content any more than Outlook was designed for pen pals. Use the infrastructure it’s giving you. Because when the information is fresh—when it syncs to actual sources—the web part feels like something alive, not just another SharePoint decoration. Of course, the moment you start going live, you run face-first into the part everybody hates: authentication. And if you’ve ever tried to untangle OAuth token flows on your own, you already know it’s the programming version of reading an IKEA manual written in Klingon. So let’s hit that head-on and talk about how to stop authentication from killing your project.Beating Authentication HeadachesMost devs don’t throw in the towel on Microsoft Graph because fetch calls are tricky—it’s because authentication feels like surviving an IKEA manual written in Klingon. Every token, every consent screen, every obscure “scope” suddenly turns into diagrams that don’t line up with reality. By the time you think you’ve wired it all together, the thing wobbles if you so much as breathe on it. I’ve seen hardened engineers lose entire weekends just trying to pass a single Graph call through that security handshake. The problem isn’t Graph ...
    Show More Show Less
    20 mins
  • The Info Architect’s Guide to Surviving Purview

    The Info Architect’s Guide to Surviving Purview
    Sep 20 2025
    Here’s the disaster nobody tells new admins: one bad Purview retention setting can chew through your storage like Pac-Man on Red Bull. Subscribe to the M365.Show newsletter at m365 dot show so you don’t miss the next rename-ocalypse. We’ll cover what Purview actually does, the retention trap, the IA guardrails to prevent disaster, and a simple pilot plan you can run this month. Reversing a bad retention setting often takes time and admin effort — check Microsoft’s docs and always test in a pilot before trust-falling your tenant into production. The good news: with a solid information architecture, Purview isn’t the enemy. It can actually become one of your strongest tools. So, before we talk guardrails, let’s start with the obvious question — what even is Purview?What Even Is Purview?Microsoft has a habit of tossing out new product names like it’s a side hustle, and the latest one lighting up eye-roll meters is Purview. A lot of information architects hear the word, decide it sounds like an IT-only problem, and quietly step out of the conversation. That’s a mistake. Ignoring Purview is like ignoring the safety inspector while you’re still building the house. You might think nothing’s wrong yet, but eventually they show up with a clipboard, and suddenly that “dream home” doesn’t meet code. Purview functions as the compliance and governance layer that helps enforce retention, classification, and other lifecycle controls across Microsoft 365 — in practice it acts like your tenant’s compliance inspector. Let’s break Microsoft’s jargon into plain English. Purview is the set of tools Microsoft gives us for compliance and content governance across the tenant. Depending on licensing, it usually covers retention, classification, sensitivity labels, access control, eDiscovery, and data lifecycle. If it’s sitting inside Microsoft 365 — files, Outlook mailboxes, Teams chats, SharePoint sites, even meeting recordings — Purview commonly has a say in how long it sticks around, how it’s classified, and when it should disappear. You can picture it as the landlord with the clipboard. But here’s the catch: the rules it enforces depend heavily on the structure you’ve set up. If information architecture is sloppy, Purview enforces chaos. If IA is solid, Purview enforces order. This is where a lot of architects get tripped up. It’s tempting to think Purview is “IT turf” and not really part of your world. But Purview reaches directly into your content stores whether you like it or not. Retention policies don’t distinguish between a contract worth millions and a leftover lunch flyer. If you haven’t provided metadata and categorization, Purview treats them the same. And when that happens, your intranet stops feeling like a library and starts feeling like a haunted house — doors welded shut, content blocked off, users banging on IT’s door because “the file is broken.” And remember, Purview doesn’t view your content with the same care you do. It doesn’t naturally recognize your taxonomy until you encode it in ways the system can read. Purview’s strength is enforcement: compliance, retention, and risk reduction. It’s not here to applaud your architecture; it’s here to apply rules without nuance. Think of it like a city building regulator. They don’t care if your house has a brilliant design — they care if you left out the fire exit. And when your IA isn’t strong, the “fines” aren’t literal dollars, but wasted storage, broken workflows, and frustrated end users who can’t reach their data. That’s why the partnership between IA and Purview matters. Without metadata, content types, and logical structures in place, Purview defaults into overkill mode. Its scans feel like a spam filter set to “paranoid.” It keeps far too much, flags irrelevant content, and generates compliance reports dense enough to melt your brain. But when your IA work is dialed in, Purview has the roadmap it needs to act smarter. It can retain only sensitive or regulated information, sweep out junk, and keep collaboration running without adding friction. There’s another wrinkle here: Copilot. If your organization wants to roll it out, Purview instantly becomes non-negotiable. Copilot feeds from Microsoft Search. Search quality depends on your IA. And Purview layers governance on that same foundation. If the structure is weak, Copilot turns into a chaos machine, surfacing garbage or the wrong sensitive info. Purview, meanwhile, swings from being a precision scalpel to a blunt-force hammer. Translation: those shiny AI demos you promised the execs collapse when retention locks half of your data in digital amber. The real bottom line is this: Purview is not some bolt-on compliance toy for auditors. It’s built into the bones of your tenant. Pretending it’s someone else’s problem is like pretending you don’t need brakes because only other people drive the car. If ...
    Show More Show Less
    20 mins