Testing RLS in Power BI Service

Thorough testing is critical to ensure RLS works correctly. Incorrect configuration can lead to data leaks or users seeing no data at all.

Testing Methods

1. Test in Power BI Desktop (Quick Test)

Steps:

1. Go to Modeling → View as Roles
2. Select a role to test
3. Optionally check "Other user" and enter an email (for dynamic RLS)
4. The report re-renders with the filtered data
5. Navigate all pages and check every visual
6. Click Stop viewing to exit

What to Verify: • ✅ Correct rows are visible • ✅ Related tables are also filtered (filter propagation) • ✅ Measures calculate correctly with filtered data • ✅ No data leaks in any visual or page

2. Test in Power BI Service

Steps:

1. Navigate to the workspace → Click the dataset
2. Click ••• → Security
3. Select a role → Click "Test as role"
4. The report opens with RLS applied
5. Verify data visibility across all pages

Test as Specific User:

1. In the Security pane → Click "Test as" → Enter a user's email
2. This simulates what that specific user would see
3. Useful for validating dynamic RLS with different users

Testing Checklist

Common RLS Issues

Validating Dynamic RLS

For dynamic RLS, test with multiple user accounts:

1. Test User A: Should see Region = East → Verify ✅
2. Test User B: Should see Region = West → Verify ✅
3. Test Manager: Should see all regions → Verify ✅
4. Test unassigned user: Should see no data (if not in any role) → Verify ✅

Testing with REST API

For automated testing at scale, use the Power BI REST API:

Endpoint: POST /datasets/{datasetId}/executeQueries

With effective identity: • Specify a username and role in the request body • The API returns data as that user would see it • Useful for automated test suites

Best Practices for RLS Testing

• Test every role — don't assume one working role means all work • Test with real user accounts — not just "View as Roles" • Check edge cases — users with no role, users in multiple roles • Verify exports — ensure exported data is also filtered • Re-test after model changes — new tables or relationships may break RLS • Document test results — keep a record of what was tested and when