5.2.3. Row-Level Security

💡 First Principle: Row-level security filters the data itself, inside the semantic model, according to who is asking. Because the filter lives in the model, every report, dashboard, Excel connection, and Copilot query built on it respects the same restriction, so one definition protects every access path.

Define roles in Power BI Desktop (Modeling > Manage roles): create a role, choose a table, and define a filter with the role editor or a DAX filter expression that returns true for rows the role may see. Roles can also be defined when editing the data model in the Power BI service, but assigning members to roles happens only in the service.

• Static RLS: hard-coded values, one role per value. [Region] = "West" in a West role.
• Dynamic RLS: one role whose filter uses the signed-in user's identity, typically with USERPRINCIPALNAME(), which returns the user's UPN (e.g., user@contoso.com) in the service. A security table maps users to permitted values: 'Security'[UserEmail] = USERPRINCIPALNAME(), with Security related to the Region dimension so the filter propagates to facts. Dynamic RLS scales: adding a user means adding a row to the security table, not editing roles.
• Filters propagate through relationships like any filter (one side to many side). If the security filter must cross a bidirectional relationship, enable Apply security filter in both directions on that relationship (3.1.2).

Test roles in Desktop with View as (choose one or more roles, or Other user to simulate a UPN for dynamic RLS), and in the service with Test as role on the semantic model's Security page.

Assign membership in the Power BI service: after publishing, open the semantic model's Security settings, select a role, and add users or Microsoft Entra security groups (groups are recommended so membership is managed centrally). This is the "configure row-level security group membership" objective: add the group, not every individual. If a user belongs to multiple roles, the roles are combined (union), so they see rows permitted by any of their roles.

Other points the exam uses: RLS defined on a model is inherited by every report, dashboard, and app using it; when a model has roles, a Viewer not assigned to any role sees no data from secured tables; object-level security (hiding tables or columns from roles) exists but is configured with external tools such as Tabular Editor; and RLS isn't a substitute for not loading data that nobody should see.

⚠️ Exam Trap: Testing an RLS role while signed in as the workspace admin shows all data, because RLS doesn't apply to Admins, Members, or Contributors. Use View as in Desktop or Test as role in the service, and remember that real users must have Viewer role or app/shared access for RLS to take effect.

Reflection Question: A company has 40 sales regions and staff move between regions monthly. Compare maintaining 40 static roles with a single dynamic role, and describe the security table and relationship the dynamic design needs.