Power BI row-level security: a practical setup

Row-level security answers a simple question: which rows may this person see? Start with the business rule, not the DAX. A regional manager sees their region. An account owner sees their accounts. A supplier sees their own orders. Write each rule as a sentence and identify the column that carries the restriction.

RLS filters data, not the report layout. It does not hide a visual, a page, or a measure name. If a page must be invisible to a group, use separate reports or apps, not RLS. If a column must be hidden, that is object-level security, a different feature.

A static role with a hard-coded filter is fine for one or two rules, but it does not scale. A mapping table is easier to audit: one row per user and permitted value, with the user's sign-in name in a column. Relate it to the dimension it restricts, hide it from report view, and refresh it from a controlled source.

Use the same identifier format the service returns. A mismatch in domain, case, or alias will silently return no rows. Keep the table small, with one row per user and scope, and add an explicit row for administrators only if they need full access.

Keep the mapping table in a source with an owner and a change history. A spreadsheet on a personal drive is a security risk, because nobody can prove who changed access or when.

For a simple mapping table related to a dimension, the role filter goes on the mapping table. The relationship propagates the filter to the dimension and then to the fact. This is easier to maintain than repeating a filter on every table.

Role filter: 'Security'[Login] = USERPRINCIPALNAME ()

Role filter for a hierarchy: PATHCONTAINS ( 'Employee'[Management Path], USERPRINCIPALNAME () )

The second pattern works for a manager hierarchy where the path column contains the sign-in names of the managers above each employee. For a rule that spans several values, use a table expression rather than a chain of OR conditions. Keep the filter on a narrow table with a clear relationship; a complex filter over a fact table will slow every query.

In Power BI Desktop, use View as role and enter a test identity. Check a table of the restricted dimension, a card with a total, and a matrix that crosses the restricted dimension with another. Confirm that the total matches the expected subset, not the full total with blank rows.

Then test the negative case: a user with no mapping should see no rows, not all rows. Test an administrator identity, a user in two regions, and a user whose name differs by case. Role membership is additive, so overlapping roles can widen access; make sure that is intended.

Assign users to roles in the workspace or app. Prefer security groups over individuals so joiners and leavers are handled by directory membership. Keep one owner for the mapping table and a documented refresh path. If the mapping table is refreshed manually, say so and set a reminder; stale membership is a security gap.

RLS does not replace workspace permissions. Anyone with Admin, Member, or Contributor access can edit the semantic model and is not restricted by the roles. Publish through an app, give viewers read access, and review who can edit. RLS also does not protect data that someone has already exported, and it does not apply to publish to web.

DirectQuery models apply the role filter at query time, so the source returns only permitted rows. The source database still needs its own access controls for anyone who can query it directly. For embedded reports, pass the effective identity through the embedding pattern; a fixed service principal identity will not produce per-user filtering.