Power BI implementation planning: Content distribution and sharing

This article helps you to plan the distribution and sharing of content in Power BI and Fabric. It's primarily targeted at:

• Fabric administrators: The administrators who are responsible for overseeing Fabric in the organization. Fabric administrators manage administration settings that impact how creators can distribute and share content in their organization. Fabric administrators can collaborate with other administrators to control the options available for creators to share their content.
• Azure administrators: The administrators who are responsible for overseeing identity management in the organization and creating external guest users to enable Microsoft Entra B2B.
• Center of Excellence (COE), IT, and BI teams: The teams that are responsible for overseeing Power BI in the organization. These teams are responsible for defining and promoting a specific content distribution strategy.
• Content owners and creators: The teams and individuals that champion analytics in a team or department and that make and distribute Power BI or Fabric content. Content owners and creators should collaborate with Azure administrators to distribute or share content to external users.

Once you create content like semantic models or reports, you'll usually want to share it with other users in your organization so that they can use it to inform their decisions and actions. There are many different approaches that you can take to share Power BI and Fabric content, and each approach has its benefits and considerations. It's important to take care because oversharing of content is a common governance and security challenge for organizations. To overcome this challenge and grant people access to the data and reports that they need, it's important that you implement a content distribution strategy that fits your needs and scenarios.

This article guides you to determine your approach to distribute content to both content consumers and other content creators.

• Content consumers: Users who view content but don't create or share new items. These users typically have Read permission for reports, but more advanced content consumers might also request Build permission to perform ad hoc analysis on data items in personal BI usage scenarios.
• Content creators: Enterprise or self-service users who create and distribute content to consumers. These creators often use existing items created by other users in the organization to make new content, for example in managed or customizable managed self-service BI usage scenarios.

Set roles and manage permissions

You share content with consumers or creators by granting them access to that content. To grant access to users and groups, you set their roles and manage their permissions.

• Roles apply certain permissions to all content within a particular scope. For example, the Viewer workspace role applies read-only permission to all content within the workspace.
• Permissions define what an individual can do with that content. For example, applying Build permission to a semantic model allows a user to connect to and create reports based on the semantic model.

The following diagram shows where you can set roles and permissions in Power BI and Fabric.

The diagram depicts the following concepts and processes.

Item	Description
	You can share content in workspaces by assigning users and groups to workspace roles. Workspace roles can grant permissions to all items within the workspace.
	You can share content from an app by adding people to app audiences, or by creating an app that shares content with the entire organization. • An app audience member will receive read-only permission to view content only in the app (and can't view individual items in the underlying workspace). • You can grant Build permissions to app audience members for the underlying semantic models of app reports and dashboards.
	You can grant access to individual items by providing direct access and setting specific permissions. Some items (like dataflows) don't support sharing by direct access. For these items, you share them via workspace roles.
	Reports have more options. For instance, you can provide direct access with a link that works for specific users and groups, or with a link for the entire organization. Links work for specific distribution methods, like embedding in SharePoint Online or securely embedding in an internal webpage. This article provides an overview of all possible methods later in this article.
	It's possible to distribute Power BI reports without setting roles or managing permissions for users and groups. • You might choose to share Power BI reports by embedding them in a custom website or application. In this case, you manage custom authentication yourself. Embedding content in this way requires an F, P, EM, or A SKU. • You can also share reports publicly by using Publish to web, which is a Power BI feature that makes content available to anyone through the public internet.

Set roles for workspaces or apps

As depicted in the previous diagram, you can share a collection of content by assigning people to roles in workspaces or apps. A workspace is a collaborative location to publish and organize content, while an app is a selection of reporting content that you organize and distribute to audiences.

• Workspace roles control whether a user can manage workspaces, content, and connected apps (Admin, Member, or Contributor), or only view content in that workspace (Viewer).
• App audiences control which content is visible in an app to a user or group. You can also publish an app to your entire organization.

Other supporting roles for content distribution or sharing

There are other roles that don't directly affect how you share content, but which you can use to support content distribution and sharing in certain circumstances.

• Data source connection roles control whether a user can use a data source connection of a data gateway. If a DirectQuery semantic model uses DirectQuery with single sign-on (SSO), then you must add a user or group as a User role so that they can use the semantic model or view reports. You might also decide to assign creators to a data gateway role so that they can add and manage their own data source connections.
• Data security roles control what data people can access in the semantic model. If a semantic model has a data security role, then you must add a user or group to that role before you share the model or any connected reports and dashboards.
• OneLake data access roles control what data people can access in a lakehouse. If you want to share only a subset of data in a lakehouse, you must add a user or group to the OneLake data access role after you grant the appropriate lakehouse Read permission.
• Deployment pipeline roles control who can deploy content between workspaces. While deployment pipelines aren't directly related to content distribution and sharing, how you decide to deploy content and who deploys it might affect your strategy to share content with creators.

Manage item permissions

When you share content via workspace roles or app audiences, you apply certain permissions to a set of content. These permissions define what an individual can do with the content. For example, if you assign someone to the Viewer workspace role, they get Read permission on all items in that workspace, which means that they can only view that content, but not modify it or connect to data items to create their own content.

You can also share content by managing permissions to individual content items. For example, if you manage permissions of a semantic model, you can grant someone Build permission to connect to and create their own content based on that semantic model. When you share a content item via direct access, you're granting certain permissions to that item for a user or group.

You can assign users to the following permissions for Power BI or Fabric items.

• Read-only (view) permission: Let someone see the content without modifying it. Some items, like lakehouses, allow more granular control of how users can view the content (like ReadData or ReadAll permissions). Other items, like semantic models, allow users to see information about the item, but not view its contents (like the data).
• Reshare permission: Let someone share the content with others. If someone has both Reshare and Build permissions, they can also grant Build permission to someone else.
• Build permission: Let someone connect to the data item (like a semantic model) to create their own content (like reports). Consumers might also need Build permission to view reports based on composite semantic models. If you grant Build permission to a report or app audience, it will automatically apply to the underlying semantic models.
• Write (modify) permission: Let someone modify an item and save their changes.

The remainder of this article guides you to make decisions about which roles and permissions you should give to content consumers and creators to share content with them.

Plan to distribute content to consumers

Most people who use content in your organization will only need to view it (Read permission) and not change it (Write permission), or create their own content based on it (Build permission). Content consumers are typically business users who need to access reporting items (in which case they're often called report consumers). Some users might also need to request Build permission for data items to enable their own data discovery in Power BI Desktop, Excel, or other client tools.

Content consumers can be either internal or external to the organization, depending on whether they have a Microsoft Entra identity in the same organization as where you publish the content.

• Internal users: Users who belong to the same organization as the content that they consume.
• External users: Users who belong to a different organization as the content that they consume. These users can belong to an affiliate or subsidiary organization, despite sharing the same parent organization. They can also be temporary collaborators (like consultants) or customers.

The following diagram presents an overview of the different approaches that you can take to distribute Power BI or Fabric content to consumers inside or outside your organization.

The diagram depicts the following concepts and processes.

Item	Description
	Content creators create and deploy content in their organization. They can distribute content to other internal users who use Fabric (such as the Fabric portal or the Power BI mobile app). Creators can also share reporting items by embedding them in other internal, non-Fabric services.
	Creators can also share items outside the organization. They can distribute content to external guest users who have been added to the organization with Microsoft Entra B2B. Creators can also share reporting items to external users.
	Content is deployed in a Fabric tenant, where consumers can use or view it.
	Fabric capacity is required to create and share Fabric items. If there isn't a Fabric capacity, creators can still create, deploy, and share Power BI items (like dataflows, semantic models, and reports).
	Content is deployed to a workspace, which can contain different items that might be organized into folders. Workspaces can belong to deployment pipelines and domains (not depicted in this diagram).
	Creators can share content to internal users or external guest users who are content consumers by assigning them to the Viewer workspace role. This role grants read-only access to all content in the workspace.
	Creators can share individual items to internal users or groups by providing direct access or sharing a link. People who use the link in the organization who don't have direct access can request it. Creators who share content via links can also modify the URL to filter the report by using query string parameters.
	Selected reporting items in a workspace can be packaged into an app.
	Creators can distribute content via apps by creating and adding internal or external guest users who are content consumers to one or more app audiences. Creators can choose to organize app content into audiences, with each audience having access to different subsets of content.
	Creators might store content files—like Power BI Desktop (.pbix) files—in SharePoint or OneDrive for Work or School.
	Creators can share a link to .pbix files from SharePoint or OneDrive for Work or School. When an internal user has a Power BI Pro license, they can preview the reports from these files without opening them (even when the files aren't published to a workspace). Recipients of the link who don't have access or a Power BI Pro license can't preview the files.
	Creators can share reporting items via direct access by using non-Fabric experiences. They can: • Embed content in Microsoft Teams (as a tab in a chat or team channel). • Embed content in a PowerPoint presentation. • Embed content in SharePoint Online. • Embed content in a PowerApps canvas app (which requires PowerApps licenses, but not an F, P, A, or EM SKU). • Embed content in an internal website (also known as secure embed). • Embed content in an internal application (also known as Embed for your organization, which requires an F, P, A, or EM SKU). • Report subscriptions and paginated report subscriptions, which provide scheduled delivery of static reports via email. You can also use regular subscriptions and dynamic per recipient subscriptions for both reports and paginated reports. • Export to file API (such as by using Power Automate to deliver exported reports via email).
	Creators also have various options to share reporting items to external users outside Fabric. They can: • Embed content securely in an external website (requires an F, P, A, or EM SKU). • Embed content securely in an external application (also known as Embed for your customers). • Publish to web for reports, which makes content available to anyone through the public internet. Publish to web is recommended only for content that's suitable for a public audience. Publish to web isn't suitable for sensitive or confidential reports. For more information, see Publish to web from Power BI.

The following sections describe the steps you take to determine your approach to sharing content with consumers.

Step 1: Identify who consumers are and how they get access

The first step when distributing content to consumers is to identify who will need access to what content. Depending on the number and type of consumers, you'll make different choices about how you distribute content.

Investigate and document answers to the following questions.

• How many consumers are there?
• What content do these consumers need access to?
• Do consumers need access to data gateway data source connections to view content that uses DirectQuery mode to query on-premises or private network data sources?

Generally, you can choose to either proactively distribute content, set up processes for users to request access themselves, or provision organization-wide access for all users.

The following sections help you to determine which is the better option for your circumstances.

Option 1: You distribute content to consumers

You can proactively distribute content to consumers, then notify them about the content and how they can access it. With this approach, you gather a list of all the consumers and assign them to a distribution group, mail-enabled group, or security group to facilitate sharing the content. You can then announce the content availability via a centralized portal or another method of communication.

This approach is beneficial when:

• You need to distribute content to a defined, large audience, like an entire department or region.
• You want tighter control of content access and releases, such as when you want to conduct user training for an app or report before providing access.
• You haven't yet set up processes for consumers to discover content.
• You use a centralized model of content ownership and delivery.

Option 2: Consumers request access to content

You can also take a discovery-driven approach, where consumers search for content that's relevant for them. With this approach, consumers browse a curated centralized portal for the content that's available to them. When they select an item that they don't have access to, they can request access from the content owner, who must approve it before the content consumer can view that item.

This approach is beneficial when:

• You curate a centralized list of content for users to explore and access, such as one maintained on a Microsoft Teams channel or SharePoint site.
• You have processes in place for content owners to quickly and reliably respond to access requests.
• There are many possible items that users might want to view, depending on their current tasks and objectives.
• You use a decentralized model of content ownership and content delivery scope.

Option 3: The entire organization can access the content

Some content might be relevant to the entire organization, like reports about organization-wide initiatives. With this approach, you share content either via apps or direct access, where the entire organization can access content in an app or by a link.

This approach is beneficial when:

• Content and the underlying data are suitable for the entire organization.
• You have processes in place for content consumers to find and understand this content, such as training, office hours, or frequently asked questions (FAQ) pages.

Step 2: Identify where consumers will view the content

Once you've defined who the consumers are and how they should get access to content, you then identify where these individuals will view the content.

Consumers can view content in four different ways, specifically by using:

• Links to the individual content items.
• Workspaces.
• Apps.
• Non-Fabric experiences, like where content is embedded in other services, custom apps, or websites.

The following sections help you to determine which is the better option for your circumstances.

Option 1: View individual content items in Fabric

You can give consumers access to individual content items, which they can access via a link. When you share content this way (called direct access), you can also give consumers the ability to reshare the content with others or build content based on the underlying data items. If someone who receives the link doesn't have access to the item, they will be prompted to request access from the original content owner.

This approach is beneficial when:

• You share content to a limited audience, rather than distributing it to a wide audience.
• Consumers need access to only a few items.
• You want to later embed that content in another internal service or website.
• You want to provide users with a collection of links to different content.

When you share individual content items, consider the following points.

• Use endorsements to help consumers find and request access to quality content.
• Audit and monitor published items to identify overshared or underutilized items to review.
• Create a process to regularly review pending access requests. Ensure that feedback is provided to users when their access request is denied. It should explain the reason, and tell them where they might find alternative information.

Option 2: View content in a workspace

You can distribute content via workspaces. With this approach, you grant read-only access to consumers to workspace content by adding them to the Viewer role. Viewers can't modify the content or create new content from the items in the workspace. Instead, you distribute a link to the workspace that lets them browse and open the individual content items.

This approach is beneficial when:

• Consumers prefer the workspace experience over the app experience.
• You separate workspaces by item type and have only reporting items in the workspace.
• You want to give users the ability to view data items in a workspace and request Build permission.
• You want the content reviewed prior to publishing an app.

When you plan to distribute content to workspace viewers, consider the following points.

• Organize workspace items into folders. Workspace organization makes it easier for consumers to find what they're looking for.
• Place content not meant for direct consumption in other workspaces. Separating workspaces by item type ensures that consumers won't be confused or overwhelmed by items that aren't for them to use.
• Regularly audit workspace role membership. Monitoring role membership helps to avoid situations where a consumer is mistakenly granted elevated permissions.

Option 3: View content in an app

You can distribute content via apps, which bundle related content in a straightforward user interface that streamlines the experience for content consumers. Unlike viewing content in workspaces, apps don't confuse or overwhelm consumers by showing non-reporting items (like semantic models). Additionally, when you distribute content via apps, there's no risk of accidentally giving consumers Write permission. Apps require you to share content by adding consumers to an app audience. It's also possible to share an app with the entire organization.

This approach is beneficial when:

• You want to distribute multiple workspace items (but not all items) to consumers.
• You need to distribute content from a single workspace to many consumers.
• You want to give different consumers access to different subsets of app content.

When you share content in an app, consider the following points.

• Organize content into folders so that it's easier for consumers to find what they're looking for.
• Add links to the app for users to request support, report issues, or provide feedback.
• Include a useful app description and contact person so that users know what the app is about.
• When reports use shared semantic models, which are located in other workspaces, ensure that consumers have Read permission for those semantic models so they can view reports in the app.

Option 4: View content from other services

You have various options to distribute content for consumers in your organization outside Fabric. In this situation, content consumers view the content from other applications and services.

This approach is beneficial when:

• Consumers intend to use the content alongside, or together with, other applications.
• You require other services or applications to deliver the best experience for consumers.
• You want to provide convenient access to content spread across multiple workspaces (such as from a SharePoint Online or internal website portal).

Additionally, each approach has specific use cases that they can support.

• Embed in Microsoft Teams: This option can be beneficial when you use Power BI reports to help coordinate project or other collaborative work.
• Embed in PowerPoint: This option can be beneficial when you want to integrate Power BI reports in your presentations or display multiple reports continuously on a screen (such as reports that show incidents or open orders in a manufacturing plant).
• Embed in SharePoint Online: This option can be beneficial when you want to centralize reports in a SharePoint site to enable collaborative work, or when SharePoint is the preferred way to distribute and manage access to different kinds of content in the organization.
• Embed in Power Apps canvas apps: This option can be beneficial when you want Power BI content to inform user decisions and actions in an app built with Power Apps. For example, you might have an app for registering seats in an open office, and a Power BI report that shows data about seat availability and office occupancy. However, Power Apps requires licenses for both creators and consumers.
• Embed in an internal website or external application: This option can be beneficial when you want to integrate Power BI reports with other custom developed content. However, this approach requires more development effort. When done for an internal website, you can use the For your organization embedding approach. When done for an external application, you can use the For your customers embedding approach, and it will require either Fabric capacity (F SKU) or Power BI Embedded (EM SKU).
• Report subscriptions: This option lets you subscribe consumers to reports and paginated reports, which can deliver static reports by email or to a SharePoint site on a schedule. Additionally, for reports, subscriptions have the benefit of notifying consumers when the data in the underlying semantic model is refreshed. This approach is best combined with other methods, like sharing content from an app. That way, consumers know only to check the app once the content inside is updated.
• Export to file API: This option enables limited scenarios when you want to distribute static versions of reports as a PDF document (.pdf) or PowerPoint (.pptx) file.

Step 3: Identify whether consumers are outside the organization

In some cases, you might need to distribute content to external consumers. In this case, you have several options to distribute content outside the organization.

Option 1: Create duplicate identities for external consumers

In this approach, you create duplicate identities for external consumers that become internal consumers. An Azure administrator creates a new account for the external consumer in the tenant that they must use to access that content. Then, a Microsoft 365 administrator allocates the appropriate per-user licenses to the new identity for them to access content. While this option is the simplest, it involves overhead and cost to create and manage new accounts.

This approach is beneficial when:

• Limitations of Microsoft Entra B2B prevent you from doing what you need to do. Examples of limitations of Microsoft Entra B2B for consumers include:
  • External guest users might not be able to open files exported from reports that have a sensitivity label with protection settings.
  • External guest users can't use Power BI Desktop to connect to semantic models or dataflows that are in the Power BI service.
  • External guest users can't use Analyze in Excel.
• You don't have the development skills or resources to embed content in a custom application.
• There aren't many long-term, external consumers.

Option 2: Create a Microsoft Entra B2B guest account for external consumers

Microsoft Entra B2B is a good option to distribute content to external consumers. With this approach, an Azure administrator adds the external consumer as an external guest user in Microsoft Entra ID. If the external user is required to access content, the Azure administrator or a Microsoft 365 administrator can provision a per-user license for the identity. External users can also bring your own license (BYOL) from their organization to access content that requires a per-user license. When the guest user has an appropriate license, creators can then share content with them.

The following diagram shows how you can share content with external users by using Microsoft Entra B2B.

In summary, external users are made external guest users by an Azure administrator. If the guest user requires a license, a Microsoft 365 administrator can then assign a license to the guest user. These guest users can then access Fabric, including workspaces, apps, and items. Access to Fabric by external guest users can be controlled in the tenant settings by a Fabric administrator.

Here are some scenarios where you can use Microsoft Entra B2B to deliver content to external consumers.

• Direct collaboration between organizations
• Parent and subsidiaries or affiliates
• Shared tenant among partner organizations
• Distribution to many external partners

This approach is beneficial when:

• There's a manageable number of external consumers.
• You have Fabric capacity and want external consumers to benefit from free viewership, or the external consumers have their own Power BI Pro licenses to use with BYOL.
• You don't have the development skills or resources to embed content in a custom application.

Option 3: Embed content in a custom website or application

In this approach, you use either an F, P, A, or EM SKU to embed content in a custom external website or application (Embed for your customers). This approach requires skills, time, and resources to develop a custom application and manage authentication. However, it provides flexibility and control over the access process.

This approach is beneficial when:

• You have the expertise, time, and resources to develop and maintain a custom application.
• You have an existing custom application that you want to embed Power BI content in.
• You distribute content to many external parties or customers.
• You want to monetize access to proprietary Power BI content to earn revenue.

Option 4: Publish content for a public audience by using Publish to web

Publish to web provides access to Power BI reports to anyone on the internet. It doesn't require authentication and access isn't logged for auditing purposes. Because report consumers don't need to belong to the organization or have a Power BI license, this technique is well suited to data journalism, a process where reports are embedded in blog posts, websites, emails, or social media.

This option is beneficial when:

• Content doesn't contain sensitive information and is intended for a public audience.
• You want to embed or link to the content in a public website, for example by using an HTML iframe element.

Step 4: Identify consumer licensing considerations

By now, you're ready to decide how to distribute content to consumers. You should now ensure that consumers have appropriate licenses to access and view that content. Depending on how you decide to distribute content, you might need per-user, per-capacity, or other licenses.

• Per-user licenses: Content consumers might require Microsoft Fabric Free, Power BI Pro, or Premium Per User (PPU) licenses to view content, depending on other factors (described later in this section).
• Per-capacity licenses: Your organization requires either a Fabric capacity (F SKU) or Power BI Embedded (EM SKU) to embed content in a custom application.
• Other licenses: If you distribute content by using other services or applications, content consumers might require other licenses. For example, both content creators and consumers require a Power Apps license to distribute and view content by using this service.

The following sections outline specific per-user licenses you might need for consumers.

Scenario 1: Consumers require no license

While content creators always require a license to publish and share content, there are certain circumstances where consumers don't require a license to view published content.

• Content is distributed publicly via Publish to web.
• Consumers access embedded content via an external website or application (which uses the For your customers embedding scenario).

Scenario 2: Consumers require Microsoft Fabric Free licenses

When you distribute or share content that's published to a Fabric capacity, consumers still require a license to access that content. They can do so at no cost with a Microsoft Fabric Free license, and they don't need any other per-user license, like Power BI Pro. An organization has unlimited Microsoft Fabric Free licenses that they can use to provide access to Fabric and Power BI content.

Scenario 3: Consumers require Power BI Pro licenses

Content creators always require a Power BI Pro license to share Power BI content, even if that content is published to a workspace on Fabric capacity. However, content creators don't require a Power BI Pro license to create or share Fabric content.

Content consumers require a Power BI Pro license to:

• Consume content that's in a workspace that doesn't use Fabric capacity license mode.
• Share Power BI content with other consumers.
• Preview shared .pbix files that are stored in OneDrive for Work or School, or SharePoint.
• Use a Microsoft Entra B2B guest account that can't use bring your own license (BYOL).

Scenario 4: Consumers require Power BI Pro or PPU licenses

If content is published to a workspace that uses PPU license mode, then both content creators and content consumers require a PPU license to share and view that content.

Step 5: Identify whether consumers require Build permission

Some consumers might have more advanced needs that aren't met with the available read-only content. These consumers could benefit from having Build permission on the underlying data items (like semantic models) so that they can create new content (like reports).

Eventually, consumers might want to share their content with others, at which point they also become content creators.

Option 1: No Build permission

The simplest scenario is when users only need to view content, and they don't want to produce their own content.

This approach is beneficial when:

• You currently lack the resources or processes to support consumers so that they can successfully create their own content.
• You haven't yet trained users how to connect to, and create content from, data items.
• Consumers express that they only want to view content and not create it.
• There's no business need for consumers to create their own content.

In these scenarios, you should seek to provide alternative approaches to granting Build permission when consumers still want to analyze and explore data.

Consider the following Power BI features that provide flexibility to consumers.

• Field parameters: You can create field parameters in semantic models that support the dynamic selection of dimensions and measures in reports. This option provides users with the ability to select a field from a slicer, and that field will be then used in visuals.
• Decomposition tree visual: You can use the decomposition tree visual in reports to let consumers explore data across multiple dimensions that they choose.
• Personalize visuals: You can enable personalization of visuals in a report, which lets consumers change visuals to suit themselves. They can modify any visual, including the visual type, format settings, and which fields the visual uses. They can also customize the report page to any field you pre-select from the semantic model, enabling them to perform ad hoc analysis.

Option 2: App audience Build permission

You can grant Build permission to members of an app audience, which applies to all the underlying semantic models for the reports and dashboards that are included in the app.

This approach is beneficial when:

• You distribute content by using Power BI apps.
• Consumers require Build permission only for semantic models.
• You need to give multiple users Build permission to multiple items in the same workspace.

Option 3: Item Build permission

You can grant Build permission to individual data items in a workspace.

This approach is beneficial when:

• You provide access to workspace content by adding consumers to the Viewer role.
• You need to grant Build permission only on specific items.
• You plan to grant Build permission to a small subset of users.

Checklist - When planning content distribution to consumers, key decisions and actions include:

Plan to share content with other creators

In enterprise and self-service scenarios, you'll need to share content with other creators. Sharing content with other creators facilitates collaboration among developers who work on the same content. It also facilitates data discovery and data democratization among self-service users who create their own content.

The following diagram presents an overview of the different approaches that you can take to share content with other creators.

The diagram depicts the following concepts and processes.

Item	Description
	Content creators create and deploy content in their organization. They can share content with other internal users who use Fabric (such as the Fabric portal or the Power BI mobile app).
	Creators can also share items outside the organization. They can distribute content to external guest users who have been added to the organization with Microsoft Entra B2B. In some scenarios, creators can also share their content files to external users.
	Content is deployed in a Fabric tenant, where creators can use or view it.
	Fabric capacity is required to create and share Fabric items.
	Content is deployed to a workspace.
	Creators can distribute content with other internal users or external guest users who are content creators by assigning them to the Admin, Member, or Contributor workspace roles. The principle of least privilege is recommended when sharing content by workspace role.
	Creators can also share content with other internal users or external guest users who are content creators by sharing individual items via links. When creators have access to data items via direct access or workspace roles, they can discover this content by using the OneLake data hub.
	In a workspace on Fabric capacity, creators can make and use lakehouses, which comprise tables and files in folders.
	Creators can share data in a lakehouse folder to other internal users or external guest users who are creators by using OneLake data access roles (also known as role-based access control, or RBAC).
	In a workspace on Fabric capacity, creators can make and use KQL databases, which comprise tables and files in folders.
	Creators can share data from a lakehouse or KQL database folders with external users outside the organization by using external data sharing.

Step 1: Identify who creators are and how they get access

The first step when sharing content with creators is to identify who they are and how they should get access to the items or data that they need to make and share their own content.

You're then ready to complete the following tasks.

• Share gateways: If necessary, set up data gateway access by adding consumers to data source connections in the User (or User with sharing) role.
• Create workspaces: Create and share access to a workspace where creators should publish their content, if they don't have one already. Creators might need access to more than one workspace if they plan to use separate workspaces to develop, test, and share content with consumers. Alternatively, you might share access to an existing workspace that contains other content that creators need access to (described later in this article).
• Allocate licenses: Creators need different licenses depending on the content that they produce.
  • Power BI Pro licenses are always required to create and share Power BI content.
  • PPU licenses are required to create and share content when the workspace uses PPU license mode.
  • No license is required to create and share Fabric items when the workspace is on Fabric capacity.

Option 1: You provide access to creators

You can proactively share content with creators, like the approach described for content consumers.

This approach is beneficial when:

• Creators need access to only a few data items.
• You want more control over what content creators can find and use.

Option 2: Creators find items and request access from the OneLake data hub

You should encourage users to use the OneLake data hub to discover content that they can use as a data source. There, and when necessary, content creators can request access to these data items. When they're granted Build permission, they can then create new content based on these items.

This approach is beneficial when:

• You use endorsements to promote and certify quality content.
• You mark content as discoverable so that users can find it from the OneLake data hub.
• You've created a process to sustainably manage access requests.
• Users have undergone training on how to find and use data items in Fabric.

Step 2: Decide on creator permissions

Depending on how creators will use the content, they might need different permissions.

Option 1: Write permission

You can grant content creators Write permission to edit and collaborate on an item. When you grant content creators Write permission, ensure that you also grant access to content files, if necessary.

Grant creators Write permissions when:

• Creators need to change or manage the item.
• You will collaborate with the creators on the item.

Option 2: Build permission

You can grant content creators Build permission to connect to and use semantic models to create new content. With Build permission, content creators won't be able to modify the original item.

Grant creators Build permissions when creators will create new content from existing semantic models.

Option 3: Read permission

You can grant creators Read permission to certain Fabric data items, like lakehouses. That way, they can make their own content (like semantic models and reports) without modifying the original data item.

Grant creators Read permission when:

• Creators should discover semantic models in the OneLake data hub to view their metadata and then request Build permission from the content owner.
• Creators should use Fabric data items like lakehouses or data warehouses to make their own content.

Step 3: Identify whether creators are outside the organization

If content creators outside the organization require access to items or data, then you'll need to take specific actions. The scenarios and considerations for content consumers also apply here.

You have several options to share content with external creators. The first two options are similar to how you share content with external consumers, except you grant Write permission to creators.

Option 1: Create duplicate identities for external creators

You can create a new account for the external consumer in your tenant that they must use to access that content.

Consider using duplicate identities for external creators when:

• External creators need to access other internal services, or they prefer to use a separate, internal account.
• Organizational policies or administrator settings don't allow for B2B sharing.
• Limitations of Microsoft Entra B2B prevent you from doing what you need to do. Examples of limitations of Microsoft Entra B2B for creators include:
  • External guest users can't use Power BI Desktop to connect to semantic models or dataflows that are in the Power BI service and can't publish from Power BI Desktop.
  • External guest users can't set sensitivity labels.
  • External guest users can't install an on-premises data gateway.

Option 2: Create a Microsoft Entra B2B guest account for external creators

You can add the external creator as a guest user and share the item with them. Guest users can bring their own Power BI Pro or PPU license to use in the host tenant. However, guest users have several key limitations when creating and sharing Power BI content with others, such as the limitations for in-place semantic model sharing.

Consider distributing content to external guest users when:

• External creators have their own Power BI Pro and PPU licenses.
• You'll share a few content items with a few external creators to use.
• You'll distribute content to many external creators who have.

Step 4: Identify what creators need to access

You can grant access to creators at four different levels, depending on what they need to do.

• Deployment pipeline access: Provides creators access to a deployment pipeline and lets them trigger deployments to promote content between stages. Creators require access to the underlying workspaces to use deployment pipelines.
• Workspace access: Provides creators access to all the content in a workspace.
• Item access: Provides creators access to a single content item within a workspace.
• Data access: Provides creators access to specific data within an item. Creators require Write permission for an item to apply data access to data within that item.

The following sections help you to determine what access creators should get.

Option 1: Deployment pipeline access

You can give creators access to a deployment pipeline to manage content deployment between multiple workspaces. These creators can also change the deployment pipeline and review deployment history.

This approach is beneficial when:

• You'll use deployment pipelines to deploy content between workspaces.
• The content creator will be responsible for reviewing content during the deployment process.

Option 2: Workspace access

You can give creators access to all content in a workspace by assigning them to either the Member or Contributor workspace role.

This approach is beneficial when:

• Creators will also get deployment pipeline access.
• Creators should collaborate in the workspace.
• You use Git integration to track and manage content changes in a remote repository that's linked to the workspace.
• Creators need to use a dataflow.

Option 3: Item access

You can give creators access to individual content items in a workspace by sharing via direct access. With this approach, you share a link to the item (similar to when you share individual items with consumers), or creators request access after they discover the content in the OneLake data hub.

This approach is beneficial when:

• Creators will only use one or a subset of items in a workspace.
• You want to share items with creators without providing workspace access.
• Creators should publish the content they create to their own, separate workspace.
• Creators should discover data items from the OneLake data hub.

Option 4: Data access

In some circumstances, content creators will need access to underlying data. In this case, creators might want to transform or enrich that data for other purposes. You have two options to share data in Fabric.

• OneLake data access role: You can assign someone to a data access role for data in a folder of a lakehouse. This approach lets you apply RBAC to OneLake data to limit what data someone can see.
• OneLake shortcuts: While not strictly a sharing technique, you can provide access to data by creating internal OneLake shortcuts to reference data within existing Fabric items. This approach lets you reuse data across teams and workspace while maintaining a single copy of the data.

These approaches are beneficial when:

• Your organization has Fabric capacity and uses lakehouses to store data for creators.
• You want to restrict the data that a creator can see and use from a lakehouse.
• Creators want to transform the underlying data to use in other data items.
• Creators are unable to use other approaches, like composite semantic models.

Checklist - When sharing content with other creators, key decisions and considerations include:

Related content

For more considerations, actions, decision-making criteria, and recommendations to help you with Power BI implementation decisions, see Power BI implementation planning.