If you've ever felt lost tracking down who accessed which dataset in Microsoft 365, get ready: Fabric governance might look familiar, but there are some surprises you need to see. Is your M365 compliance experience enough to tame this new platform—or are there catches nobody told you about?Stick around. I'm going to show you exactly where Fabric borrows from M365, and where it changes the rules—sometimes when you least expect it.Why Fabric Governance Catches Admins Off GuardIf you’re coming from Microsoft 365, it’s easy to assume Fabric will just slot in under your usual admin workflow. You launch the admin center and start poking around, expecting the settings menu to lead you where you need to go. That’s where Fabric throws its first curveball. The environment looks close enough to feel comfortable—at least on the surface. The icons line up, the workspaces have familiar names, and you will see labels that remind you of Teams or SharePoint. But try moving through the standard setup and your muscle memory instantly trips over the differences. Permissions aren’t hiding in their normal place, and when you do find them, the options read a little differently. That sense of “I’ve been here before” fades out as soon as you start looking for an old-school bridge, like a straightforward inheritance pattern or one-click audit configuration.Think about the admin who’s spent years fine-tuning access in SharePoint. They walk into Fabric with a certain confidence—menus in Microsoft should follow a type of logic, right? The expectation is: all those tricks for handling nested permissions, inheritance, even the group-based controls for managing access, should translate. But Fabric breaks from that rhythm. You’re looking for a way to adjust permissions on a library or a list, but Fabric wants you thinking about domains, workspaces, and specific items instead. Instead of a predictable stack of settings, you get overlapping pages, new terminology, and extra layers that don’t quite line up with what you’d expect. Even the simple act of assigning a role comes with extra caveats about what “Admin,” “Contributor,” or “Member” really means for a workspace versus a data item.That’s where the friction starts. The marketing for Fabric sold it as an extension of what you already know, so you start by running your go-to playbook. You copy over your M365 permission structures, thinking, “that should cover us.” And right away, the cracks appear. Simple questions—like “if I label this dataset as Confidential, will it actually limit who can export or share it?”—aren’t answered where you’d expect. Suddenly, you’re off to the documentation. And it isn’t just you. We’ve all seen admins—seasoned ones—getting stumped by why their access controls don’t stick or why their compliance monitor isn’t catching everything.There’s definitely a learning curve. The language is similar enough to lure you into old habits, but key words have shifted. Menus overlap so you’re jumping between multiple screens trying to figure out which setting overrides the other. And some controls are split between the Fabric portal and the broader M365 admin center, or worse, they look joined but behave differently behind the scenes. You get this odd mashup—like déjà vu, but with enough details out of place to slow you down at every step. It isn’t just an annoyance for people who like things tidy; it means mistakes slip through the cracks. Auditing isn’t as obvious. Permission inheritance doesn’t always kick in. Meanwhile, you’re getting pinged by the business when someone accidentally lets an unauthorized user peek at a sensitive dataset.Speaking of that, here’s the kind of scenario that happens more often than folks like to admit: a business analyst goes to share a dataset they’ve marked as “internal.” In M365, their previous experience taught them that sensitivity labels would cascade, restricting sharing outside the company. So they assume Fabric is doing the same thing in the background. Except it’s not. The permissions surface works differently, so their internal-only data gets exposed to a partner by mistake—because the settings didn’t propagate like they expected. Suddenly, you’ve got questions about who can see what, and the audit logs aren’t showing what you thought they’d show.A big reason for all this, according to recent research from Microsoft’s own Fabric documentation and early adopter surveys, is the introduction of data domains. In M365, most permissions revolve around the app or the container—like a SharePoint site or a Teams channel. With Fabric, the data domain model asks you to organize by logical business areas. It sounds simple enough, but it upends where you set controls and who’s responsible for governance. Instead of a one-size-fits-all approach, Fabric spreads out ownership and makes you think carefully about the context in which data lives and moves. Many admins miss this shift at first, especially if they’re used to painting with broad permission strokes, rather than managing at a granular, domain-specific level.So if you’re finding yourself frustrated, or even second-guessing that intuition built up from years in the M365 world, you’re not alone. Fabric governance isn’t just a facelift on top of your usual compliance tools. It’s a new model—one that rewards those who take time to learn how data domains, workspace roles, and new audit points fit together. In the end, even M365 veterans need to plan for a different kind of map.But it’s not like you’re starting from scratch. While some of the landscape has changed, a core set of concepts still carry over. The trick, now, is figuring out what’s familiar, and how to translate that comfort level into these new rules. That’s where things start to get interesting.Blueprints and Mirrors: Translating M365 Compliance Tools to FabricIf you’ve ever wrestled with sensitivity labels in the M365 Compliance Center, you’ve probably noticed the promise: set a few policies, apply some labels, and you’ve got audit-ready confidence, right? So, stepping into Fabric, it’s perfectly natural to assume those same rules and shortcuts carry across. Let’s see how that expectation holds up inside Fabric’s walls. Sensitivity labels, DLP (Data Loss Prevention) policies, audit trails—those are staples of M365 governance. You might already have your go-to process for tagging a confidential file, knowing it’ll follow users even if it leaves your tenant. Or maybe you’ve relied on audit dashboards to flag a suspicious download. It’s a comfortable routine. In Fabric, you’ll find these terms and tools, but if you’re waiting for a one-to-one translation, you’re in for a surprise.Start with sensitivity labels. In the M365 universe, these labels tend to behave like digital wrappers, sticking to a document as it moves around the cloud or shows up in emails. The enforcement is predictable. But say you try to apply that same label in Fabric, maybe to a Power BI dataset. It seems straightforward, but the propagation is where things start to split. In M365, label a document “Confidential” and its access controls travel with it—easy. In Fabric, you label your asset, and suddenly you’re asking: why isn’t that restriction showing up for analytics users, or when the data is copied elsewhere? It’s because the label attaches at the object level but doesn’t always enforce downstream, especially if the data is transformed or exported. That disconnect catches people off guard.DLP policies—another favorite tool you probably rely on in Exchange or SharePoint—work in Fabric, but with important differences. In M365, DLP policies are the safety net: block an export, get an alert, maybe even run a forced encryption action. With Fabric, the framework exists, but coverage can feel inconsistent. Now, instead of one policy engine watching everything, you find DLP settings tucked inside the Fabric admin panels, and sometimes in overlapping M365 areas. The tricky part is, certain assets—say, Data Warehouses or Pipelines—don’t always respect the same DLP triggers as a simple file stored in OneDrive. You need to read the fine print and test coverage, or you could end up with data slipping past your normal controls.Now, let’s talk audit logs. Auditability is where seasoned admins either relax—or tense up. In M365, the compliance center is your reconnaissance base. Everything shows up in the Unified Audit log, from file opens in SharePoint to message edits in Teams. You search, filter, export—no drama. Fabric offers audit logging, too, but you’ll quickly notice these logs sometimes live in their own corners. Some actions get piped into the M365 center, but others only exist in Fabric’s own dashboards. For example, certain analytics queries, report views, or pipeline runs in Fabric create audit events you won’t see in your classic compliance searches. If you’re investigating a breach or simply validating compliance, knowing where to look—and what’s missing—really matters.Here’s a tangible scenario: you apply a sensitivity label to a Power BI dataset inside Fabric, just like you would for a confidential document in SharePoint. The expectation is that anyone trying to share, export, or copy that data will hit a permission wall. In reality, while the dataset might show its label, actual restrictions can be hit-or-miss. A report built on that data might not inherit the label, or external connections could bypass those settings if you’re not diligent. This patchwork effect means your risk of accidental exposure goes up unless you double-check every layer.With audit logs, the differences might make you nostalgic for good old Unified Audit. Suppose you’re asked to trace who changed a dataflow last Thursday. M365 would offer a robust filter and export tool. Fabric does have that search function, but quirky labeling and the placement of logs can slow you down. Sometimes, digging up that information means jumping between Fabric logs and M365 logs, with gaps appearing if the acti

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.