Why RLS protects sensitive data in Power BI - Quick Recap

Recall & Review

beginner

What does RLS stand for in Power BI?

RLS stands for Row-Level Security. It controls access to data at the row level based on user roles.

beginner

How does RLS protect sensitive data?

RLS restricts which rows of data a user can see, so users only view data they are allowed to access.

beginner

Why is RLS important for shared reports?

Because multiple users can access the same report but see only their allowed data, keeping sensitive info private.

beginner

What happens if RLS is not used in a report with sensitive data?

All users might see all data, including sensitive information they shouldn’t access, risking data leaks.

intermediate

Can RLS be customized for different users?

Yes, RLS roles can be created with different filters so each user sees only the data relevant to them.

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

A To export data to Excel

B To improve report loading speed

C To restrict data access based on user roles

D To change report colors automatically

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

If RLS is not applied, what risk does a report have?

A Report will not open

B Users may see all data including sensitive info

C Data will be deleted automatically

D Report will load faster

Without RLS, all users can see all data, risking exposure of sensitive information.

How does RLS filter data for users?

A By applying filters on rows based on user roles

B By changing column names

C By hiding visuals

D By exporting data

RLS applies filters on rows so users only see allowed data.

Can RLS be set differently for different users in the same report?

A Yes, by creating different roles with filters

B No, RLS applies the same filter to all users

C Only for admins

D Only for report creators

Different roles with specific filters can be created to customize data access.

Which of these is NOT a benefit of using RLS?

A Protecting sensitive data

B Allowing users to see only relevant data

C Sharing one report with multiple users securely

D Automatically fixing data errors

RLS controls data access but does not fix data errors automatically.

Explain in your own words how RLS helps protect sensitive data in Power BI reports.

Think about who can see what data when RLS is applied.

Describe what could happen if you share a report with sensitive data but do not use RLS.

Consider the risks of no restrictions on data visibility.

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