18  Collaboration & Access Control

NoteManaging Who Can Do What

Publishing a report to the Power BI Service is not the end of the process. Once content is live, you need to control who can view it, who can edit it, who can build new reports on top of the same data, and which datasets your organization trusts enough to treat as official sources. Getting access control right is not just a technical concern. It is a governance responsibility that protects data integrity, prevents unauthorized exposure, and builds organizational trust in Power BI as a platform.

This chapter covers three interconnected access control topics: the fundamental difference between sharing a report and granting workspace access, how to manage dataset permissions and build rights, and how to endorse datasets and reports so consumers know which sources are reliable.

flowchart TD
    A[Power BI Content] --> B{Access Method}
    B --> C[Direct Share <br> Report or Dashboard <br> Read-only link or email <br> No workspace access]
    B --> D[Workspace Access <br> Admin / Member / <br> Contributor / Viewer <br> Access to all content <br> in the workspace]
    B --> E[Dataset Build Permission <br> Can create new reports <br> on this dataset <br> Without workspace access]
    C & D & E --> F[Controlled, Governed <br> Data Access]
    classDef default fill:#004466,color:#ffffff,stroke:#ffcc00,stroke-width:3px,rx:10px,ry:10px;

18.1 Sharing vs. Workspace Access

18.1.1 Sharing vs. Workspace Access: Key Differences

NoteTwo Ways to Give Someone Access

In Power BI, there are two fundamentally different ways to give another person access to your content: direct sharing and workspace membership. They look similar on the surface but operate at very different levels of scope and permission. Choosing the wrong one is one of the most common access control mistakes in Power BI deployments.

Understanding the difference between these two approaches is essential for building a reporting environment that is both collaborative and appropriately controlled.

Direct Sharing

NoteWhat Direct Sharing Does

Direct sharing gives a specific person access to a single, named item: one report or one dashboard. The person receives a link (or is notified by email) and can open that specific item. They do not gain access to the workspace that contains it. They cannot see other reports or datasets in the workspace. They cannot edit the report, modify the data model, or publish new content.

Direct sharing is a deliberate, narrow grant of read access to exactly one piece of content. It is the right choice when:

  • A specific person or a small group needs to view one particular report
  • The recipient should not have visibility into other content in the workspace
  • You want to share content with users outside your team without giving them any workspace-level permissions
  • You are sharing with external stakeholders or occasional consumers who need access to a specific output

[Insert screenshot of the Share dialog in the Power BI Service showing the recipient email field, sharing options, and a note at the bottom indicating the shared item is a specific report, not the entire workspace]

NoteWhat Direct Sharing Does Not Do

It is important to understand the limitations of direct sharing:

  • The recipient cannot see other content in the same workspace, even if it is closely related to the shared report
  • The recipient cannot edit the report unless they are also granted a workspace role with editing permissions
  • If the report is removed from the workspace or moved, the shared link may break
  • Shared access must be managed report by report. If you share ten reports individually, each share must be updated separately if permissions change

[Insert screenshot of the workspace content list showing multiple reports, with a visual indicator or annotation highlighting that a user with only direct share access can see only the one shared report, not the others in the list]

Workspace Access

NoteWhat Workspace Access Does

Workspace membership grants access to the workspace itself, which means the user can see and interact with all content within it, subject to their assigned role. There are four workspace roles, each with progressively broader permissions:

Role View Content Edit Reports Publish Content Manage Members Delete Workspace
Viewer Yes No No No No
Contributor Yes Yes Yes No No
Member Yes Yes Yes Limited No
Admin Yes Yes Yes Yes Yes

Workspace access is the right choice when:

  • A team actively collaborates on building and maintaining reports together
  • Multiple people need to publish, edit, and update content in the same workspace
  • A group of consumers should have access to all content in a workspace as their standard reporting environment
  • You want to manage access at the team or department level rather than item by item

[Insert screenshot of the workspace Access panel in the Power BI Service showing a list of users with their assigned roles (Admin, Member, Contributor, Viewer) and email addresses, with an “Add people” field at the top]

NoteHow to Add Members to a Workspace

To grant workspace access to a user:

  1. Navigate to the workspace in the Power BI Service
  2. Click Access in the workspace toolbar (or go to the workspace settings via the three-dot menu)
  3. In the Access panel, enter the email address or security group name of the person or group you want to add
  4. Select their role from the role dropdown (Admin, Member, Contributor, or Viewer)
  5. Click Add. The user receives an email notification and their workspace access is active immediately

[Insert screenshot of the workspace Access panel with a new user’s email being typed into the Add people field, the role dropdown showing Contributor selected, and the Add button visible]

Choosing Between Sharing and Workspace Access

NoteA Decision Framework

The table below summarizes which access method is appropriate for each scenario.

Scenario Use Direct Share Use Workspace Access
Giving one person access to one report Yes No
Giving an entire team access to all team reports No Yes (Viewer role)
A colleague needs to edit and update reports No Yes (Contributor role)
An external stakeholder needs to view a dashboard Yes No
A new analyst is joining the reporting team No Yes (Contributor or Member)
A manager needs to view reports but never edit Yes (or Viewer role) Either, depending on scope
Sharing with hundreds of users across the organization No (use an App instead) No (use an App instead)
TipUse Apps for Large Audiences

When content needs to reach a large number of consumers (an entire department, the whole organization, or external partners), neither direct sharing nor workspace membership scales well. Direct sharing requires managing individual access grants. Workspace membership exposes all workspace content and allows all viewers to see works in progress. Publishing a Power BI App (covered in Chapter 17) is the right approach for broad distribution: it provides a curated, clean view of exactly the content intended for the audience, with no workspace clutter, and access can be granted to the entire organization or specific security groups in one step.

18.2 Managing Dataset Permissions

18.2.1 Managing Dataset Access and Build Permissions

NoteDatasets Are the Foundation of Multiple Reports

In a well-organized Power BI environment, multiple reports are built on top of the same shared dataset rather than each report maintaining its own independent copy of the data. This shared dataset model reduces data duplication, ensures all reports draw from a single source of truth, and makes scheduled refresh more efficient. But it introduces a new access control question: who should be allowed to connect to a dataset and build new reports on top of it?

Power BI manages this through two separate dataset-level permissions: read access (the ability to query the dataset and see data in reports built on it) and build access (the ability to create new reports and other content using the dataset as a source).

NoteRead Access vs. Build Access

Read access is what a consumer needs to view a report that is connected to a dataset. If you share a report with someone, they automatically get read access to the underlying dataset for the purpose of that report. They cannot, however, use that dataset to build their own reports or explore the data independently in Excel.

Build access grants the additional right to create new Power BI reports, paginated reports, Excel workbooks, and other analytical content using the dataset as the data source. It is the permission that enables self-service analytics: a report builder in another team can connect to your certified dataset and build their own reports without needing to own or copy the underlying data.

[Insert screenshot of the dataset permissions page in the Power BI Service showing a list of users with their permission types (Read, Build, Reshare) listed in columns next to each name, with options to modify or remove permissions]

NoteHow to Grant Build Permissions on a Dataset

To give a user the ability to build new content using a dataset:

  1. Navigate to the workspace containing the dataset
  2. Find the dataset in the content list and click the More options menu (three dots) next to it
  3. Select Manage permissions
  4. The dataset permissions page opens, showing all users who currently have access and their permission level
  5. Click Add user and enter the email address or security group
  6. Check the Build permission checkbox (in addition to Read, which is included automatically)
  7. Optionally check Reshare if the user should also be able to grant others read access to the dataset
  8. Click Grant access

[Insert screenshot of the Manage permissions page for a dataset showing the Add user panel with email input, and checkboxes for Read, Build, and Reshare permissions, with Build checked and the Grant access button visible]

NoteRevoking and Modifying Dataset Permissions

To remove or change a user’s dataset permissions:

  1. Open the dataset’s Manage permissions page (three-dot menu → Manage permissions)
  2. Find the user in the permissions list
  3. Click the three-dot menu next to their name and select Modify access to change their permission level, or Revoke access to remove their access entirely
  4. Confirm the change. The update takes effect immediately

[Insert screenshot of the dataset permissions list showing a user row with the three-dot menu open beside it, displaying the Modify access and Revoke access options]

NoteDataset Permissions and Workspace Roles Interact

It is important to understand how workspace roles and dataset permissions interact. Users with Admin, Member, or Contributor workspace roles automatically have full access (read and build) to all datasets in that workspace. Dataset-level permissions set through Manage permissions apply only to users who are not workspace members, providing a way to extend access to specific datasets without granting full workspace membership.

Specifically: - A workspace Viewer has read access to datasets for viewing reports but does not automatically have build access. Build access must be explicitly granted through Manage permissions - A user who is not a workspace member at all can be granted read-only or read-and-build access to a specific dataset through Manage permissions, without ever seeing the workspace or any other content in it

[Insert screenshot of a diagram or annotated table showing the intersection of workspace roles and dataset permissions, indicating which combinations result in read-only vs. read-and-build access to a dataset]

TipGrant Build Access to Enable Self-Service Analytics

If your organization wants to encourage self-service analytics, the most effective approach is to build and certify a small number of clean, well-documented shared datasets, and then grant Build access to the analysts and report builders across the organization who need to create their own reports. This allows them to build on reliable, governed data without copying it, requesting extracts, or maintaining their own data pipelines. Centralized dataset ownership with distributed build access is the foundation of a scalable Power BI governance model.

18.4 Certified Endorsement

18.4.1 Certified Endorsement

NoteWhat “Certified” Means

The Certified endorsement is the highest level of endorsement and carries significant weight in an organization’s data governance framework. Certified content has been reviewed and formally approved by a designated authority in the organization, confirming that it meets defined quality standards, follows organizational data governance policies, and is safe for broad use across the organization.

Certified content displays a Certified badge (a checkmark or verified ribbon icon) that is immediately recognizable as the most trustworthy source. In the Power BI Desktop dataset connection picker and in the OneLake data hub, certified datasets are prominently featured and recommended over uncertified alternatives.

Unlike Promoted, the Certified endorsement cannot be self-applied. Only users who have been granted the Certify content permission by a Power BI admin can certify datasets, reports, dataflows, and datamarts.

When to use Certified: For the official, organization-wide sources of truth: the canonical Customer dataset, the approved Financial dataset, the standard Date table. These are the datasets that all reports in the organization should reference rather than building their own.

[Insert screenshot of the OneLake data hub in the Power BI Service showing a list of datasets, with a Certified badge (checkmark icon) prominently displayed next to one dataset and a Promoted badge next to another, illustrating how the two levels are visually distinguished]

NoteHow to Certify a Dataset (for Authorized Certifiers)

If you have been granted the Certify content permission by a Power BI admin:

  1. Navigate to the workspace containing the dataset
  2. Click the More options menu (three dots) next to the dataset name
  3. Select Endorse
  4. In the endorsement dialog, select Certified
  5. Optionally add a certification note explaining the basis for certification (the governance standards it meets, the review process it passed, or the team responsible for maintaining it)
  6. Click Apply

The Certified badge appears on the dataset. It is visible across the entire organization in the OneLake data hub, in the Power BI Desktop connection picker, and in search results.

[Insert screenshot of the endorsement dialog with Certified selected, a text field showing a certification note being typed, and the Apply button at the bottom]

NoteHow to Configure Who Can Certify Content

Granting the Certify content permission is an admin-level task:

  1. Sign in to the Power BI Service as an admin and go to the Admin portal (gear icon → Admin portal)
  2. Navigate to Tenant settings
  3. Find the Certification section under Content pack and app settings or the Discovery settings group
  4. Enable the certification feature and specify which security groups or users are authorized to certify content
  5. Only users in the authorized groups will see the Certified option in the endorsement dialog

[Insert screenshot of the Power BI Admin portal Tenant settings page with the Certification setting expanded, showing a toggle to enable it and a security group input field for specifying authorized certifiers]

NoteRemoving or Downgrading Endorsement

To remove or change an endorsement:

  1. Open the endorsement dialog for the item (three-dot menu → Endorse)
  2. Select None to remove all endorsement, or change between Promoted and Certified as appropriate
  3. Click Apply

Removing certification is restricted to the same authorized certifiers who can apply it. Removing the Promoted status can be done by the item owner. Any change to endorsement is logged in the Power BI audit log for governance tracking.

[Insert screenshot of the endorsement dialog showing the None option selected, with a note that selecting None will remove the current endorsement badge, and the Apply button]

TipMake Endorsement Part of Your Data Release Process

Treat endorsement as a formal step in the lifecycle of a dataset or report rather than an optional cosmetic addition. Establish a simple process: datasets are published and tested in an unendorsed state, promoted by their owners when ready for team use, and certified by a governance authority when approved for organization-wide use. Communicate this framework to all Power BI users so they understand what each badge means and can make informed decisions about which datasets to base their work on.

18.5 Bringing Access Control Together

18.5.1 Bringing Access Control Together

NoteA Layered Approach to Governance

Effective Power BI access control is not a single setting but a layered system where each layer serves a different purpose. Direct sharing handles individual, item-level access for specific consumers. Workspace roles handle team-level collaboration for content creators and editors. Dataset build permissions enable self-service analytics without data duplication. Endorsement communicates trustworthiness and guides the entire organization toward authoritative sources.

No single layer is sufficient on its own. A certified dataset with no build permissions granted cannot be used by self-service analysts. A well-configured workspace with no endorsement signals leaves consumers unsure which of the many available datasets to trust. All layers working together create a governance model that is both open enough to encourage data democratization and controlled enough to maintain data quality and security.

ImportantAccess Control Is a Team Responsibility

In most organizations, report builders, dataset owners, and Power BI administrators each play a role in maintaining access control. Report builders manage sharing for the reports they publish. Dataset owners manage build permissions and endorsement for their datasets. Administrators configure tenant-level settings such as who can certify content and which sharing options are available. No single person can maintain a healthy governance model alone. Establish clear ownership, document your access control policies, and review permissions regularly as teams change and content evolves.

Summary

Concept Description
Permissions and Security
Workspace Roles Admin, member, contributor, and viewer permissions
Build Permissions Allowing users to build new reports off shared datasets
Row-Level Security Filters that restrict rows visible to specific users or roles
Object-Level Security Hiding entire tables or columns from specific roles
Sensitivity Labels Microsoft Purview labels applied to Power BI content
Collaboration
Co-Authoring Multiple authors editing the same workspace
Comments and Discussions In-product threads tied to specific visuals or report pages
Audit Trail Activity log capturing user and admin actions across the tenant