Implementing Row-Level Security in Power BI with Fabric: How DAX, Roles and Relationships Really Decide Who Sees Your Data

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 LEARNWhy 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.How relationships, filter directions, and new tables can undermine or strengthen your security model over time.Why RLS needs ongoing governance—reviews, naming standards, and testing—as your org structure and Fabric models evolve.CORE INSIGHTThe core insight of this episode is that Row-Level Security is not “one filter per role”—it is a network of filters, relationships, and user mappings that lives and changes with your data model. When you treat RLS as part of your Fabric architecture instead of a setup step, you stop relying on luck and start building Power BI models that stay aligned with real-world access rules even as your organization grows.WHO THIS IS FORPower BI and Fabric developers implementing RLS on top of Lakehouse-backed models.Data and security architects responsible for aligning BI access with Entra ID and organizational roles.Analytics leads who have already been surprised by users seeing data outside their region or area.Compliance and audit teams who need confidence that “RLS is on” actually means “sensitive data is protected.”ABOUT THE HOSTMirko Peters is a Microsoft 365 and cloud consultant and the host of M365.FM, focused on modern work, security, and data architectures that hold up under real-world pressure. He helps organizations design context-driven systems on Microsoft 365, Fabric, and Power BI where identity, governance, and Row-Level Security work together instead of fighting each other. In M365.FM, Mirko turns deep-dive topics like implementing RLS in Fabric—from DAX quirks to real incidents—into practical patterns you can apply directly to your own models.Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.