Enable Dynamic RLS Role Switching via Slicers in Power BI

Power BI currently applies only one RLS role per user per dataset, evaluated before the report loads. Because of this, slicers or disconnected tables cannot be used to let users pick which role they want to view the report as (e.g., SuperUser vs CompanyHR vs Self).

This creates a major limitation for users who legitimately have multiple roles. In real scenarios, a user may need to switch between their restricted view (HR) and full view (SuperUser), but Power BI always forces the most permissive role and offers no way to choose.

The only supported workaround today is creating multiple datasets and duplicated reports, which becomes unmanageable and not scalable as the number of roles grows.

Requested Feature:
Allow users to choose their active RLS role dynamically inside the report—using a slicer, parameter, or a built-in role selector. RLS should respect the user’s choice among the roles assigned to them.

This would avoid dataset duplication, reduce maintenance, and support common enterprise use cases where users hold multiple roles.

Why This Is Important

Many enterprise scenarios involve users who hold multiple business roles, such as:

• SuperUser + Company HR

• Manager + Auditor

• Global Admin + Regional Admin

• Internal + External View

• Multiple market/country responsibilities

These users need the ability to explicitly pick which role they want to use for a report, not always default to the most permissive one.

Proposed Enhancement

Introduce a new RLS feature such as:

1. Dynamic RLS mode

   • Allow RLS expressions to reference a special runtime value (e.g., RLSSELECTEDROLE()) set by a slicer or parameter.

2. Session-based role override

   • After login, users can pick one of their assigned roles for that session.

3. UI-based role selector

   • A Power BI native visual that lists roles the user has access to, enabling runtime switching.

4. Dataset-level “multiple active roles” mode

   • Allow RLS to author rules based on a user’s chosen role rather than forcing one default.

These changes would keep security intact while allowing more flexible, real-world role behavior.

Thanks for considering this. Let me know if further clarification is needed.