Picture this: your analytics team has just finished building a beautifully crafted Power BI solution for the regional sales managers. The executive dashboard is crisp, the regional breakdowns are spot-on, and the forecasting model is genuinely useful. You publish it to your Power BI workspace, share the link with the sales managers, and within 48 hours you get a frantic message from a VP: "Why can anyone on the entire company network see our Q3 pipeline data?" Someone on the IT helpdesk clicked the link out of curiosity and found themselves staring at confidential revenue figures. Worse, three of your analysts who were supposed to see everything can only see the published App — they can't edit a single report.
This scenario plays out constantly in enterprise Power BI deployments, and it almost always traces back to the same root cause: conflating workspace membership with App access, misunderstanding how permission layers interact, and making assumptions about what "sharing" actually does in practice. Power BI's access control system is genuinely powerful, but it has multiple overlapping layers that need to be understood as a system, not as a collection of isolated settings.
By the end of this lesson, you'll understand exactly how workspace roles, App audiences, per-item sharing, and Row-Level Security (RLS) interact with each other, and you'll be able to architect a content access strategy that gives the right people the right access — and absolutely no one else.
What you'll learn:
You should already be comfortable with the Power BI service interface — creating workspaces, publishing reports from Desktop, and navigating the service portal. A basic familiarity with your organization's Azure Active Directory (AAD) / Microsoft Entra ID structure will help, particularly knowing what security groups exist and how users are organized. You don't need to be a DAX or M expert for this lesson, though we will touch on RLS roles which require a small amount of DAX.
Before diving into configuration, you need to internalize one architectural truth that eliminates most access control confusion:
Workspace membership and App access are entirely separate permission systems.
A workspace is a collaboration environment — it's where your team builds, edits, and manages content. An App is a curated, published distribution mechanism — it's how you deliver polished content to business consumers. These two things have completely independent permission models, and mixing them up is the number-one source of enterprise Power BI security problems.
Think of it this way: your workspace is the kitchen, and the App is the restaurant dining room. Your chefs (analysts and developers) need full access to the kitchen. Your diners (business users and executives) should only see the dining room — a carefully curated experience with no access to the prep area. Some people, like managers who want to see how things are made, might get a kitchen tour without being allowed to touch anything.
When you understand that workspace roles and App permissions are configured in completely different places and operate independently, a lot of things that seemed confusing will click into place.
Power BI workspaces have four roles: Admin, Member, Contributor, and Viewer. The official documentation describes them in terms of checkbox capability tables, which is technically accurate but not particularly useful for deciding what to assign in practice. Let's talk about what these roles mean for real people doing real jobs.
Admins have complete control over the workspace. They can add and remove members (including other admins), update workspace settings, delete the workspace, and publish Apps. In a production environment, you should have at minimum two admins per workspace — one being a service account or team alias — because if the sole admin leaves the organization, you can lose administrative access entirely.
Who gets this: Workspace owners, team leads responsible for the analytics solution, and your Power BI service account.
Members can do almost everything an admin can do except manage other admins or delete the workspace. Critically, they can publish and update Apps, share content, and manage permissions for datasets. This is more trust than most people realize they're granting.
Who gets this: Senior analysts who are actively developing the solution and need to publish App updates. Be careful here — anyone with Member rights can publish an App update and potentially change what business users see.
Contributors can create, edit, and delete content in the workspace — reports, dashboards, dataflows — but they cannot publish Apps or manage workspace membership. This is your typical analyst role.
Who gets this: Analysts and developers actively building reports. A contractor or new team member building out report pages should be a Contributor, not a Member.
Viewers can read content directly in the workspace but cannot edit anything. This is an often-misunderstood role. Workspace Viewers are seeing the raw workspace content — they can browse the workspace's reports list, open individual reports, and see dataset names. They are not seeing a curated App experience. They can also, if they know the URL, potentially see reports you haven't finished yet.
Who gets this: Internal stakeholders who need to monitor content but shouldn't edit it — perhaps a data governance officer who needs to audit what reports exist. Not for general business users, who should use Apps instead.
Important warning: Do not add business users as Workspace Viewers as a shortcut for giving them report access. This bypasses the App curation model entirely, exposes your development workspace to end users, and means they may see draft reports, half-finished dashboards, or internal documentation you didn't intend to share. Use Apps for distribution.
In any organization with more than ten people touching Power BI, you should be assigning workspace roles to Microsoft Entra security groups, not individual users. Here's why this matters in practice:
When you add individual users to workspace roles, every time someone joins or leaves your analytics team, you're doing manual permission management across potentially dozens of workspaces. When you use security groups, the group membership is managed in Active Directory, and the Power BI permissions follow automatically.
To add a group to your workspace, go to the workspace in the Power BI service, select "Workspace settings" (the gear icon in the top right area of the workspace), then choose "Access." In the access panel, type the name of your security group in the "Add people or groups" field, select the appropriate role from the dropdown, and click Add.
A practical group structure for most enterprise teams looks like this:
sg-pbi-[workspacename]-admins — Two or three people maximumsg-pbi-[workspacename]-developers — Your analytics team, assigned as Contributorssg-pbi-[workspacename]-publishers — Senior analysts who need to publish Apps, assigned as MembersAn App is a published, curated version of workspace content. When you publish an App from a workspace, you're essentially saying: "Take these specific reports and dashboards, arrange them in this navigation structure, and make them available to these specific audiences." The underlying workspace continues to exist independently — your team can keep editing, and changes only become visible to App users when you explicitly republish.
This is enormously valuable in production. You can be actively developing next quarter's dashboard while this quarter's version is live in the App, and business users see no disruption.
To publish an App, navigate to your workspace and find the "Create app" button in the top navigation bar. If you don't see it, you're either a Contributor (who lacks publishing rights) or you need to check workspace settings.
The App publishing interface has three main tabs: Setup, Navigation, and Permissions.
Setup is where you define the App's name, description, and branding. The App name is what users will search for in the Power BI Apps marketplace, so make it meaningful — "Contoso Sales Analytics" rather than "Sales WS App."
Navigation is where you curate the content. Not everything in your workspace has to appear in the App. You can choose which reports and dashboards to include, rename them with business-friendly names (your internal file might be called rev_fcst_v3_FINAL_use_this_one.pbix, but you can display it as "Revenue Forecast"), and organize them into sections. Sections appear as expandable groups in the left navigation panel when users open the App.
Permissions is where the real access control work happens, and it's the tab most people under-invest in.
The Permissions tab is where you specify who can access your App. You have several options:
Entire organization — everyone in your Azure AD tenant can access the App. This sounds convenient and is the source of the pipeline data incident described in the introduction. Only use this for genuinely organization-wide content like a company KPI dashboard or an employee directory.
Specific individuals and groups — you enter specific users or security groups. This is the correct approach for almost all enterprise scenarios.
Allow users to share the App — this checkbox controls whether App recipients can reshare the App with others. In most enterprise scenarios, you should leave this unchecked. If a finance analyst can reshare the CFO dashboard to anyone they want, your access controls have a large hole in them.
Allow users to build content with the underlying datasets — this is critically important. When checked, App recipients can use the datasets powering the App to build their own reports in their own workspaces. This is the right setting for self-service analytics cultures where power users are expected to build on your certified datasets. When unchecked, users can only consume what you've published. Make this decision deliberately.
This is where Power BI Apps go from a distribution tool to a genuine enterprise access control mechanism. Multiple audiences let you serve different versions of your App content to different user groups — all from a single workspace and a single published App.
Let's use a concrete scenario. Your company has a Sales Analytics workspace containing:
Different groups need different access:
Before multiple audiences, you'd either build separate Apps (multiplying your maintenance burden) or give everyone the same access (violating least-privilege). Multiple audiences solve this elegantly.
In the App publishing interface under the Permissions tab, you'll see an "Add audience" button. Each audience is a named configuration with its own:
Click "Add audience" to create your first named audience. Give it a meaningful name — "Executive Leadership" or "Regional Managers" rather than "Audience 1."
After naming the audience, you assign users or groups to it. Then — and this is the key step — you go back to the Navigation tab and notice that the content visibility controls now have an audience context. For each piece of content in your navigation structure, you can toggle visibility per audience. A report that's included for Sales Operations might be hidden entirely for Individual Sales Reps.
Here's how the audience configuration for our sales scenario would look:
Audience: Executive Leadership
sg-exec-leadership, sg-evp-salesAudience: Regional Managers
sg-regional-managersAudience: Sales Operations
sg-sales-opsAudience: Sales Reps
sg-sales-reps-allTip: If a user belongs to multiple security groups that map to multiple App audiences, Power BI uses the most permissive audience they qualify for. Design your group memberships with this in mind — a Regional Manager who's also in the exec leadership group will see content from whichever audience grants more access.
After configuring audiences and permissions, click "Publish app." Power BI validates your configuration and publishes the App. Users in assigned audiences will receive the App in their Power BI Apps section, and depending on your organization's settings, they may receive an email notification.
When you need to update the App — say, you've added a new report page or fixed a data issue — you make changes in the workspace and then return to the App publishing interface and click "Update app." Users see the updated content immediately after the update completes. This is why the workspace/App separation is so valuable: your iteration cycle doesn't disrupt the published experience.
Beyond workspace roles and Apps, Power BI allows sharing individual reports, dashboards, and datasets with specific users. Understanding when this is appropriate versus when it's a security smell is important.
You can share a specific report by opening it in the Power BI service and clicking the Share button. This generates a sharing link or allows you to enter specific users. The recipient gets access to that report and, by default, the underlying dataset required to view it.
Per-item sharing is appropriate in specific situations:
Ad-hoc, short-term sharing: A finance analyst needs to share a one-time analysis with a stakeholder who shouldn't be part of the ongoing App distribution. Share the specific report, set an expiration if your licensing allows it, and revoke when done.
External sharing with guests: When sharing with Azure AD B2B guests (external partners or clients), per-item sharing is sometimes cleaner than adding them to App audiences, depending on your tenant's external sharing policies.
Sharing a single dataset for self-service: A certified dataset owner might directly share the dataset with power users to enable report building, bypassing the need for full workspace access.
Per-item sharing becomes a security problem when it's used as the primary distribution mechanism for ongoing content. Here's why:
When you use per-item sharing at scale, you end up with a permission sprawl that's nearly impossible to audit. If you need to remove access for a terminated employee, you might be revoking dozens of individual share links across multiple reports rather than removing them from a single security group. The permission structure also lives in the report itself, not in a central administration location, making governance reviews painful.
Warning: When you share a report using "Allow recipients to share this report" (which is enabled by default), you've created a permission chain you have no visibility into. A recipient can share to someone else, who can share to someone else. Unless you have a policy and technical control against this, use per-item sharing for read-only access and uncheck resharing by default.
For reports that have been shared, you can see the full sharing list by opening the report and going to the Manage permissions option (accessed via the "..." menu on the report in the workspace view). This shows you every individual user and link type that has access to the item — a useful audit tool, but one that quickly becomes overwhelming if sharing has been used indiscriminately.
Everything we've discussed so far controls whether users can see a report. Row-Level Security (RLS) controls what data within that report a user can see. For the sales scenario described above, RLS is what ensures that the Western Region manager sees only Western Region data even though she's accessing the same Regional Detail Report as the Eastern Region manager.
RLS is configured in Power BI Desktop before publishing. Open your PBIX file, go to the Modeling ribbon, and select "Manage roles."
In the Manage roles dialog, you create named roles and write DAX filter expressions that restrict what rows are visible. The filter expressions are applied to a specific table in your data model, and the filter propagates through relationships automatically.
For our sales scenario, assume your data model has a DimSalesRep table with a Region column, and your FactSales table has a relationship to DimSalesRep. Here's a role that uses dynamic RLS:
-- Role: RegionalAccess
-- Applied to: DimSalesRep table
[Email] = USERPRINCIPALNAME()
This single expression filters the DimSalesRep table to show only the row where the Email column matches the logged-in user's principal name. Because FactSales has a relationship to DimSalesRep, all sales data flows through that filter — the regional manager only sees data for sales reps in their region, assuming the data model properly associates reps to regions.
For a region-based filter where you want all managers in a region to see all reps in that region (not just themselves), you'd need a separate mapping. Assume a RegionAccess table that maps user emails to the regions they can access:
-- Role: RegionalManagerAccess
-- Applied to: DimRegion table
[RegionName] IN
CALCULATETABLE(
VALUES(RegionAccess[RegionName]),
RegionAccess[ManagerEmail] = USERPRINCIPALNAME()
)
This approach — using a security mapping table — is the most flexible and maintainable pattern for enterprise RLS. Your data team can update the RegionAccess table in the data source when managers change, without needing to republish the PBIX file.
After publishing to the Power BI service, you need to assign users or groups to your RLS roles. Navigate to the dataset in your workspace (not the report — the dataset), click the "..." menu, and select "Security." Here you'll see your defined roles and can add users or groups to each one.
For the RegionalManagerAccess role, you'd add your sg-regional-managers security group. Every user in that group will have the RLS filter applied when they access the report.
Critical point: RLS only applies to users who access the report via a role. Workspace Admins, Members, and Contributors bypass RLS entirely — they see all data. This is intentional (developers need to see everything to build and test), but it's a significant security implication. Your Workspace Members should be your trusted team members only, and your business users should access content through the App (which respects RLS).
Power BI Desktop has a "View as" feature in the Modeling ribbon that lets you preview what a specific role or user would see. Use this rigorously before publishing — confirm that the regional manager persona sees only their region's data, and that an executive persona (which won't be assigned an RLS role) sees everything.
In the Power BI service, you can also test RLS by navigating to the dataset security settings and clicking "Test as role" to verify the filter behavior in the published environment.
Setting up access control correctly at deployment time is only half the battle. Enterprise Power BI environments drift over time — people change roles, teams restructure, and new reports get created. A permission model that was correct six months ago may have significant gaps today.
Schedule quarterly access reviews for your workspace roles. The Power BI Admin portal provides usage metrics and access information, but for a structured review, the most reliable approach is to use the Power BI REST API or PowerShell to extract workspace membership:
# Install the Power BI Management module if needed
# Install-Module -Name MicrosoftPowerBIMgmt
Connect-PowerBIServiceAccount
# Get all workspaces
$workspaces = Get-PowerBIWorkspace -Scope Organization -All
# For a specific workspace, get users
$targetWorkspace = $workspaces | Where-Object { $_.Name -eq "Contoso Sales Analytics" }
Get-PowerBIWorkspace -Id $targetWorkspace.Id -Scope Organization | Select-Object -ExpandProperty Users
Run this output against your HR system's active employee list. Any user who's left the organization or changed departments should trigger an access review.
App permissions aren't as easily extracted via standard PowerShell cmdlets as workspace memberships, but the Power BI Admin portal does expose App usage metrics. Go to the Admin portal (gear icon in Power BI service, then Admin portal), navigate to "Usage metrics," and review which Apps are being accessed and by whom. Sudden drops in App access can indicate permission issues; unexpected new users can indicate that resharing occurred without authorization.
If your organization has Microsoft Purview Information Protection configured, Power BI supports sensitivity labels on workspaces, reports, datasets, and dataflows. A sensitivity label like "Confidential - Finance" can enforce encryption, restrict external sharing, and appear as a watermark on exported content. Configuring sensitivity labels is an admin-level task, but as a workspace owner, you should be applying appropriate labels to your content consistently.
This exercise walks you through building a secure, multi-audience content distribution setup for a realistic business scenario. You'll need a Power BI Pro or Premium Per User license and access to a Power BI workspace where you have Admin rights.
Scenario: You're the Power BI lead for Northwind Logistics. You have three reports in your workspace:
Your user groups:
sg-nw-executives — should see executive KPI onlysg-nw-regional-ops — should see executive KPI and regional operationssg-nw-internal-ops — should see all threeStep 1: Create your workspace role assignments Open workspace settings and verify that your development team members are assigned as Contributors, not Members. Remove any business user accounts from workspace roles entirely.
Step 2: Create three sample reports
If you don't have real data handy, connect to the built-in Power BI sample datasets (Retail Analysis Sample or Sales & Returns). Create three separate reports representing the three categories above. Name them clearly: Executive KPI, Regional Operations, Internal Metrics.
Step 3: Publish your App with multiple audiences Click "Create app." In the Setup tab, name it "Northwind Logistics Analytics."
In the Navigation tab, add all three reports to the navigation structure with clean business names.
In the Permissions tab, click "Add audience" three times:
sg-nw-executives. Go to Navigation and for this audience, disable visibility on "Regional Operations" and "Internal Metrics."sg-nw-regional-ops. Disable visibility on "Internal Metrics" only.sg-nw-internal-ops. All reports visible.Step 4: Publish and verify Publish the App. Open an InPrivate/Incognito browser window and log in as a test user from each group. Verify that each persona sees only the reports you intended. This is the most important step — never trust configuration without verification.
Step 5: Add RLS to the Regional Operations report
Go back to your Power BI Desktop file for the Regional Operations report. In Manage roles, create a role called RegionalFilter with a DAX expression that filters the region table to the user's assigned region (using a RegionAccess mapping table if your data supports it, or a USERPRINCIPALNAME() match if not). Republish, assign the sg-nw-regional-ops group to the RegionalFilter role in the dataset security settings, and re-verify using the "View as" feature.
This almost always means an analyst has been given access to the App but not to the underlying dataset. If Build permission wasn't granted in the App audience settings, analysts trying to create their own reports on top of the dataset will be blocked. Go to the dataset in the workspace, select "Manage permissions," and grant Build access to the relevant group.
Check whether the user is actually in the assigned security group. Group membership changes can take up to an hour to propagate in Azure AD. Also confirm that the audience has at least one navigation item with visibility enabled — an audience with all items hidden is functionally an empty App.
The most common cause: the user accessing the report is a workspace Admin, Member, or Contributor. These roles bypass RLS. To test RLS behavior for business users, use the "View as" feature in Desktop, or use a test account that has only App access with no workspace role. Also verify the user is assigned to an RLS role in the dataset security settings — just defining the role in Desktop isn't enough.
Workspace permission changes propagate relatively quickly (minutes), but App audience changes require a republish of the App. If you add a new user to an audience but don't republish, they won't see the new access. Always republish the App after changing audience configurations.
Check three places: workspace roles (are they a Viewer?), direct item shares (did someone share the report or dataset directly to them?), and App audience membership (is there a group they belong to that grants broader access than intended?). The Manage Permissions view on the specific report will show all access vectors in one place.
This is a tenant-level setting issue. If your Power BI tenant has external sharing enabled broadly, and you published the App to "Entire organization" or forgot to restrict resharing, external users with guest access may be able to reach your content. Work with your Power BI administrator to review tenant-level sharing policies and ensure App permissions use explicit group assignments rather than the entire-organization option.
You now understand Power BI's access control model as an interconnected system rather than a collection of isolated settings. The key principles to carry forward:
Workspace roles are for builders, not consumers. Use Admin, Member, Contributor, and Viewer roles for your analytics team. Business users should never have workspace roles — that's what Apps are for.
Apps are your distribution layer. Publish curated, business-friendly experiences through Apps. Use multiple audiences to serve different content subsets to different groups from a single workspace.
Per-item sharing is a scalpel, not a hammer. Use it for specific, time-bound, or exceptional situations. Never use it as your primary distribution mechanism.
RLS controls data, not content. Row-Level Security is what limits which rows a user sees within a report. It layers on top of everything else and is essential for multi-region, multi-business-unit, or role-sensitive datasets.
Always verify with test personas. Configuration is not the same as correct configuration. After any access change, test with an account that represents the actual user experience.
Learning Path: Getting Started with Power BI