Episode Details

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 CheckboxIf 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 organ