Table of Contents
Introduction
Power BI security roles help determine what users can do and which data they can see. Workspace roles control activities such as editing and publishing, while row-level security (RLS) roles filter data within a semantic model. Effective access control requires both to match each person’s responsibilities.
Consider a sales report containing results for every country your organization operates in. One manager oversees United Kingdom and Italy, while another manages the United States. Both need the same report, but each should see only their assigned countries.
RLS supports this requirement without creating a separate report for every manager. However, a filtering rule is only part of the setup. Model relationships, user assignments, and workspace permissions determine whether that rule produces the intended result.
This guide explains how to prepare your model, create static and dynamic roles, assign users, and test access before distributing reports.
How Do Power BI Security Roles Differ from Workspace Roles?
Workspace roles determine a user’s responsibilities within a workspace. RLS roles define the rows available to a restricted report consumer. These settings work together, but assigning an RLS role does not remove the broader access granted by an editing role.
| Workspace | Typical responsibility | Does RLS restrict this workspace user? |
|---|---|---|
|
Admin |
Manage workspace settings, access, and content |
No |
|
Member |
Manage and publish content, with broader collaboration permissions |
No |
|
Contributor |
Create and edit workspace content |
No |
|
Viewer |
View and interact with content |
Yes, according to RLS assignments |
For regional managers who only consume reports, use an appropriate viewing arrangement, such as app access or the Viewer workspace role. Review their underlying semantic model permissions as well. Opening a report through an app does not cancel elevated permissions they already hold.
RLS restricts rows. If the requirement is to protect entire tables or columns, assess object-level security (OLS) separately. Hiding a field in the report authoring interface is not a substitute for access control.
What Should You Prepare Before Setting Up RLS?
The walkthrough below uses an Import semantic model and fictional manager accounts. Have Power BI Desktop, a workspace you can publish to, and the permissions needed to manage the model’s RLS membership. Confirm that your intended viewers have the licensing or capacity-based access required for your distribution method.
Keep the example’s scope in mind: Analysis Services live connections require security configuration in the source model, while other storage modes can introduce additional considerations.
Prepare the Country and Manager Mapping
Use four tables:
- Geography: One row per country, containing
CountryKeyandCountryName. - Stores: One row per store, containing
StoreKeyandCountryKey. - Sales: Sales transactions containing
StoreKeyand sales values. - ManagerAccess: One row for each permitted combination of user and country.
For example:
| UserUPN | CountryKey |
|---|---|
|
UK |
|
|
IT |
|
|
US |
The country keys must match those in Geography. Keep each user-country pair unique, remove obsolete assignments, and exclude blank identities or country keys.
Configure the Filter Path
For this example, configure these active relationships:
| Relationship | Configuration |
|---|---|
|
Geography[CountryKey] to Stores[CountryKey] |
One-to-many, single direction from Geography |
|
Stores[StoreKey] to Sales[StoreKey] |
One-to-many, single direction from Stores |
|
Geography[CountryKey] to ManagerAccess[CountryKey] |
One-to-many, with cross-filter direction set to Both and Apply security filter in both directions enabled |
The last relationship allows a security filter on ManagerAccess to reach Geography, then Stores and Sales. A standard one-way relationship from Geography to ManagerAccess would not provide that reverse security path.
Use this bidirectional security relationship deliberately. In larger models, additional paths can introduce ambiguity and performance problems. Confirm the design rather than enabling bidirectional filtering across every relationship.
Understanding how to manage Power BI semantic models helps clarify where these relationships and security definitions belong.
Should You Use Static or Dynamic Row-Level Security?
Static RLS applies a fixed filter to everyone assigned to a role. Dynamic RLS evaluates the user’s identity against an access mapping. Choose the approach based on how many access combinations you maintain and how often they change.
| Approach | Example | Maintenance Consideration |
|---|---|---|
|
Static RLS |
A US role permits United States data |
Manage role membership and separate geographic rules |
|
Dynamic RLS |
A manager sees countries listed against their UPN |
Maintain user-country mappings and role membership |
Static roles can suit a few stable audiences. Dynamic RLS can simplify a larger organization where managers oversee different combinations of countries.
The examples below demonstrate both approaches. Treat them as alternatives when assigning users, rather than automatically adding everyone to both.
How Do You Create Security Roles in Power BI Desktop?
Open your report in Power BI Desktop and select Modeling > Manage roles. Create a role, select the relevant table, and define its filter. Use the DAX editor for the expressions below.
Create a Static Country Role
Create a role named US_Sales. Select Geography and enter:
[CountryKey] = "US"This retains the US geography row and filters related stores and sales through the configured relationships. Use the actual country key in your model if it differs from this example.
Save the role and test it before assigning users.
Create a Dynamic Manager Role
Create a separate role named Manager_Dynamic. Select ManagerAccess and enter:
[UserUPN] = USERPRINCIPALNAME()USERPRINCIPALNAME() returns the current user’s principal name. It commonly resembles an email address, but your mapping must match the identity Power BI actually receives.
For [email protected], the rule retains the UK and IT mapping rows. The configured security relationship then limits Geography, Stores, and Sales to those countries.
For an identity absent from ManagerAccess, this rule should permit no sales rows. Test that outcome explicitly. Avoid adding a fallback that grants unrestricted access when a mapping is missing.
With an imported mapping table, source changes must reach the semantic model through refresh before they affect this filtering logic.
How Do You Assign Users to RLS Roles in Power BI Service?
After saving your roles:
- Publish the report and semantic model to the intended workspace.
- In Power BI service, locate the semantic model and open its Security settings.
- Select the role you created.
- Add the intended users or supported groups, then save.
- Confirm those users also have access to the report through the chosen distribution method.
Role membership and report access are separate requirements. Adding someone to an RLS role does not, by itself, distribute the report to them.
Supported RLS group types include Microsoft Entra security groups, distribution groups, and mail-enabled groups. Microsoft 365 groups are not supported for RLS role membership.
External Microsoft Entra B2B guests can use RLS. Validate their returned identity and access with the actual guest account. If guest membership through a security group does not resolve as expected, investigate direct role assignment and the guest’s identity mapping.
Check overlapping assignments: RLS roles are additive. A manager assigned to both a dynamic regional role and a broader static role may see more countries than the mapping alone permits. Review direct assignments and group-based membership together.
How Do You Test Power BI Security Roles Before Sharing Reports?
Start in Desktop with Modeling > View as. Test the static role on its own. For dynamic RLS, select the dynamic role and use the other-user option to enter a sample UPN.
Repeat validation in the Power BI service using Test as a role, then check the report with actual consumer accounts. Simulation has limitations, particularly for external identities. Service role testing is also unavailable for DirectQuery models using single sign-on.
Use a simple test matrix:
| Test Case | Expected Result |
|---|---|
|
Manager mapped to UK and IT |
United Kingdom and Italy sales only. |
|
Manager mapped to US |
United States sales only |
|
User in the dynamic role but absent from the mapping |
No sales data |
|
Manager attempting to view another country |
No unauthorized country data |
|
Actual guest account, if included |
Only its explicitly assigned countries |
Check detail tables, totals, drillthrough pages, and other reports connected to the model. A correct landing page does not establish that every relevant view is correctly restricted.
If identity matching is unclear, temporarily add a card using this measure:
CurrentUserUPN = USERPRINCIPALNAME()Distribute the Validated Report
If you use a workspace app, select Create app, configure its content and audiences, and publish it. For an existing app, update its configuration as needed.
Confirm audience access, model permissions, and RLS assignments together. Retest using the app as a consumer rather than relying on the author’s view.
Why Is Power BI RLS Showing All Data or No Data?
Unexpected results can originate in permissions, identity mapping, or model relationships. Check these before rewriting the filtering expression.
| Symptom | Possible Cause | What to Check |
|---|---|---|
|
A manager sees every country |
Elevated workspace or model permissions |
Review all permission paths, including group membership |
|
A manager sees extra countries |
Membership in additional RLS roles |
Inspect the combined access granted by every assigned role |
|
The report shows no sales |
Missing assignment or mismatched UPN |
Verify role membership and the actual user identity |
|
ManagerAccess filters, but sales do not |
Broken or incorrectly directed security path |
Inspect the active relationships and bridge security setting |
|
A changed assignment has no effect |
Imported mapping data is stale |
Refresh the model and verify the loaded mapping |
|
Desktop tests pass, but the guest gets different results |
Different identity or permissions in the service |
Validate with the actual guest account |
For the regional example, compare the user’s expected countries with the mapping first. Then inspect role membership, permissions, and relationships in that order. Record the failed test and rerun it after the correction.
Need Help Resolving Power BI Access Issues?
Discuss your user mappings, workspace permissions, and model relationships with AlphaBOLD’s Power BI team to identify why report access differs from your requirements.
Request a ConsultationHow Should You Maintain RLS as Your Organization Grows?
Gartner’s January 2026 research on data and analytics governance platforms describes their role in helping organizations design and enforce governance policies throughout the data lifecycle. For Power BI, a practical application of that principle is to make access maintenance part of the operating process.
Assign responsibility for approving access, updating mappings, and removing obsolete permissions. Retest when relationships or roles change, and review access when employees change responsibilities. For imported mappings, include refresh timing in that process.
Document exceptions, such as an executive’s cross-region access, and check report performance under representative roles. The goal is an access model your team can explain, maintain, and verify after the initial deployment.
When Should You Bring in a Power BI Security Specialist?
A regional sales example provides a useful starting point. Your production environment may also involve overlapping responsibilities, external partners, multiple data sources, and access changes across departments. These requirements introduce decisions that a single role-filter expression cannot resolve.
Consider specialist support when the following situations apply:
| Your Situation | What Needs to be Resolved |
|---|---|
|
Managers need access across several regions or business units |
Define approved combinations and prevent overlapping assignments from granting unintended visibility. |
|
Different reports produce inconsistent access results |
Review models, relationships, and permissions to identify where the rules diverge. |
|
Customers or partners need access to reporting |
Plan external identities, sharing permissions, and validation for each audience. |
|
Access changes depend on manual updates by one developer |
Establish ownership and a repeatable process for onboarding, role changes, and departures. |
|
Your team is expanding an existing deployment |
Check whether the security design supports additional users, models, and reporting requirements. |
These issues can delay report rollouts, increase support requests, and make it difficult to explain who has access to sensitive information. Addressing them starts with translating business responsibilities into a clear access design.
Consider specialist support when the following situations apply:
How Can AlphaBOLD Help?
AlphaBOLD’s Power BI consulting services can support the model design, implementation, and troubleshooting behind your reporting environment. Depending on your requirements, that work can include:
- Mapping departments, regions, and user responsibilities to reporting access.
- Reviewing how model relationships and workspace permissions interact with RLS.
- Configuring static or dynamic security for the intended audiences.
- Defining access tests and documenting ongoing maintenance responsibilities.
A useful first conversation starts with three questions: Who needs access? What should each audience see? Where does the current behavior differ? Bring an example of the reporting requirement or access problem so the discussion can focus on the work your environment needs.
Read more: Overcoming Power BI Integration Challenges
Discuss Your Power BI Access Requirements
Whether you are preparing a rollout or resolving inconsistent report access, speak with AlphaBOLD about your security requirements and the implementation support needed to address them.
Request a ConsultationConclusion
Effective Power BI security roles depend on model relationships, role filters, user mappings, and permissions working together. Define the business requirement, choose static or dynamic RLS, and verify both permitted and prohibited access using consumer accounts.
A successful setup also gives your team a repeatable way to handle new users, changing responsibilities, and model updates. That is what keeps reporting access aligned with the business after deployment.
FAQs
No. Workspace Admins, Members, and Contributors have editing permissions and are not restricted by RLS. Use appropriate consumer access for people who should see filtered data. Check underlying semantic model permissions too, because opening a report through an app does not remove existing elevated access.
Yes. Microsoft Entra B2B guests can access appropriately shared reports protected by RLS. Their role assignments, report access, and identity mappings must be configured correctly. Test with the actual guest account, particularly when using dynamic RLS or security groups containing external members.
The roles are additive, so access can expand to include rows permitted by any assigned role. A restrictive role does not cancel access granted by another. Review direct and group-based assignments together and test the combined result against the user’s approved business responsibilities.
Explore Recent Blog Posts
