Implementing Row-Level Security in Power BI with Fabric

Ever wondered who can actually see your data in Power BI? Spoiler
alert—it’s not as private as you might think, unless you master
Row-Level Security. In this episode, we don’t just check the RLS
box. We break down the moving parts, from role definitions to the
DAX expressions that quietly decide who sees what. Most people
stop at setup—but we're going to show you how every decision
connects, so your data isn’t just locked—it’s architected for
security.


Why Row-Level Security Is a System, Not a Checkbox


If you’re used to locking down a sensitive spreadsheet by
slapping a password on it, you already know there’s a gap between
what you intend and what actually protects your data. Power BI
with Row-Level Security can feel exactly the same. You hit the
RLS toggle, assign a couple of roles, and think, “We’re covered.”
But the reality is different: sensitive data finds a way out when
those connections between roles, filters, and users aren’t
carefully mapped. People rarely talk about the times when someone
on the sales team opened up a dashboard and ended up with a clear
view into numbers they never should have seen. But it happens.
And it almost always starts with the assumption that RLS is just
one more box to check during setup.Let’s put you in the shoes of
someone who’s handed out dashboard access, thinking you’re just
empowering a colleague. Feels harmless, right? But in too many
organizations, access to one dashboard is access to everything
behind the scenes. I’ve seen environments where a single “global”
manager role accidentally allowed junior users to browse
confidential HR data, just because the naming didn’t match
reality. This isn’t a rare one-off, either—it’s closer to the
rule than the exception, especially when a company is growing and
dashboards are multiplying. Everyone wants to move fast, but when
you move without structure, tiny holes get left behind that can
turn into gaping gaps during an audit.On paper, RLS couldn’t
sound simpler. Build a role—maybe call it “Sales”—add a filter
like [Region] = ‘US’, and map users to it. But behind every
dropdown and checkbox in Power BI, there’s a system making
decisions about what data travels where. If you miss one
relationship, or a filter doesn’t capture a new data source, it
isn’t just a technical slip—it’s a security incident waiting to
happen. You won’t know until someone stumbles over data they
aren’t supposed to see—and sometimes, not even then. That’s what
makes these little misses so hard to catch: they don’t come with
warning bells, and standard audits often don’t drill deep enough
to notice them.What gets overlooked is how tightly connected RLS
components actually are. Most tutorials breeze through setup,
walking you through role creation and filter basics. They’ll
demonstrate mapping users and checking a preview box. But next to
nobody pauses to interrogate how a filter on the Sales table
affects, say, a related Territories table. Every bit of logic in
RLS ripples into the others—assignments, DAX expressions, and
even the naming of the roles themselves. Treat those choices as
isolated steps, and you’re trusting the system not to have any
loose ends. But one forgotten filter, and suddenly your careful
role setup is like a sieve. This is one of those areas where the
right analogy isn’t a locked door; it’s a mesh of threads. You
change one part, the whole thing can subtly shift. Miss a thread,
and you’ve created a leak that isn’t even obvious until it’s
exploited.Actual incidents show how this plays out. Insider
stories from analytics teams talk about the moment when the
European sales lead stumbled onto data from North America’s
pipeline. That wasn’t someone breaking in—it was a misapplied
filter, an unintentional default, or a role that nobody thought
to double-check. It’s not just real-world horror stories,
either—Microsoft’s own vulnerability reports list misconfigured
Row-Level Security as one of the top reasons for embarrassing,
public data exposure in large organizations. For every news
headline about a big breach, there are dozens that go unreported
but have lasting consequences behind the scenes.What ties these
problems together is the false sense of security RLS offers when
you treat it like a simple item to cross off a to-do list.
Studies from Microsoft’s security teams underscore that layering
filters—stacking them across tables, applying additional DAX
expressions, or using combinations of static and dynamic
logic—ramps up both protection and complexity. Each layer you add
doesn’t just make things safer. It multiplies the number of
points where a configuration mistake can occur. Instead of a
simple gatekeeper at the door, you’ve got a complex web where one
missed node can undermine months of security planning.Let’s not
glaze over the practical realities, either. A system might work
fine in test, but drag it into production with real users, real
departments, and ever-shifting teams, and you get situations
where someone who changed teams last quarter still has access to
the quarterly finance numbers. Names and assignments that made
sense early on turn into mysterious legacy artifacts nobody wants
to touch “just in case” they’re still being used. If you’re only
toggling RLS at setup and moving on, you’re not protecting your
data. You’re hoping nobody comes knocking at the wrong
door—whether through curiosity or mistake.All this leads to one
core truth: Row-Level Security is alive. It shifts with your
organization. Every role you build, every DAX filter you apply,
every group you assign—these aren’t small choices. They flow
together to create a living, breathing system of protection, or,
if ignored, a mesh full of holes. So before you move on to the
next dashboard or handoff a model, pause and ask: am I actually
managing a security system—or just hoping the switch is enough?
The next part of this story starts with the piece at the heart of
it all: the filter logic itself, and how it steers every other
decision you make.


Building a Secure Foundation: Data Filtering and Role Design


If you’ve ever set up Row-Level Security thinking it was just
about keeping certain rows out of view, you’re not alone. The
main reason RLS gets messy is one simple misunderstanding—this
isn’t just about what’s visible, it’s about shaping the entire
user experience. One quick misstep and suddenly, that
confidential bonus table or executive salary figure spills over
into someone’s dashboard. People discover these leaks when
reports are already in circulation, and by that point,
backtracking can get awkward. The uncomfortable part? These
breakdowns rarely look dramatic. It’s usually some edge case: a
US manager logs in and sees just what they’re supposed to, but a
London colleague opens the same model and, without anyone
realizing it, finds New York’s numbers sitting right there.Think
about kicking off a Fabric model for global sales. You want
managers in different regions to see only their own data. The
reflex is to drop in a filter, something simple: [Region] = "US"
or [Country] = "UK." But here’s the catch—how you write that
filter, and how you hook it into your model, decides whether your
system actually holds together or comes apart the minute things
get more complex. Plenty of folks assume it’s dead simple, a
one-line DAX filter, and then move on. But not all DAX behaves
the same way. In fact, those nuances often break things later,
especially when you move from Power BI Desktop over to Fabric,
where cloud-level quirks start to surface.RLS gets tangled pretty
quickly when you get into the weeds. People often bank on
functions like USERNAME() or USERPRINCIPALNAME(), guessing they
do the same thing or just grabbing whichever one a blog post
uses. But swap USERNAME()—which pulls your Windows name in
Desktop—for USERPRINCIPALNAME(), which grabs your email address
in Fabric, and suddenly your filter logic starts to wobble. If
you’ve ever had a test work in Desktop but collapse once you
publish to Fabric, this is probably why. And picking wrong?
That’s how gaps open up, quietly giving the wrong people a window
into data they should never touch.Let’s get specific. For basic
scenarios, a hardcoded check works: [Region] = "US" means only
rows where the region is US show up. That’s textbook static RLS.
It’s quick, it’s simple, and for fixed divisions—like a report
meant only for US managers—it gets the job done. But as soon as
someone asks for dynamic security, things shift. You might need
to determine access based not just on the report viewer, but on
relationships in another table—a user access table, for example,
listing which users see which regions. Now your RLS filter isn’t
just a fixed value; it’s a formula that looks up what regions
each person should access in real time.Here’s where DAX can trip
you up if you’re not careful. You might reach for something like
USERPRINCIPALNAME() and then try to join it to your access table.
But if your DAX relies on calculated columns or pulls in logic
that doesn’t respond to the user context at view time, you can
accidentally break the dynamic filter. Real-world example: a
company sets up a dynamic filter relying on a calculated column
in their fact table, only to realize later that calculated
columns are evaluated when data is loaded, not when it’s viewed.
This means users can’t see their personalized rows, or worse, see
too much. You don’t notice until a user pings you asking why a
report looks different for them than for someone else on the same
team.Microsoft’s documentation and a long parade of MVP blog
posts keep shouting from the rooftops: don’t trust calculated
columns with RLS. Calculated columns are locked at refresh—they
don’t change by user. For RLS to actually respond to the viewer,
your filter logic needs to be built as a DAX expression on tables
that update in the report context. Ignore this, and your
dashboards quietly betray you, showing the same rows no matter
who’s logged in.Static versus dynamic RLS isn’t just a technical
distinction; it’s about when and how data is filtered. Static RLS
is fast and rigid—great for when you know exactly which role
needs what data ahead of time. If you’re launching a report with
just a "Finance" or "Sales" group, this works. But go dynamic,
and every access decision happens on the fly, usually by matching
current user identity to an entry in a lookup table of
permissions. The flexibility is powerful, especially for big
organizations or multi-tenant deployments. But every step up in
flexibility adds complexity, and complexity always carries hidden
risk.Even advanced admins get tripped up believing filters are
always straightforward. The actual shape of your organization
changes constantly, and your DAX filters have to keep up. Many
break because they don’t realize how RLS logic gets applied—not
during data load, but every time a user interacts with a report.
Forget that, and you can accidentally open up or block off whole
sections of your data model without realizing it.The bottom line?
Get the foundation wrong, and nothing else you build with RLS
will matter. The way you write your DAX, the kind of filters you
use, and where you apply them—these pile together to shape your
real security posture. Skip the nuance, and you end up with a
setup that works in theory but leaks in practice. All this
happens before you even get to mapping users to roles, which
turns out to be the next place things quietly go sideways.


Mapping Roles to Users: The Assignment Trap


So, you’ve set up your roles, crafted the filters, and things
look tight on the model side. The next step—assigning
users—sounds like a no-brainer, but here’s where most Row-Level
Security plans quietly start to crack. This is the crossroads of
IT thinking: the technical logic is in place, but now you’re
betting that the human layer—your user and group
assignments—actually matches the reality of how your business
runs. It looks simple because there’s a “group” field and a list
of roles, but experience says this is where mistakes like to
hide.Picture this: you’ve created a “Manager” role, dropped your
carefully built filter onto it, and mapped the role in Power BI
or Fabric to an Azure AD group called “Managers.” You
double-check, maybe even get a second set of eyes on it, and roll
it out to the org. At first, it feels straightforward. That’s
kind of the problem—because group logic, especially in big
organizations, rarely stays simple for long. Teams shift.
Departments reorganize. Roles evolve. People leave one project,
join another. What happens if someone moves from sales to
operations and no one prunes the old group memberships? Suddenly,
your airtight RLS blueprint has a user in two places at once, and
there’s a real risk they get access to data that’s no longer
theirs.It’s easy to assume that everyone in a particular Azure AD
group should get the same access. But in reality, group
memberships can grow stale. Someone might transfer to a different
region, but their name never leaves the original team list. Even
if you, as the admin, are pretty disciplined about cleaning up,
group owners rarely keep up with every shuffle, especially during
a busy quarter. And remember, the sync between Azure AD and Power
BI—or Fabric—isn’t always instant. Sometimes it lags by hours,
and that’s more than enough time for someone to see something
they shouldn’t after a change. Wait for an overnight batch, and a
departing employee can leave with a lot more context than you
intended.Shadow assignments might sound dramatic, but they're
almost routine. In most real-world environments, a single user
can easily end up in multiple groups, each mapped to different
RLS roles. The design is meant to be flexible, which is good in
theory. In practice, it means you’re juggling a web of inherited
permissions, and it’s not always clear who can see what unless
you manually chase it down. For example, if Sarah from finance
moves to HR, and nobody pulls her out of the finance group, she's
now wearing two hats—one current, one outdated. Most people don’t
even notice until Sarah herself tries to access a report meant
for finance and still gets right in, long after she’s gone to a
different department.Microsoft’s own security teams call out role
assignment errors as the #1 cause of accidental data exposure in
analytics environments. The math is simple: the more groups and
the more shifting users, the easier it is to overlook who’s
actually attached to each role. What makes it sneakier is the
lack of obvious feedback. Unlike other security mistakes, you
don’t get an error message or a break in the UI. There’s usually
no automated warning or forced review—an incorrect mapping can
sit in the shadows for months, surfacing only during an audit or
when someone stumbles onto data they weren’t meant to touch.Even
the best intentions get whittled away by day-to-day realities.
Reviewing group memberships is a best practice that everyone
recommends, but few teams actually follow with any rigor. From
the admin side, it’s tedious work—manual group reviews aren’t
exactly a top-of-mind priority, especially if the analytics team
is firefighting other issues. And in most organizations, there
isn’t a process set up for regular audits, because it’s assumed
that changes in HR or IT will trickle through. But assumptions
are exactly what let permissions drift and shadow access persist.
The result? Over time, your RLS model—no matter how precise on
paper—gets out of sync with who should really see what.Automated
auditing tools can help spot these lingering assignments, but
getting them stood up takes work. They need to connect your Azure
AD, flag changes, maybe even trigger a workflow when someone’s
group memberships don’t match their business unit anymore. Not
every Power BI environment has those kinds of checks in place,
especially smaller shops or projects run off tight deadlines. So,
group sprawl becomes inevitable—the longer your RLS system sits,
the more likely it is that permissions go stale, or worse,
cascade into different layers you’re not even tracking.What
really catches people off guard is that assignments aren’t just a
checkmark. They’re the continuous link that binds your security
logic to real people. Leave them to drift, and all the clever DAX
in the world won’t save you. Assignment hygiene is an active
process, not a one-and-done setup. Systems evolve. Users move.
Your model has to track those changes, or you’re left relying on
luck. And luck isn’t a security strategy.Now, even with the
tightest assignment processes, a major curveball comes the moment
you take your carefully built solution from Power BI Desktop into
the wild: Fabric. Up until this point, most teams are testing in
the local sandbox, on their own machine, with only test accounts.
Things feel predictable. But move to Fabric, and all sorts of
subtle differences in user context, group resolution, and
authentication timing begin to show up. That’s where we run into
the quirks nobody expects—and why assignments that seem perfect
in theory can break spectacularly in production.


From Desktop to Fabric: The Hidden Shifts in RLS Behavior


If you’ve ever been convinced you had Row-Level Security
completely under control in Power BI Desktop, but then watched
everything unravel the moment you published to Fabric, you’re in
familiar territory. This is the part nobody tells you about in
RLS tutorials—the moment where all that flawless role and filter
logic runs headlong into the reality of the cloud. You’ve checked
every filter, carefully mapped every group, and even tidied up
those edge-case assignments. But the second you move to the
Fabric service, things shift in a way that catches even seasoned
admins off guard.Let’s start with what you see in Desktop. The
preview works just like you’d expect. You test user roles; you
toggle between sample identities. Everything lines up perfectly,
the numbers match, and for a moment, it feels like you’ve nailed
a straightforward process. But as soon as your teammates start
opening that same Power BI file in the cloud, the stories start
rolling in. Somebody reports seeing numbers outside of their
region, or worse, someone’s locked out of a dataset they
absolutely need to do their job. The frustration grows when you
realize the same RLS setup that was watertight on your machine
now acts more like a suggestion than a rule.That confusion comes
down to differences you can’t actually see until you publish.
Fabric’s cloud environment operates in a different world when it
comes to security, identity, and data context. One classic gotcha
hits right at the heart of dynamic RLS patterns. In Desktop, a
DAX function like USERNAME() pulls your local Windows login.
Simple, predictable, and—inside your environment—reassuringly
stable. But on Fabric, that same USERNAME() call grabs your full
email address instead. It sounds minor, but if your filter or
lookup references domain names, or if your security table keys
off short formats versus full emails, the entire system breaks
down the moment users hit the cloud.Inevitably, you start running
into complaints. Here’s what happens in real environments: a
report shows a country breakdown in Desktop, but after publish,
users see global numbers. Maybe your model relied on
USERPRINCIPALNAME() because all your access keys are email
addresses. That’s good practice for cloud, but if you started out
in Desktop and didn’t know this shift happens, you’re debugging a
problem that doesn’t exist locally but explodes at scale. The
truth is, what works on your laptop is more of a decent prototype
than a finished solution. Local logic can hide a landmine that
only cloud authentication triggers.There are also a few invisible
levers Fabric pulls without warning. Data refreshes, for one, can
fire off with different credentials or land on a different model
owner than you expect. If the published dataset’s owner isn’t in
the right group, they can end up seeing no data at all, or
getting access to everything by accident. Changing ownership in
the cloud doesn’t just affect permissions—it can break
connections to gateways or change how credentials are evaluated
against source systems. Sometimes, tenant settings hide legacy
behavior or default to options that override what you set up
during Desktop testing. For organizations with layered tenant
policies, something as small as toggling external sharing can
shift the logic of who sees what overnight.What throws people is
how subtle these changes are. They don’t shout, “Hey, your RLS is
broken now!” Instead, things operate quietly wrong. A small
change in authentication, or the way a model resolves group
membership during sign-in, mutates security context entirely.
Microsoft’s support forums are packed with admins trading horror
stories about reports that passed every Desktop test, only to
fall apart once users started accessing them in the cloud. You
see threads where, after a rollout, teams are scrambling to patch
or redesign all their RLS roles—not because the logic was bad,
but because the move to Fabric shifted the identity context
enough to make everything unreliable.Even cloud upgrades or
tenant-wide updates can nudge security in new directions.
Sometimes after an update, group mappings managed by Azure AD
sync just a little differently than before, so that shadow
assignments suddenly have more priority or certain dynamic
lookups run into nulls where you expected a match. Small changes
add up. A tweak in one piece of the stack ripples through the
whole security mesh, and your most reliable pattern from last
quarter just doesn’t hold up today.That’s why real-world teams
have started to treat RLS testing as a production job, not just a
local check. It’s not enough to click through roles on your own
laptop. You need to actually stage the model in Fabric, bring in
real user accounts, and walk through the end-to-end permission
flow. Only then do you catch subtle authentication bugs or
misalignments between group assignments and what Power BI thinks
is current in Azure AD. Some organizations even script out
periodic RLS audits in the cloud, just to check for drift between
assignment, model logic, and what Fabric actually
enforces.There’s no shortcut here. If you’re not testing with
real people in the environment where your report truly lives,
your RLS is basically running on hope. The cloud is the final
referee, and the only way to see how filters and roles interact
with identities at scale is to build your RLS with production in
mind from the start. If you leave these tests for later, you’re
flying blind, and the consequences—exposed data, frustrated
teams, or careful security work undone by a hidden switch—wind up
costing far more to fix once the report’s in use.Now, facing this
landscape, the big question isn’t just about patching up your RLS
each time something shifts. It’s about whether you have a plan
that works as your Fabric setup gets more complicated, your data
grows, and the business keeps changing. Every gap you find in
cloud testing is a signal to rethink—not just patch—the blueprint
for scalable, reliable Row-Level Security moving forward. That’s
not a one-time job, but an ongoing part of managing analytics at
any real scale. And as Fabric gets integrated deeper into how
organizations manage and share data, missing this cloud-driven
piece of RLS logic is where most mature deployments trip
themselves up.


Conclusion


Every time you update a role, tweak a filter, or shuffle user
groups, you’re working with a system that never sits still. RLS
isn’t just a one-time project—it’s ongoing architecture that
needs real maintenance. Anyone treating it like a checkbox is on
borrowed time and hoping nothing changes, but everything does. If
you want Power BI models that actually stay secure, plan for
regular reviews, real cloud testing, and scheduled audits as
business teams and data grow. As the organization evolves,
revisit your RLS because yesterday’s setup won’t guard today’s
data. This mindset is where real Microsoft data security begins.


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