Episode Details

Most teams treat Row-Level Security in Power BI like a checkbox: create a role, add a filter, assign some users, and move on. In this episode, we dig into why that mindset quietly leads to leaks—like regional managers seeing the wrong pipeline, or “global” roles exposing HR or finance data—once your model lands in Fabric and real users start exploring. We walk through how roles, relationships, and DAX filters actually work together in a Fabric-backed model, and why one missed table or the wrong function (USERNAME vs USERPRINCIPALNAME) can make RLS behave perfectly in Desktop but fall apart in the service.

We start by reframing RLS as a living system, not a one-time toggle. You’ll hear how every role definition, filter expression, and relationship line in your model cooperates to decide who can see which rows, and how small changes—adding a new table, tweaking a relationship, or introducing a calculated column—can quietly undo your intent. Real-world incidents, from European sales leads seeing US numbers to legacy “manager” roles exposing payroll figures, show that most breaches are configuration accidents, not hacks.

From there, we get into the core building blocks: static vs dynamic RLS, user-mapping tables, and DAX that actually respects the current viewer. We explain why calculated columns evaluated at refresh time don’t work for per-user security, why Microsoft and MVP guidance push you toward dynamic filters built on tables that respond to user context, and how to combine USERPRINCIPALNAME with an access matrix so each user only sees the territories, customers, or cost centers they’re entitled to. Along the way, we highlight how relationships and filter directions can either reinforce your security model or puncture it.

We also connect RLS to lifecycle and governance. As people change teams, new regions appear, and Fabric Lakehouse models grow, roles and mappings that made sense last quarter become dangerous leftovers. You’ll learn why RLS needs regular review just like permissions in Entra ID or SharePoint, how to design naming conventions and documentation that survive handovers, and which tests (including “view as role” scenarios and edge-case accounts) you should run before shipping models into production workspaces.

By the end, Row-Level Security in Power BI with Fabric will look less like a technical feature and more like part of your overall data protection architecture. You’ll walk away with a mental model where filters, roles, DAX, and relationships form a mesh you actively design and maintain—so your next dashboard doesn’t just hide the right rows, it proves to auditors and stakeholders that your security model actually matches how your organization works.

WHAT YOU LEARN

• Why RLS that “looks fine” in Desktop often behaves differently once you publish to Fabric workspaces.
• How misused functions (like confusing USERNAME and USERPRINCIPALNAME) and calculated columns quietly break dynamic RLS.
• How to design static and dynamic roles using user-mapping tables and DAX that responds to the current viewer.

  Listen Now