Fabric Governance Is Not What You Expect

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 Guard


If 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
Fabric


If 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 action isn’t recognized by both systems. It’s not always
intuitive, and those gaps are where compliance headaches
start.Microsoft’s approach wasn’t to copy-paste M365’s toolkit
into Fabric. According to Fabric documentation and blogs from
early adopters, governance here is “designed to echo M365
patterns but relies on data mesh concepts layered on top.” That
means Fabric emphasizes decentralized data ownership,
context-driven access, and object-centric controls more than the
container-based approach you’re used to. The idea is that each
domain—like Finance, HR, or Sales—can set its own rules, and
those rules integrate with, but don’t necessarily depend on,
central M365 settings. It’s modular, but also means you need to
develop new habits.So, where does your M365 experience actually
help? If you understand sensitivity labels, you know why marking
assets matters. If you’ve run audit searches, you already know
what evidence stakeholders will ask for. But the trick is
watching for the “almost but not quite” moments. Fabric’s
terminology is familiar, but the execution changes around context
and granularity. Leverage your M365 toolkit—but take time for a
Fabric walkthrough before you trust your instincts.The bottom
line is this: if you’ve locked down your SharePoint or finessed
DLP in Exchange, you’re off to a solid start. Just be ready for a
few sharp turns—some routines carry across, others just look
familiar until you try them in practice. These familiar tools
give you a running start, but the real test is adapting your
approach for Fabric’s quirks. And that becomes even more obvious
when you take a closer look at access, which bends the rules in
its own way.


Access Control: Where Fabric Borrows (and Breaks) from SharePoint
and Teams


If you’ve set up access controls in SharePoint or Teams, you know
how the system works—the comfort comes from years of patterns.
Give a group access at the top, and permissions drip down through
everything underneath. Inheritance makes life predictable. Even
with Teams, you adjust a team’s membership, and everyone slots
right into the permissions you expect, more or less. But Fabric
mixes things up. It gives you just enough of that familiar
structure to make you comfortable, then flips the details around.
Suddenly, you’re not dealing with just site collections and
groups. You’re dealing with workspaces, objects, and—here’s the
part that usually gets missed—data domains, all with their own
set of switches.The first place you notice things veering off
course is with inheritance. You might assign someone to a
workspace thinking, “They’re good—they have access to everything
in here.” In SharePoint, that works. In Fabric, you find out
there are layers underneath. Items inside that workspace, like
datasets or reports, might have their own explicit permissions.
That means even if a user has workspace access, they can still
get blocked at the object level, and vice versa. It’s like
granting access to a library, only for someone to get stopped at
a special archive room inside. This isn’t just a philosophical
difference; it’s practical. An admin could assign someone as a
workspace member, expecting them to see every dataset and item.
The reality? Without object-level permissions on specific
datasets, users run into a wall. Then come the tickets—“I can’t
see the data I need”—and everything bogs down.Here’s a situation
I’ve seen more than once. You get an urgent request from a
department. They’ve onboarded a new analyst and need them to
access sales dashboards, so you add them at the workspace level
for the Sales domain. When the analyst goes to open a core
dataset, though, they can’t. The dataset has been locked down at
the item level, maybe because an earlier admin decided it was
extra sensitive. In Teams or SharePoint, admins expect to trace
inheritance and fix it in one shot. In Fabric, you’re left
spelunking through nested permissions, trying to piece together
why membership up top doesn’t always mean access everywhere
below.And then you factor in domains. This isn’t just a new
word—Fabric’s data domains are a real twist. Instead of just
creating folders or libraries, you’re tasked with organizing
resources in ways that reflect how your business units actually
run. Domains bring a new flavor to access control, centered on
real-world organizational boundaries. A user might belong to
multiple domains; their access shifts depending on where they’re
working. It’s powerful but for admins coming from the old world
of blanket access, it’s extra complexity. Microsoft makes it
clear in their documentation: “Don’t assume your M365 permission
models will transfer—data mesh governance in Fabric must be
designed for each domain.” That means governance by context, not
template.Let’s not forget roles. The labels sound familiar—Admin,
Member, Contributor—but the impact isn’t always one-to-one with
what you’ve seen in Teams or SharePoint. One workspace might
treat Members as pure editors, while another might have layered
restrictions where Members still get blocked on high-value
datasets. Contributors often discover they can load objects but
can’t always publish or see all datasets, depending on how
granular things are set. Without careful planning, users can wind
up with either too much power or stuck on the outside looking in,
even though they’re “in the group.” And if you think audit logs
will save you, remember: in Fabric, tracking permission changes
and access history can feel less unified than what you get with
the M365 compliance dashboard.Now, let’s talk about the reality
of all these controls mashed together. On one hand, it’s
flexible—if you want fine-grained access down to the file or
dataset, you can do it. But it’s also easy to over-permission,
especially when you’re juggling workspaces, roles, and domain
rules. Accidental exposure creeps in through little gaps—a user
added in a hurry or a dataset that slipped through because you
missed the object-level override. Even the best admins can forget
to check those corners, especially when their brain’s still wired
for the M365 group model. Instead of a single source of truth,
you’re working with an overlapping set of permissions, any one of
which can open a door you thought was locked.Microsoft’s best
practices make it blunt: assuming old models will just click into
place is what gets most teams into trouble. Data mesh governance
isn’t just marketing jargon. It forces you to put access rules
where they belong—at the domain, workspace, and object. That
means more power to tune controls for each use case but a bigger
cognitive load, too. The result? Unless you get hands-on and
actively track how roles interact with domains, you risk missing
out on critical audit signals. If a permission slips, it may not
be flagged in your usual compliance tools, and that’s when issues
turn into actual breaches.The encouraging part is that your
background in M365 group-based access still matters. The
instincts around “least privilege,” or careful delegation, give
you a foundation to work from. But that approach only gets you as
far as Fabric’s own multi-layered permissions allow. You pick up
the rest by diving into the specifics of how Fabric structures
access—by mixing workspace roles, object overrides, and domain
context.That’s just one side of governance. Setting access
controls well is critical, but compliance and auditing feel
different as soon as you cross into Fabric’s reporting and
oversight tools. That shift brings its own unique surprises.


Audit, Lineage, and Compliance: The Hidden Differences That Trip
Up Pros


If you’ve spent time in the M365 compliance center, you probably
feel at home picking through audit logs and tracking data
lineage. It’s familiar territory—open up a dashboard, punch in a
few filters, and watch the story unfold: who touched what, when
it happened, and where files traveled. With Fabric, though, those
instincts don’t get you as far as you’d expect. The tools might
echo what you know from M365, but the details force you to work a
little harder, and the price of missing something is higher.Most
admins don’t see the catch until the first time there’s a real
incident. Let’s say you catch wind that a sensitive report—maybe
quarterly financials—was shared externally. In the classic M365
world, you’d hit the compliance center, run an audit search, and
usually come away with a clear sequence of events. In Fabric, you
might start in the same place, but you soon realize you’re
working with a blend of audit endpoints. Some activities log
inside M365, while others live exclusively in Fabric’s own audit
pane. Tracking the flow of a report through different workspaces,
then figuring out where lineage diverges from the audit trail,
creates a scavenger hunt. It’s not just a new UI to learn; it’s a
new process that asks you to jump between tools, and—here’s the
kicker—sometimes key evidence lives only in one system or the
other.Picture what happens to a compliance officer who needs to
reconstruct the journey of a sensitive dataset. They’re used to a
unified dashboard, so at first, they don’t notice that Fabric’s
objects bring their own breed of lineage tracking—one that
doesn’t always tie back to the broader M365 audit logs. They get
halfway through the investigation, only to discover there are
gaps: certain transformations, dataflows, or even Power BI report
exports log actions in Fabric but never surface in M365. The
officer chases leads, clicks through every available drill-down,
and ends up with a screenshot mosaic instead of an integrated
report.The good news? Fabric actually raises the bar for data
lineage visuals. Once you get past the vocabulary—terms like
“artifact,” “upstream,” and “downstream flows”—you realize you
can follow data through every touchpoint. Instead of simply
seeing that a file changed hands, you get to graph the
step-by-step transformation of a dataset from source, through ETL
jobs, to the dashboards that surface insights. That’s more
granularity than what most M365 admins are used to. But it comes
at the cost of needing to decode new visualizations, and the path
is less about following a breadcrumb trail and more about mapping
a subway system. If you’ve ever stared at a Fabric lineage
diagram for the first time, you know the feeling: the scope is
impressive, but you have to retrain your eye to spot where access
splintered or where sensitive data took a side track.Integration
with the M365 Compliance Center helps, but it doesn’t fill every
hole. You’ll find that certain Fabric compliance events—say,
dataset sharing, pipeline runs, or workspace role changes—make it
into M365 audit feeds, while others, including lineage changes
and object-level access adjustments, only live inside Fabric’s
portal. It’s easy to assume, “if it’s important, it must show up
everywhere.” But that assumption trips up a lot of skilled
people. Early adopters keep running into cases where the audit
logs in M365 look clean, but Fabric’s native tools reveal missed
events. Microsoft calls it a “hybrid” model, which sounds neat
until you’re scrambling for answers and realize you checked one
dashboard, not both.Best practices here aren’t obvious—most
admins start by mirroring their old compliance routines, only to
realize that Fabric’s controls need dedicated setup. If you want
solid oversight, you have to activate detailed audit logging
inside Fabric itself, configure retention policies, and actually
review those logs on Fabric’s terms. Just setting it and
forgetting it in M365 won’t protect you from hidden exposures.
It’s worth running real investigations as tests. Try following a
report’s full journey, from the first ingestion in a dataflow,
through transformations, and all the way to the published
dashboard. Watch for steps that silently break the audit trail,
and document which logs live where—that map will save you during
real incidents.Another tip: get familiar with Fabric’s
terminology and mapping features early on. Data lineage diagrams
are useful, but their power comes only if you know how to connect
what you see with questions you’re being asked—about data
sharing, regulatory compliance, or even simple troubleshooting.
Don’t be shy about creating reference guides for your team or
setting up shortcuts to commonly checked audit points. The more
ground you cover ahead of time, the better you limit your
exposure to missed signals.Here’s the real takeaway—M365
compliance comfort isn’t a risk on its own, but over-relying on
it can give you a false sense of security in Fabric. The stakes
are bigger, not because the tools are worse, but because
unfamiliar layers make easy things easy to miss. Staying both
thorough and flexible is how the best admins avoid getting
blindsided. Now that we’ve flagged these hidden differences, it’s
worth asking: what does all this actually mean for admins looking
to make the most out of Fabric’s governance—beyond just staying
out of trouble?


Conclusion


If you’ve been treating Fabric like it’s just M365 with new
branding, the cracks show fast. The controls shift, the language
changes, and your familiar playbooks need tweaking. It’s not
about abandoning what you know—it’s about pushing your comfort
zone and looking for the detail hiding behind “familiar” menus.
The admins who adapt, who stay curious about each domain and
audit nuance, are the ones shaping standards in this space. Don’t
coast on past habits—question everything, share your discoveries,
and keep engaging. There’s always a next quirk, a smarter
workaround, or a sharper question right around the corner.


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