Row-Level Security (RLS)

Row-Level Security, or RLS, is a way to restrict what data a specific user can see inside a Power BI report. Instead of building separate reports for each department, manager, or region, you build one report and then tell Power BI, ‘User A sees only rows where Region = West, and User B sees only rows where Region = East.’ Power BI does the hiding automatically at the row level.

To understand RLS, you need to know a few key terms. A ‘role’ is a named group with a set of permissions. For example, ‘Sales Managers’ could be one role. A ‘rule’ is a DAX expression that returns either TRUE or FALSE for each row. DAX stands for Data Analysis Expressions, the formula language of Power BI. The rule says, ‘Only show this row if the current user’s email matches the email in this column.’ DAX expressions look like this: [SalesRepEmail] = USERPRINCIPALNAME(). USERPRINCIPALNAME() is a built-in DAX function that returns the email address of the user viewing the report. When the rule evaluates each row, it checks if the email in that row matches the logged-in user’s email. If it matches, the row is visible. If not, the row is completely hidden.

RLS works only after a report is published to the Power BI Service, not in Power BI Desktop. In Desktop you define the roles and rules, but you cannot see the filtering until you ‘View As’ a specific role. When you publish the report, you then go to the Power BI Service, open the dataset settings, and assign users (from Microsoft Entra ID) to the roles you created. Microsoft Entra ID is the identity service that holds all user accounts for a Microsoft cloud environment. It used to be called Azure Active Directory.

There are two main approaches to RLS: static and dynamic. Static RLS means you define a rule that uses a fixed value, like [Region] = ‘West’. Every user in the role gets the same filter. Dynamic RLS means the rule uses the current user’s identity, like USERPRINCIPALNAME() = [Email]. Each user sees only their own data. Dynamic is more flexible because you do not need a separate role for each person.

RLS replaced the old method of creating multiple copies of the same report with different data sources or filters for each audience. That approach was slow, error-prone, and cluttered. RLS makes data governance simpler: one report, one dataset, but different views for different people. It is important to know that RLS does not encrypt or secure data at rest—it only controls what is visible in the report. A determined user with access to the underlying dataset could still extract the full data if they have other permissions. RLS is a reporting-layer control, not a database security measure.

Another critical detail: RLS applies to measures and calculated tables, but it cannot limit access to the data model itself if someone connects directly to the dataset with an external tool (like Excel or a dashboard in a different app). That is why organisations often combine RLS with other security controls, like object-level security (OLS) and data-source permissions.

When you create an RLS rule in Power BI Desktop, you use the Manage Roles button in the Modelling tab. You give the role a name, then choose a table and write a DAX expression that returns TRUE or FALSE. The expression is evaluated per row. You can use any standard DAX function: FILTER, CALCULATE, KEEPFILTERS, and the security-related functions like USERNAME(), USERPRINCIPALNAME(), and CUSTOMDATA(). USERNAME() returns the user’s Windows logon (not usually useful for cloud reports), so USERPRINCIPALNAME() is the one you will use most often.

After publishing, in the Power BI Service, you go to the dataset, click Security, then add individuals or groups from Microsoft Entra ID to each role. A person can belong to multiple roles, and if they do, they see the union of all rows allowed by all their roles. Be careful: if the rule hides a whole table because of a relationship error, the user sees a blank report. This is a common trap in the exam.

RLS is also respected when a report is embedded in a custom application (Power BI Embedded) or shared via a Power BI App. However, if you allow users to Build permissions (create their own reports from your dataset), they might bypass RLS unless you also apply RLS at the dataset level. The exam tests this nuance: RLS is bypassed when someone builds a new report using the dataset unless restrictive permissions are in place.

Imagine you are a Power BI analyst at a national retail company called ShopCo. The company has 30 regional sales managers, each responsible for one region. The CEO wants one master sales report that every manager can use, but each manager must see only their own region’s data. You cannot build 30 separate reports—that would be a maintenance nightmare. Instead, you build one report with RLS.

Here is what you actually do, step by step. First, you open the dataset in Power BI Desktop. You have a table called ‘Sales’ with columns: Region, SalesRep, Revenue, Date. You also have a table called ‘Users’ with columns: Email, Region, Role. You build a relationship between Users[Region] and Sales[Region].

Second, you click Manage Roles in the Modelling tab. You create a role called ‘Regional Manager’. In the DAX formula bar, you write: [Region] = LOOKUPVALUE(Users[Region], Users[Email], USERPRINCIPALNAME()). This reads the current user’s email, finds their region in the Users table, and then filters the Sales table to show only rows where the Region matches.

Third, you test the role using the ‘View As’ button under the ribbon. You select the role, then type in or select a test user’s principal name. Power BI Desktop shows you exactly what that user would see—you can confirm the data is filtered correctly. You also test a user who should see no data to ensure the rule does not break (it should show a blank visual, not an error).

Fourth, you publish the report to the Power BI Service. You navigate to the dataset, click the Security icon. You see your ‘Regional Manager’ role listed. You click Add Members and type the email addresses of the actual regional managers from Microsoft Entra ID. You can add individuals or security groups. Using security groups is better administration because you manage access in Microsoft Entra ID when a manager leaves or joins.

Fifth, you share the report with all managers by giving them Viewer access through a Power BI App. You do not give Build permission or Contributor access to the dataset, because that would let them bypass RLS by creating their own reports from the same dataset. You only give them App Viewer access.

Now each manager logs into Power BI, opens the app, and sees the exact same sales report—but with different numbers. The Western manager sees only rows where Region = West. The Eastern manager sees only East. The CEO, if added to a special role with no filter (or to a role where the rule allows all rows), sees the entire dataset. If a bug happens—like a manager seeing no data—you troubleshoot by checking three things:

If a manager accidentally sees another region’s data, the most likely cause is a missing or incorrect relationship, or a DAX expression that evaluates to TRUE for more rows than intended. You would use DAX Studio or run DAX queries to debug the expression.