Trouble Shooting & FAQs

Troubleshooting Row Level Security (RLS

1.    Purpose

This section provides a structured approach to diagnosing and resolving issues related to Row Level Security (RLS).

The objective is to ensure that:

·        Users see only the data they are authorized to access.

·        Access issues such as no data visibility or overexposure of data are quickly identified and resolved.

2.    Common RLS Issues

Issue	Description
No Data Visible	User opens report but sees blank visuals
Excess Data Visible	User sees more data than expected
Partial Data	Some expected data is missing
Inconsistent Results	Data differs between Desktop and Service

3. Key Troubleshooting Areas

3.1 User Identity Validation

RLS is driven by the logged-in user identity using:

USERNAME()

Checks:

• Confirm that the email used in the RLS DAX exactly matches the user’s login email.
  • Ensure there are no spelling errors or domain mismatches 3.2 Data Availability Validation RLS only filters existing data. If the filtered values do not exist in the dataset, the user will see no data. Checks:
  • Confirm that the dataset contains the expected values. Example:
  • Allowed in RLS: GROUPAIR
  • Available in dataset: HAE, AIRCROSS Result:
  • No data will be returned. Resolution: Ensure that all values referenced in the RLS logic exist in the dataset.

3.3 RLS DAX Logic Validation

Incorrect DAX logic is a common cause of RLS failure.

Common Issues:

Incorrect Logical Conditions

[Database] = "HAE" && [Database] = "AIRCROSS"

This condition will never be true

Correct Approach

[Database] IN {"HAE", "AIRCROSS"}

Incorrect Default Condition

IF (

   USERNAME () = "user@email.com",

   [Database] = "HAE",

   FALSE ()

)

This blocks all other users completely.

Recommended Structure

IF(

   USERNAME() = "user@email.com",

   [Database] IN {"HAE","AIRCROSS"},

   IF(

       USERNAME() IN {Admin_List},

       TRUE(),

       FALSE()

   )

)

3.4 Role Assignment in Power BI Service Even with correct DAX logic, users will not see data if they are not assigned to the RLS role.

Checks:

• Navigate to: Power BI Service → Dataset → Security Confirm the user is added to the correct role.
  3.5 Data Model Relationships RLS filters propagate through relationships between tables. Checks:
  • Ensure relationships are:
    • Active
    • Correctly configured
  • Confirm RLS is applied on the correct table containing the filtering column (e.g. Database). 3.6 Report-Level Filters Report, page, or visual filters may override RLS. Checks:
  • Review:
    • Report filters
    • Page filters
    • Visual filters
    • Slicers Example:
  • RLS allows HAE
  • Report filter is set to ACS Result:
  • No data displayed

3.7 Data Consistency and Formatting

Text mismatches can cause filters to fail.

Checks:

• Case sensitivity:
  • "HAE" vs "hae"
• Trailing spaces:
  • "HAE " vs "HAE"

Recommended Fix:

UPPER([Database]) = "HAE"

4. RLS Testing Procedure

4.1 Testing in Power BI Desktop

Navigate to:

Model → View As

  Enter the user’s email.

 Validate visible data.

4.2 Testing in Power BI Service

   Go to Dataset → Security

    Use Test as Role

   Confirm expected results

5. Standard Troubleshooting Workflow

    When a user reports an issue, follow this sequence:

1. Verify USERNAME () output
2. Confirm user is assigned to role
3. Check if required data exists in dataset
4. Validate RLS DAX logic
5. Inspect relationships in data model
6. Remove report-level filters
7. Test using “View As”8. Refresh dataset