Row-level security (RLS) is essential for controlling who can see what data in your Power BI reports. Here are three key takeaways from this video:
- RLS works like a permanent, enforced filter. Instead of relying on page-level filters that any user could change, RLS restricts the actual rows of data a user can access at the semantic model level, ensuring they can never see data outside their assigned scope.
- Setting up RLS is a two-step process. First, you create and define roles with filtering rules in Power BI Desktop. Then, you publish to the Power BI Service and assign specific users to those roles, which is where the security is actually enforced.
- RLS only applies to viewers. Users with higher-level workspace access, such as Admin, Member, or Contributor, can see all data regardless of RLS roles. To enforce data restrictions, users must be assigned the Viewer role in the workspace.
This lesson is a preview from our Power BI Certification Course Online (includes software & exam). Enroll in this course for detailed lessons, live instructor support, and project-based training.
This is a lesson preview only. For the full lesson, purchase the course here.
When a Power BI report contains data for multiple regions, departments, or business units, there are situations where individual users should only see a subset of that data. A salesperson responsible for France should see French sales figures but not the numbers for Germany or the United Kingdom. Without row-level security, any user with access to the report can see everything, and while page-level filters can narrow the view, they can be changed or removed by the user at any time.
Row-level security solves this by restricting access at the data level. Rather than filtering a view that a user could adjust, RLS limits the actual rows of data that the user's session can access. Even measures that use ALL or ALLSELECTED functions in DAX are constrained by the RLS boundary, meaning a user assigned to a France role cannot see total company revenue across all regions. They can only see what their role permits.
Step One: Creating Roles in Power BI Desktop
The first step in implementing static RLS takes place in Power BI Desktop. Under the Modeling tab, you can create and manage roles. Each role is given a name and a set of rules that define which rows of data are visible to anyone assigned to that role.
For a territory-based example, you would create a role called "France" and define a rule on the territories table that says: show data only when the region equals France. This rule functions as a filter, and because the territories table is connected to the sales table through the data model's relationships, the filter flows through to restrict all related data. The key point is that RLS relies on the existing data model structure. The filter defined in the role propagates through relationships just like any other filter in Power BI, so the relationships and filter flow directions you have set up in your model determine how the security restriction cascades to other tables.
Before publishing, you can test the role directly in Power BI Desktop using the "View As" feature in the Modeling tab. This lets you see the report exactly as a user with that role would see it, confirming that the correct data is being shown and restricted.
Step Two: Publishing and Assigning Roles in the Service
Creating the role in Power BI Desktop only defines the rules. The security is not actually enforced until you publish the semantic model to the Power BI Service and assign users to the roles there. After publishing to a shared workspace, navigate to the semantic model (not the report) and open its security settings. You will see the roles you defined, and you can add individual users or groups to each one.
Once assigned, any user in that role will see only the data their role permits when they open any report built on that semantic model. This is an important distinction: because the security is applied at the semantic model level, every report that uses the same model inherits the same security rules automatically. You do not need to configure security separately for each report.
The Viewer Requirement
One of the most critical details of RLS implementation is that it only applies to users who have Viewer access to the workspace. Users with higher-level roles such as Admin, Member, or Contributor can see all data regardless of any RLS roles assigned to them. This means that the people who build, manage, and maintain reports can access everything they need, while the broader audience of report consumers has their view appropriately restricted.
When inviting users to a workspace, always ensure that anyone who should be subject to RLS is assigned as a Viewer. If they are given a higher access level, the row-level security rules will not be enforced for their sessions, and they will see the full, unfiltered dataset.
