Row-level security (RLS) is a Power BI feature that restricts which rows of data each person can see in a report, based on who they are. Instead of building a separate report for every team or region, you publish one report and each viewer sees only the rows that apply to them.
What row-level security is
Row-level security is a way to control who sees which data inside a single report. Without it, everyone who can open a Power BI report sees all of its data. With RLS switched on, the report is filtered for each person, so a regional manager opening the company sales report sees only their own region's rows.
The point is that it's still one report. You don't carve the data into a separate file per team. You build the report once, define the rules once, and Power BI applies the right filter to whoever is looking. Microsoft's guide to row-level security with Power BI describes RLS as a way to "restrict data access for given users".
Because the filtering happens on the data itself, RLS is part of the report's semantic model, the data layer behind the visuals. It is set up there, not bolted on afterwards.
How RLS works: roles and DAX rules
Row-level security is built from two pieces: roles and the people assigned to them. A role is a named set of filter rules; a member is a person who gets those rules applied when they view the report.
You create roles in Power BI Desktop, under Modelling then Manage roles. For each role you write a filter rule on one or more tables, expressed in DAX, the formula language of the model. A rule for a North region role might simply be [Region] = "North": any visual that touches that table is then limited to North rows. Microsoft's DAX overview documents the expression language these rules are written in.
Setup is split across two places. Roles and their rules are defined in Power BI Desktop; once the report is published, people are assigned to those roles as members in the Power BI service. That division between Power BI Desktop and the Power BI service is worth knowing: the rules and the people are managed in different tools.
Static vs dynamic RLS
There are two ways to write the filter rules, and the difference is how well they scale.
- Static RLS: each role carries a fixed, hard-coded filter, so you usually need one role per group. A report covering five regions needs five roles, each with a rule such as
[Region] = "South". It is simple to understand, but the number of roles grows with the number of groups. - Dynamic RLS: one role does the work for everyone. The filter rule uses a function such as
USERPRINCIPALNAME()to pick up the signed-in user, then matches them against a table that maps each person to the data they may see. Add a new starter to that mapping table and they are covered, with no new role to build.
Static RLS suits a handful of stable groups. Dynamic RLS suits a large or changing audience, because the rules stay the same however many people you add.
What RLS does and does not do
It helps to be precise about what row-level security controls. RLS filters data, meaning the rows in the model's tables. It decides which rows feed the visuals, so two people open the same report and see the same charts populated with different numbers.
RLS does not hide report pages, individual visuals or the structure of the model. Every viewer still sees the same layout. If you need to hide a whole page or a specific chart from certain people, that's a separate job, not something RLS handles.
One more boundary matters. RLS applies to people given a Viewer role on the content; report authors and workspace admins are not restricted by it and always see everything. To check how a role looks before publishing, Power BI Desktop has a View as roles option that previews the report as a chosen role would see it.
Why row-level security matters
The everyday problem RLS solves is one report, many audiences. A sales report might need to go to twelve regional managers who must each see only their own region. Without RLS, that's twelve reports to build, refresh and keep in step.
With RLS, it's one report. You maintain a single report and a single set of rules, and every manager sees a correctly filtered view. That saves real effort and removes a common way for sensitive data to leak: someone simply being shown rows that were never meant for them.
It also keeps the numbers consistent. When everyone draws on the same model and the same measures, the totals reconcile; the only thing that changes per viewer is which rows are in scope.
Sharing data safely is a core Power BI skill Reading about row-level security is a useful start; setting up roles and dynamic RLS that hold up in practice is a skill worth investing in. Our two-day, hands-on Power BI Masterclass covers data modelling and secure sharing the practical way, building and testing real roles rather than learning the theory in the abstract. If you are still comparing courses, our guide to choosing Power BI training in the UK sets out what to look for.
