What is row-level security in Power BI and how do you implement it?

Row-level security (RLS) restricts which rows a user can see within a single dataset, so one report serves everyone while each person sees only their own data.

Static RLS defines a role with a fixed DAX filter:

[Region] = "South"

You then assign users to that role. Simple, but it does not scale — a role per region quickly becomes unmanageable.

Dynamic RLS is the approach used in practice. One role filters based on who is viewing:

[SalesRepEmail] = USERPRINCIPALNAME()

For a hierarchy, add a permissions table mapping users to the regions or accounts they may see, relate it to the model, and filter through that relationship. Adding a new user then means adding a row to a table, not editing the model.

Important details:

• Test with "View as role" in Desktop before publishing, and test again in the Service — behaviour can differ.
• Filters propagate through relationships, so a filter on a dimension flows to the fact table. Check that it reaches everything it should, and watch for bidirectional relationships bypassing it.
• Workspace admins and members bypass RLS. Users must have Viewer access and be assigned to a role for it to apply — a genuine and frequently overlooked security gap.
• RLS filters rows, not columns or measures. Object-level security handles hiding columns.