Why RLS protects sensitive data in Power BI - Business Case Study

Scenario Mode

👤 Your Role: You are a Power BI developer at a retail company.

📋 Request: Your manager wants you to explain and demonstrate how Row-Level Security (RLS) protects sensitive sales data so that each regional manager only sees their own region's data.

📊 Data: You have a sales dataset with columns: Region, Salesperson, SalesAmount, and Date. The data includes sales from North, South, East, and West regions.

🎯 Deliverable: Create a Power BI report with RLS applied so that when a regional manager views the report, they only see sales data for their region. Also, provide a simple explanation of how RLS protects sensitive data.

Sample Data

Region	Salesperson	SalesAmount	Date
North	Alice	5000	2024-01-10
South	Bob	7000	2024-01-12
East	Charlie	6000	2024-01-15
West	Diana	5500	2024-01-20
North	Eva	6500	2024-02-05
South	Frank	7200	2024-02-10
East	Grace	5800	2024-02-15
West	Henry	5300	2024-02-18

1

Step 1: Load the sales data into Power BI Desktop.

Import the table with columns: Region, Salesperson, SalesAmount, Date.

Expected Result

Sales data is visible in Power BI data view with all rows.

2

Step 2: Create a Row-Level Security (RLS) role for each region.

In Power BI Desktop, go to Modeling > Manage Roles. Create a role named 'NorthRegion' with DAX filter: [Region] = "North". Repeat for South, East, and West with respective filters.

Expected Result

Four roles created, each filtering data to only one region.

3

Step 3: Test the RLS roles in Power BI Desktop.

Use Modeling > View as Roles, select 'NorthRegion' role to see data filtered to North region only.

Expected Result

Only sales rows where Region = North are visible.

4

Step 4: Publish the report to Power BI Service and assign users to roles.

In Power BI Service, assign each regional manager to their respective RLS role under dataset security settings.

Expected Result

Each manager can only see their region's sales data when viewing the report.

5

Step 5: Explain how RLS protects sensitive data.

RLS restricts data access by filtering rows based on user roles, so users only see data they are allowed to see.

Expected Result

Managers cannot see sales data from other regions, protecting sensitive information.

Final Result

Power BI Report Dashboard
-------------------------
| Region | Salesperson | SalesAmount |
|--------|-------------|-------------|
| North  | Alice       | 5000        |
| North  | Eva         | 6500        |

(When viewed as NorthRegion role)

Key: Each regional manager sees only their region's sales data.

✓RLS filters data so users see only their allowed rows.

✓Sensitive sales data from other regions is hidden.

✓This protects company data privacy and security.

Bonus Challenge

Create a dynamic RLS role that filters data based on the logged-in user's email instead of fixed region roles.

Show Hint

Use USERPRINCIPALNAME() DAX function in the role filter to match user email with a table mapping emails to regions.

Practice

1. What is the main purpose of Row-Level Security (RLS) in Power BI?

easy

A. To speed up data refresh times

B. To change the visual design of the report for each user

C. To create new calculated columns automatically

D. To restrict data access by filtering rows based on the user's identity

Solution

1. Step 1: Understand RLS functionality

   RLS filters data rows so users only see data they are allowed to access.

2. Step 2: Compare options

   Speeding up refresh times, changing visual design, and creating calculated columns describe unrelated features; only restricting data access by filtering rows based on user identity matches RLS purpose.

3. Final Answer:

   To restrict data access by filtering rows based on the user's identity -> Option D

4. Quick Check:

   RLS filters rows by user identity = C [OK]

Hint: RLS controls data visibility per user, not report design [OK]

Common Mistakes:

• Confusing RLS with report formatting
• Thinking RLS speeds up data refresh
• Believing RLS creates new columns

2. Which of the following is the correct way to define a filter in a Power BI RLS role?

easy

A. FILTER('Sales', 'Sales'[Region] = "USERNAME()")

B. FILTER('Sales', 'Sales'[Region] == USERNAME())

C. FILTER('Sales', 'Sales'[Region] = USERPRINCIPALNAME())

D. FILTER('Sales', 'Sales'[Region] = USERNAME())

Solution

1. Step 1: Identify correct DAX function for user identity

   USERPRINCIPALNAME() returns the logged-in user's full username, commonly used in RLS filters.

2. Step 2: Check syntax correctness

   FILTER('Sales', 'Sales'[Region] = USERPRINCIPALNAME()) uses correct syntax and function. Using double equals (==), treating the function as a string, or using USERNAME() instead misuses syntax or less preferred function.

3. Final Answer:

   FILTER('Sales', 'Sales'[Region] = USERPRINCIPALNAME()) -> Option C

4. Quick Check:

   Use USERPRINCIPALNAME() for RLS filters = A [OK]

Hint: Use USERPRINCIPALNAME() for user-based filters in RLS [OK]

Common Mistakes:

• Using USERNAME() instead of USERPRINCIPALNAME()
• Using double equals (==) in DAX
• Putting USERNAME() inside quotes

3. Given this RLS filter on the 'Sales' table:
FILTER('Sales', 'Sales'[Salesperson] = USERPRINCIPALNAME())
If the logged-in user is '[e-mail]', what data will Alice see?

medium

A. All sales data regardless of salesperson

B. Only sales where 'Salesperson' equals '[e-mail]'

C. No data because USERPRINCIPALNAME() is invalid

D. Sales data for all salespersons except '[e-mail]'

Solution

1. Step 1: Understand the filter condition

   The filter keeps rows where 'Salesperson' matches the logged-in user's email.

2. Step 2: Apply the filter for user '[e-mail]'

   Only rows with 'Salesperson' = '[e-mail]' remain visible to Alice.

3. Final Answer:

   Only sales where 'Salesperson' equals '[e-mail]' -> Option B

4. Quick Check:

   RLS shows user-specific rows = B [OK]

Hint: RLS filters rows matching logged-in user exactly [OK]

Common Mistakes:

• Assuming all data is visible
• Thinking USERPRINCIPALNAME() is invalid
• Believing data for other users is shown

4. You created this RLS role filter:
FILTER('Orders', 'Orders'[Country] = USERNAME())
But users report seeing no data. What is the most likely issue?

medium

A. USERNAME() returns only the username, not the country name

B. FILTER function is not supported in RLS roles

C. The table name 'Orders' is misspelled

D. RLS roles cannot filter by text columns

Solution

1. Step 1: Understand USERNAME() output

   USERNAME() returns the user's login name, not a country name.

2. Step 2: Compare USERNAME() with 'Country' column

   Since 'Country' contains country names, the filter never matches, so no data shows.

3. Final Answer:

   USERNAME() returns only the username, not the country name -> Option A

4. Quick Check:

   Mismatch between USERNAME() and column values = A [OK]

Hint: Match USERPRINCIPALNAME() or correct user info to column values [OK]

Common Mistakes:

• Assuming USERNAME() returns country
• Thinking FILTER is unsupported in RLS
• Ignoring case sensitivity in filters

5. You want to protect sensitive sales data so that each regional manager sees only their region's data. Which approach best uses RLS to achieve this?

hard

A. Create a role with filter 'Sales'[Region] = LOOKUPVALUE('Managers'[Region], 'Managers'[Email], USERPRINCIPALNAME()) and assign managers by email

B. Do not use RLS; instead, create separate reports for each region

C. Create a role with filter 'Sales'[Region] = "Region1" and assign all managers to this role

D. Create a role with filter 'Sales'[Region] = USERPRINCIPALNAME() and assign managers their email as region

Solution

1. Step 1: Understand the need for dynamic filtering

   Each manager should see data for their assigned region, which may differ from their username.

2. Step 2: Use LOOKUPVALUE to map manager email to region

   Create a role with filter 'Sales'[Region] = LOOKUPVALUE('Managers'[Region], 'Managers'[Email], USERPRINCIPALNAME()) and assign managers by email uses LOOKUPVALUE to find the manager's region from a 'Managers' table, enabling correct filtering.

3. Step 3: Evaluate other options

   Create a role with filter 'Sales'[Region] = USERPRINCIPALNAME() and assign managers their email as region incorrectly assumes email equals region; C assigns all managers to one region; B avoids RLS and is less efficient.

4. Final Answer:

   Create a role with filter 'Sales'[Region] = LOOKUPVALUE('Managers'[Region], 'Managers'[Email], USERPRINCIPALNAME()) and assign managers by email -> Option A

5. Quick Check:

   Use LOOKUPVALUE for dynamic RLS filtering = D [OK]

Hint: Use LOOKUPVALUE to map users to their data dynamically [OK]

Common Mistakes:

• Assuming username equals region directly
• Assigning all users to one static region
• Avoiding RLS and duplicating reports