What is Row-Level Security in Power BI?
Row-Level Security (RLS) in Power BI limits the data a user can see by filtering table rows based on their identity or role. You define roles in Power BI Desktop using DAX filter expressions, then assign users to those roles in the Power BI Service. This prevents users from seeing data they are not authorised to access, without needing a separate report per person.
Row-Level Security in Power BI restricts which rows of data a user sees based on their identity, so each person only accesses data relevant to their role.
What RLS Does
RLS filters table rows based on who is viewing the report. When a sales manager from the West region logs into a shared dashboard, they see only West region data. A colleague from the East region sees the same report layout but with East region data. The underlying dataset is the same; the filter applied at query time determines what each person can access. This saves you from maintaining multiple copies of the same report and reduces the risk of accidental data exposure.
How RLS Works in Power BI
RLS works through two components: roles and DAX filters. A role is a named security profile, such as “Sales West” or “Finance Read-Only”. You attach a DAX filter expression to one or more tables in that role. For example, a filter on a Region column might look like this: [Region] = "West". When a user assigned to the “Sales West” role opens the report, Power BI applies that DAX filter automatically before rendering any visual. The filter respects relationships in your data model, so it propagates to related tables as well.
Static vs Dynamic RLS
Static RLS uses hardcoded values in DAX filters. You create a separate role for each region or department, and each role has its own fixed filter. This is straightforward to set up but does not scale well when you have many users or frequently changing access rules.
Dynamic RLS uses the USERNAME() or USERPRINCIPALNAME() function to look up the logged-in user in a mapping table within your data model. You create one role, and the DAX filter compares the current user’s email address to a column in a user-permissions table. This approach scales to hundreds of users without adding new roles.
Typical Use Cases
RLS fits any scenario where different users should see different subsets of the same data. Common examples include a sales team where each representative sees only their own accounts, a regional manager who sees all stores in their territory but not those in other territories, or a finance dashboard where department heads see only their own budget lines. You can also use RLS to hide sensitive KPIs from certain user groups while keeping the same report structure for everyone. See How to Set Up Row-Level Security in Power BI for a step-by-step walkthrough.
What RLS Does Not Cover
RLS controls row-level access to data within a report. It does not control access to the report itself: you manage that through workspace permissions and sharing settings in the Power BI Service. RLS also does not restrict access to the underlying dataset when a user connects from Excel or another tool unless you configure object-level security separately. For most reporting scenarios, RLS on its own is sufficient.
Our tip: Start with dynamic RLS from the beginning, even if you only have a handful of users now. Maintaining a user mapping table is far easier than going back later to replace dozens of static roles when your organisation grows.
Frequently asked questions
What is the difference between static and dynamic RLS in Power BI?
Static RLS uses fixed DAX filter values per role, for example a role for 'North' that always filters Region = 'North'. Dynamic RLS uses the USERNAME() or USERPRINCIPALNAME() function to look up the logged-in user in a mapping table. Dynamic RLS scales better: instead of creating a new role for every user, you maintain a single role and a user mapping table that controls who sees what.
Does RLS work in Power BI Desktop?
You define and test roles in Power BI Desktop, but RLS is only enforced when you publish the report to the Power BI Service and assign users to roles there. In Desktop you can use the 'View as role' feature to test how the report looks for a specific role, but any user who has access to the .pbix file on their computer can open it and bypass RLS restrictions.
Does RLS apply to all visuals in a report automatically?
Yes. Once you define a role with a DAX filter on a table, that filter propagates automatically to all visuals in the report that use data from that table or related tables. You do not need to configure RLS separately per visual or per page. If your data model has correct relationships, a filter on one table flows through to all connected tables.
Can you use RLS with DirectQuery?
Yes, RLS works with both Import and DirectQuery mode in Power BI. With DirectQuery, the RLS filter is passed to the underlying data source as part of the query, so only the permitted rows are retrieved. This is useful for large datasets where you cannot import all data into Power BI. The behaviour is the same from the user perspective: they only see the rows their role allows.