Free tools Windows power users keep installed
One-click scans. No signup required.
Share a Power BI report only with the people who need it, grant the least access they need, and secure the underlying semantic model separately. Use direct sharing for a defined audience, an app for broader read-only distribution, and workspace roles only for collaborators. Hiding report content does not protect it; use row-level security (RLS) and object-level security (OLS) where data must be restricted.
Choose the sharing method that fits the audience
Power BI offers several ways to distribute a report, but they grant different kinds of access. Choose based on who needs the report and whether they need to read, reshare, build from the model, or edit content.
| Method | Best fit | Permission and security considerations |
|---|---|---|
| Specific people or groups | A defined audience, including named users or groups | Recipients must authenticate with the account granted access. Specific people links can include B2B guests already represented in the tenant. Review link permissions such as Reshare and Build. |
| People in your organization | Internal audiences when forwarding the link within the organization is acceptable | Organization members with the link can view the report. This link type does not work for external or guest users. |
| People with existing access | Sending a convenient URL to users whose access is already established | The link itself does not grant new access. |
| Power BI app | Broader, read-only distribution | Consumers receive access to the report and semantic model. Configure model security rather than relying on the report’s visible layout. |
| Workspace | Collaboration and content creation | Workspace roles can grant broader capabilities than a report link. Give readers who need RLS the Viewer role; do not use authoring roles for consumers. |
| Teams tab or message link | Making a report easier to find in Teams | A Teams tab or message link does not grant Power BI permissions by itself. |
For a bounded audience, start with a specific people or groups option. For wider read-only distribution, consider an app. Use workspace access only when recipients need to collaborate or create content. Before relying on an option, confirm its licensing and tenant prerequisites for your workspace and audience.
Grant only the permissions recipients need
A sharing link that grants access includes at least read permission. In Microsoft’s documented link flow, Reshare is included by default and Build is excluded by default. Remove either permission if the recipient does not need it. Build is significant: it lets a user create reports from the associated semantic model, not merely view the shared report.
#1 Best Overall
To review or clean up access, open Manage permissions for the relevant content and examine direct access, links, and related content. Remove access when it is no longer required. When removing dashboard access, also consider related reports and semantic models; leftover permissions on related items can allow unexpected access.
Secure the semantic model, not just the report
Sharing a report also grants access to its underlying semantic model. A report’s layout is not a security boundary: hiding a table, column, measure, visual, or page changes the experience, but does not prevent access to hidden model content. Microsoft states in its sharing guidance that hiding is a clutter-free presentation option, not a security measure.
- Use RLS to filter which rows a user can see.
- Use OLS to restrict access to tables or columns.
A filtered report link or shared view is not a replacement for either control. Define and test model security for the intended audience.
Workspace roles affect whether RLS applies
RLS applies to workspace Viewers, including Viewers who have Build permission. It does not apply to Admin, Member, or Contributor roles because those roles have edit permission on the semantic model. If RLS must constrain a consumer, assign the Viewer role rather than an authoring role.
Rank #3
Share with external guests carefully
External sharing depends on the Power BI administrator enabling it in tenant settings. The recipient signs in through Microsoft Entra B2B, and access is tied to the identity that received permission. A guest’s identity and group membership may not behave like an employee’s for RLS mapping.
For example, USERPRINCIPALNAME() may return an email-like identifier or a guest UPN in #EXT# format. External membership in Entra security groups may also behave differently across configurations. Match the identity Power BI actually receives to the RLS mapping table and validate the result while signed in as the actual guest.
Protect sensitive content and avoid public links
Microsoft Purview Information Protection sensitivity labels can be applied to Power BI reports, dashboards, semantic models, dataflows, and PBIX files. Label support must be enabled for the tenant, and applying labels has permission and licensing prerequisites. A label is part of information protection; it does not replace recipient permissions or semantic-model security. See Microsoft’s sensitivity-label overview and label application guidance.
Do not use Publish to web for confidential or proprietary reports. Microsoft warns that anyone can access the published report and underlying model data. For internal embedding, Microsoft’s Embed and Embed in SharePoint Online options enforce viewer permissions and data security.
Best Value
Check licensing and tenant requirements
Sharing and consumption requirements depend on the users’ licenses and the workspace’s capacity. Microsoft’s sharing guidance says Pro or PPU is generally required to share unless the content is in qualifying Premium capacity; recipients generally need Pro or PPU unless the content is in Premium or Fabric capacity. It also identifies P SKUs and F64-or-larger capacity for free-license users in certain Viewer or app scenarios.
These conditions vary by scenario and can change. Confirm the current rules, workspace capacity, recipient license, and tenant settings in the target organization before promising that a particular audience can view the content.
Quick Recap
Secure-sharing checklist
- Choose a link, app, or workspace based on audience size and the actions recipients need.
- For direct sharing, name the intended people or groups and require them to sign in with the account that was granted access.
- Remove Reshare and Build if recipients do not need those capabilities.
- Set RLS for row restrictions and OLS for table or column restrictions in the semantic model.
- Use the Viewer workspace role for consumers who must be constrained by RLS.
- For external guests, check tenant settings and test RLS as the actual guest identity.
- Review Manage permissions, including access to related reports and semantic models, and avoid Publish to web for private data.
- Verify applicable licenses and capacity before distributing the report.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
