Power BI implementation planning: Workspaces at the workspace level

This article describes tactical implementation planning that you do at the workspace level for Microsoft Fabric workspaces, with an emphasis on the Power BI experience inside Fabric.

The article primarily is for:

• Fabric administrators: Administrators who are responsible for overseeing the Fabric implementation in the organization.
• Center of Excellence (CoE), IT, and business intelligence (BI) teams: Teams that are responsible for overseeing the use of data and BI in the organization, and for supporting self-service users throughout the organization.
• Content creators and owners: Self-service users who create, publish, and manage content in workspaces.

To use workspaces effectively, you make many tactical decisions. Whenever possible, individual workspace-level decisions should align with your tenant-level decisions.

Workspace purpose

When you plan a workspace, it's important to consider not only the type of content it will store but also the activities the workspace is intended to support.

Consider the following two examples of finance-related workspaces. Although they're both dedicated to the same team, each workspace serves a different purpose:

• Financial month-end workspace: The Financial month-end workspace contains reconciliation and month-end closing reports. This workspace is considered an informal workspace to support collaborative efforts. A Power BI app isn't necessary for content viewers because the primary use of this workspace is collaboration by a small group of people who work closely together. Most team members have permissions that let them edit content in this workspace.
• Financial reporting workspace: The Financial reporting workspace contains the finalized, presentation-level reports. This workspace contains content that is broadly distributed throughout the organization to many viewers, including to executives, via a Power BI app. The workspace is closely governed.

With these two examples in mind, consider two specific aspects of workspace purpose: intent for collaboration and intent for viewing.

Intent for collaboration

The primary objective of a workspace in the Fabric portal is to facilitate collaboration among multiple contributors.

Collaboration in a workspace occurs in multiple ways:

• Team-based development: Users can work together to build, test, and publish content. One user might work on the design of a lakehouse. Another user might work on the design of the semantic model, and other users might focus on building reports.
• Testing and validations: Users might need to perform data validations for new content. Subject matter experts from the business unit might need to perform user acceptance testing (UAT). A data quality team might need to validate the accuracy of the semantic model.
• Enhancements: Content stakeholders and consumers might suggest enhancements to content throughout the lifecycle of the content.
• Ownership transfer: Another person or team might assume responsibility for content that someone else created.

One of the key areas of the Fabric adoption roadmap is content ownership and management. The type of collaboration that occurs in a workspace differs based on the approach you choose for content ownership and management:

• Business-led self-service BI: Content that the content creators in a business unit or department own or manage. In this scenario, most collaboration in the workspace occurs among users in that business unit.
• Managed self-service BI: Data that a centralized team owns or manages, but various content creators from business units take responsibility for reports and dashboards. In this scenario, it's highly likely that multiple workspaces are needed to securely facilitate collaboration by multiple teams of people.
• Enterprise BI: Content that a centralized team, such as IT, enterprise BI, or the CoE owns or manages. In this scenario, collaboration efforts in the workspace occur among users in the centralized team.

Checklist of key decisions and actions when you plan for collaboration in a workspace:

Intent for content viewing

The secondary objective for a workspace is to distribute content to consumers who need to view the content. For content viewers, the primary Fabric workload is Power BI.

You can approach content distribution in the Power BI service in multiple ways:

• Reports can be viewed by using a Power BI app: Content stored in a nonpersonal workspace can be published to a Power BI app. A Power BI app is a more user-friendly experience than viewing reports directly in a workspace. For this reason, using a Power BI app is often the best choice for distributing content to consumers. Audiences for a Power BI app are flexible. However, sometimes your goals for how to distribute content with an app are a factor in determining how to organize content in or across workspaces. For more information about securing Power BI apps, see Report consumer security planning.
• Reports can be viewed directly in the workspace: This approach is often appropriate for informal, collaborative workspaces. Workspace roles define who can view or edit the content contained in a workspace. For more information about workspace roles, see Content creator security planning.
• Reports can be shared: Use of per-item permissions (links or direct access) is useful when you need to provide read-only access to a single item in a workspace. We recommend that you use app permissions and workspace roles more frequently than sharing because they're easier to maintain. For more information, see Report consumer security planning.
• Reports can be embedded in another application and viewed in the application: Sometimes the intention is for consumers to view Power BI content embedded in another application. Embedding content is useful when it makes sense for the user to remain in the application to increase efficiency and stay within its workflow.

Another key area of the Fabric adoption roadmap is content delivery scope. The ways that a workspace support content distribution differs based on the content delivery scope:

• Personal BI: Content is intended for the content creator to use. Because sharing content with other users isn't an objective, personal BI is done in a personal workspace as described in the next section.
• Team BI: Content is shared with a relatively small number of colleagues who work closely together. In this scenario, most workspaces are informal, collaborative workspaces.
• Departmental BI: Content is distributed to many consumers who belong to a large department or business unit. In this scenario, the workspace is primarily for collaboration efforts. In departmental BI scenarios, content is commonly viewed in a Power BI app instead of directly viewed in the workspace.
• Enterprise BI: Content is delivered broadly across organizational boundaries to the largest number of target consumers. In this scenario, the workspace is primarily for collaboration efforts. For enterprise BI scenarios, content is commonly viewed in a Power BI app instead of directly viewed in the workspace.

Checklist of key decisions and actions when you consider expectations for how workspace content is viewed:

Appropriate use of personal workspaces

You can choose from two types of workspaces:

• Personal workspaces: Every user has a personal workspace. A personal workspace can be used for publishing certain types of content to the Fabric portal. Its primary purpose is to support personal BI usage scenarios.
• Workspaces: The primary purpose of a workspace is to support collaboration among multiple users. Secondarily, a workspace can also be used for viewing content.

A personal workspace used for anything other than learning personal BI, temporary content, or testing increases an organization's risk. In a personal workspace, only the workspace owner creates and manages the content. A personal workspace also doesn't support collaboration with others.

To allow a user to create any type of Fabric item, like a lakehouse or a warehouse, a workspace must be added to a Fabric capacity. The process applies to both standard workspaces and personal workspaces. You can govern who can create certain types of items in a personal workspace by managing its capacity assignment.

A personal workspace is limited in its options to share content with others. You can't publish a Power BI app from a personal workspace. Also, Power BI apps are an important mechanism for distributing content to the organization. Per-item permissions (links or direct access) are the only way to share personal workspace content with others. Extensive use of per-item permissions involves more effort, and it increases the risk of error. For more information, see Report consumer security planning.

Checklist of key decisions and actions when you consider expectations for how personal workspaces are used:

For more information, see the Fabric adoption roadmap:

• Fabric centralized portal
• Fabric training
• Fabric documentation

Workspace ownership

One of the most important things to consider when you plan workspaces is determining the ownership and stewardship roles and responsibilities. The goal is to have clarity on exactly who is accountable for creating, maintaining, publishing, securing, and supporting the content in each workspace.

Clarity on ownership is especially relevant when responsibilities for creating and managing data are decentralized or distributed among departments and business units. This concept is also sometimes referred to as a data mesh architecture. For more information about data mesh, see What is data mesh?.

In Fabric, decentralized or distributed ownership is enabled through workspaces. Different areas of the organization can work independently but still contribute to the same underlying data structure in OneLake. Each workspace can have its own administrator, access control, and capacity assignment (for billing, geographic data ___location, and performance monitoring).

When the intent for collaboration involves decentralization and multiple teams beyond a single business unit, it can add complexity for managing workspaces. Often, it's helpful to create separate workspaces to clearly delineate which team is responsible for which content. Use of multiple workspaces allows you to be specific as to ownership and management responsibilities, and it can help you to set security according to the principle of least privilege. For more security considerations, see Content creator security planning.

Checklist of key decisions and actions when you consider workspace ownership responsibilities:

Workspace organization

How to organize workspaces is one of the most important aspects of workspace planning.

Different business units and departments might use workspaces differently depending on their collaboration requirements. When you need a new workspace, we recommend that you consider the factors described in this section.

Workspace subject and scope

The following options present some suggestions about how you can organize workspaces by subject and scope.

In some cases, you might already have some useful groups established in Microsoft Entra ID. You can use the groups to manage access to resources for the defined subject area and scope. However, you might need to create new groups to fully implement this approach. For more information, see Workspace access.

Option 1: One workspace per subject area or project

If you create one workspace for each subject area or project, you can focus on the workspace purpose. This approach can be more balanced in the distribution of content among workspaces.

Examples: Quarterly Financials or Product Launch Analysis

The advantages of option 1 include:

• It's more straightforward to manage user access for who can edit or view content because access is scoped per subject area.
• When users across organizational boundaries access content, structuring workspaces by subject area is more flexible and easier to manage, which is compared to option 2, discussed next.
• One scope per subject area is a good compromise between workspaces that contain too many items and workspaces that contain too few items.

A disadvantage of option 1 is that, depending on how narrow or wide workspaces are defined, you still risk users creating an excessive number of workspaces. Finding content can be challenging for users when content is spread across many workspaces.

Option 2: One workspace per department or team

A common approach is to create one workspace per department, team, or business unit. In fact, alignment with the organizational chart is the most common way people begin planning workspaces. But this approach isn't ideal for all scenarios.

Examples: Finance Department or Sales Team Analytics

The following diagram depicts a generalized example of how you might separate workspaces by department, team, or subject area. Option 1 and option 2 look the same. The items to include in each workspace depends on the nature of the data each department, team, or subject area focuses on, and how they intend to use the data.

The advantages of option 2 include:

• Getting started with planning is simple. All content that department users need is in one workspace.
• It's easy for users to know which workspace to use because all their content is published in the workspace associated with their department or team.
• Managing security roles can be straightforward, especially when you use the best practice of assigning Microsoft Entra groups to workspace roles.

The disadvantages of option 2 include:

• The result is often a broad-scoped workspace that contains many items. A broadly defined workspace scope can make it challenging for users to locate specific items.
• Because a one-to-one relationship exists between a workspace and a Power BI app, a broadly defined workspace can result in apps for users that contain lots of content. You can mitigate the issue by excluding certain workspace items from the app and via design of app navigation.
• When users from other departments need to view specific workspace items, managing permissions can be more complex. A risk is that people assume that everything in the department workspace is for their eyes only. Another risk is that sharing individual items instead of roles is used to accomplish granular viewing permissions.
• If some content creators need permissions to edit some but not all items, it's not possible to set those permissions in a single workspace. Workspace roles, which determine edit or view permissions, are defined at the workspace level.
• When you have a large number of workspace items, you often need to use strict naming conventions for items so that users can find what they need.
• Broad workspaces with many items might run into a technical limitation on the number of items that can be stored in a workspace.

Option 3: Workspace for a specific report or app

Creating a workspace for each report or type of analysis isn't recommended except in specific circumstances.

Examples: Daily Sales Summary or Executive Bonuses

Advantages of option 3 include:

• The purpose of a narrowly defined workspace is clear.
• Ultra-sensitive content can, and often should, be segregated into its own workspace so that it can be managed and governed explicitly.
• Fine-grained workspace permissions are applicable to a few items. This setup is useful when, for example, a user is permitted to edit one report but not another.

Disadvantages of option 3 include:

• If overused, narrowly defined workspaces can lead to a large number of workspaces.
• A large number of workspaces requires more effort for users. Although users can rely on search, finding the right content in the right workspace can be frustrating.
• A larger number of workspaces increases the auditing and managing workload.

Checklist of key decisions and actions when you consider the subject area and scope of workspace content:

Workspace item types

A common practice to decouple data assets from analytical assets is to separate data workspaces from reporting workspaces.

• A data workspace is dedicated to storing and securing data items such as a lakehouse, warehouse, data pipeline, dataflow, or semantic model.
• A reporting workspace is focused more on downstream analytical activities. A reporting workspace stores and secures only items like reports, dashboards, and metrics. Reporting workspaces typically include Power BI content, but it's not required.

In Fabric, you might extend this separation to have distinct workspaces for other item types.

Some examples include:

• Data source workspaces for data warehouses, lakehouses, and SQL databases that store data
• Data transformation workspaces for data pipelines, notebooks, and dataflows that transform data
• Distribution workspaces for scorecards, metric sets, and organization applications that distribute data to users

The following diagram depicts an example of how you might separate workspaces by item type.

The advantages for separating data workspaces from reporting workspaces include:

• Critical organizational data, such as an endorsed lakehouse or semantic model, can reside in a specific workspace designed to make reusable data available at enterprise scale. Common examples include:
  • Report creators can locate and reuse trustworthy shared semantic models more easily. For more information, see the managed self-service BI usage scenario.
  • Semantic model creators can locate trustworthy dataflows or lakehouse tables more easily. For more information, see the self-service data preparation usage scenario and the advanced self-service data preparation usage scenario.
• Access management can be centralized for critical organizational data. Managing access separately for the data workspace compared with reporting workspaces is useful when different people are responsible for data and reports. With managed self-service BI, it's common to have many report creators and fewer data creators.
• Limiting who can edit and manage semantic models minimizes the risk of unintentional changes, especially to critical data items that are reused for many purposes or by many users. Physical separation reduces the chances of inadvertent, or unapproved, changes. This extra layer of protection is helpful for certified semantic models, which the organization relies on for their quality and trustworthiness.
• Co-ownership scenarios are clarified. When shared semantic models are delivered from a centralized BI or IT team, self-service content creators in business units publish reports. A good practice is to segregate the semantic models in a separate workspace. This approach avoids the ambiguity of co-ownership scenarios because ownership and responsibility per workspace is more clearly defined.
• Row-level security (RLS) is enforced. When you encourage creators to work in different workspaces, they don't have unnecessary edit permissions to the original semantic model. The advantage is that RLS and object-level security (OLS) are enforced for content creators and content viewers.

Disadvantages for separating data workspaces from reporting workspaces include:

• A workspace naming convention is required to differentiate a data workspace from a reporting workspace.
• Extra user education is required to ensure that content authors and consumers know where to publish and find content.
• Sometimes it's challenging to clearly delineate the item types that should be contained in a workspace. Over time, a workspace can end up containing more types of content than was originally intended.
• Use of separate workspaces results in a larger number of workspaces that you need to manage and audit. As you plan for purpose, scope, and other considerations (such as the separation of development, test, and production content) the approach to workspace design can become more complicated.
• Extra change management processes could be required to track and prioritize requested changes to centralized data items, particularly when report creators have requirements beyond what composite models and report-level measures can handle.

Workspace development stage

A common practice is to use separate workspaces for different stages of content development. Typically, this practice involves the following stages:

• Development workspaces for untested changes
• Test workspaces for dedicated internal and user testing
• Production workspaces for releasing content for consumers

In Fabric, you can add workspaces for each stage to a deployment pipeline. A deployment pipeline helps with content lifecycle management, by letting pipeline administrators compare and deploy changes between stages. Typically, you first publish content to the earliest stage (like development) and then deploy it to the next stage (like deploying content from development to test workspaces, and then from test to production workspaces).

Here's an example of this setup:

You can also combine separating workspaces by both development stage and item type. If you use deployment pipelines, you can use autobinding to ensure that stages are linked. Autobinding ensures that, for example, reports in the report development workspace point to the correct semantic model in the model development workspace.

Here's an example:

Optionally, you might have other workspaces, such as the following types of workspaces:

• Private workspaces for creators to work in isolation. Using this setup is a common practice for collaborating on content by using Git integration because each content creator works on their own separate copy (branch) of the content to avoid disrupting each other's work. Then, creators can open a pull request to merge their changes into another branch that syncs to the development workspace, which creators can view, but not modify or publish content to.
• Preproduction workspaces for creators to perform specific tests before releasing content. These tests might include performance testing or testing supporting resources like data gateways and apps.
• Sandbox workspaces for creators to freely experiment and conduct improvised explorations. Sandbox workspaces are typically emptied at a regular cadence (often automatically, such as by using APIs or notebooks). Content that creators want to retain from a sandbox workspace can be copied to a personal or private workspace for more development.

The advantages for separating workspaces by development stage include:

• You can support more sophisticated and structured development processes, including:

  • Deployment Pipelines to copy content between stages
  • Git integration and branching strategies for deployment and release
  • Notebooks to orchestrate or automate certain tasks in the content lifecycle

• You can avoid disrupting production content that consumers use.

• You have better access control for content.

The disadvantages for separating workspaces by development stage include:

• You must manage and govern more workspaces, which create more overhead.
• You must plan for new deployment and post-deployment activities.
• You might have to account for other, non-supported tools or features that deploy or promote content through the development stages.
• More sophisticated workspace access policies are required to prevent creators from publishing to and using the wrong stage.

Intra-workspace organization

In addition to organizing your workspace structure, you also have to organize content in a single workspace.

To better organize content in a workspace, consider the following guidelines:

• Use clear naming conventions to easily identify different content. Consider using numerical prefixes (like 01 - Daily Sales to order content alphabetically, if needed).
• Use task flows to group content by its purpose in your workflow into tasks. Using task flows helps you quickly identify and select similar content (by selecting the task in the task flow). It's important if you decide to include many item types with different purposes in the same workspace.
• Use workspace folders to organize similar content into groups. Workspace folders can be used instead of or in addition to tasks in task flows.
• Use endorsement and sensitivity labels to label content appropriately based on their endorsement and sensitivity status.

Checklist of key decisions and actions when you consider item types that a user can store in a workspace:

Workspace access

Because the primary purpose of a workspace is collaboration, workspace access applies primarily to users who create and manage workspace content. Access can also be relevant when the workspace is used for viewing content. This purpose is a secondary purpose for workspaces, as described earlier in the article.

When you begin to plan for workspace roles, it's helpful to consider the following questions:

• How does collaboration occur in the workspace?
• Will consumers directly view content in the workspace?
• Who is responsible for managing the content in the workspace?
• Who can view content stored in the workspace?
• Do you intend to assign individual users or groups to workspace roles?

A best practice is to use groups to assign workspace roles. Security groups, mail-enabled security groups, distribution groups, and Microsoft 365 groups are all supported for workspace roles. For more information about using groups, see Tenant-level security planning.

When you plan to use groups, you might consider creating one group per role per workspace. For example, to support the Quarterly Financials workspace, you could create the following groups:

• Fabric workspace admins – Quarterly Financials
• Fabric workspace members – Quarterly Financials
• Fabric workspace contributors – Quarterly Financials
• Fabric workspace viewers – Quarterly Financials
• Power BI app viewers – Quarterly Financials

When data workspaces are separated from reporting workspaces, as described earlier in this article, it results in an even larger number of groups. Consider how the number of groups doubles from five to 10 when you separate data and reporting workspaces:

• Fabric data workspace admins – Quarterly Financials
• Fabric reporting workspace admins – Quarterly Financials
• Fabric data workspace members – Quarterly Financials
• Fabric reporting workspace members – Quarterly Financials
• Fabric data workspace contributors – Quarterly Financials
• Fabric reporting workspace contributors – Quarterly Financials
• Fabric data workspace viewers – Quarterly Financials
• Fabric reporting workspace viewers – Quarterly Financials
• Power BI app viewers – Quarterly Financials

When multiple workspaces exist for development, test, and production, it results in an even larger number of groups. Potentially, the number of groups might triple. For example, for just the data workspace admins, you would create these three groups:

• Fabric data workspace admins – Quarterly Financials [Dev]
• Fabric data workspace admins – Quarterly Financials [Test]
• Fabric data workspace admins – Quarterly Financials

The preceding examples are intended to convey that the use of groups that map to workspace roles can quickly become unmanageable.

The effective use of groups for workspace roles can require considerable planning. Be prepared to encounter scenarios when existing groups (that might be aligned with the organizational chart) don't meet all your needs for managing Fabric content. In this case, we recommend that you create groups specifically for this purpose. The words Fabric or Power BI are included in the group name in the preceding examples for this purpose. If you have multiple business intelligence tools, you can choose to use only BI as the prefix instead. That way, you can use the same groups across multiple tools.

Lastly, the examples show one workspace - Quarterly Financials - but often it's possible to manage a collection of workspaces with one set of groups. For example, multiple workspaces owned and managed by the finance team might be able to use the same groups.

Checklist of key decisions and actions when you consider workspace access:

Workspace ___domain

As described earlier in this article, it's critical to have clarity on workspace ownership. One way to further support workspace ownership in Fabric is by using domains. A ___domain is a logical grouping of multiple workspaces that have similar characteristics.

For more information about planning for domains in your tenant, see Workspace domains.

Workspace settings

You can set up several settings for each individual workspace. These settings can significantly influence how collaboration occurs, who is allowed to access the workspace, and the level of data reusability across Fabric workloads.

Workspace license mode

Each workspace has a license mode setting. You can set a workspace license mode to Pro, Premium per user, Premium capacity, Embedded, Fabric capacity, or Trial.

The type of license is important for workspace planning because it determines:

• Features: Different features are supported. PPU includes more features (such as deployment pipelines) that aren't available in Pro. Many more Fabric features (such as lakehouses) become available for workspaces assigned to a Fabric capacity.

• Content access: The license type determines who can access content in the workspace:

  • Only users who have a PPU license (in addition to being assigned a workspace role) can access a PPU workspace.
  • If you expect to deliver content to content viewers who have a free license, you need a license of F64 or higher.

• Data storage ___location: When you need to store data in a specific geographic region (outside of your home region), that becomes possible with a workspace assigned to a capacity (and, accordingly, the capacity is created in that region). For more information about data storage ___location, see Tenant setup.

Checklist of key decisions and actions when you consider workspace license mode:

Workspace lifecycle management

When content creators collaborate to deliver analytical solutions that are important to the organization, you must make various lifecycle management decisions. The lifecycle management processes are also called continuous integration/continuous delivery (CI/CD), and they're one aspect of DevOps.

Lifecycle management considerations include how to:

• Ensure timely, reliable, and consistent delivery of content.
• Communicate and coordinate activities between multiple content creators who are working on the same project.
• Resolve conflicts when multiple content creators edit the same item in the same project.
• Structure a straightforward and reliable deployment process.
• Roll back deployed content to a previous stable, working version.
• Balance fast releases of new features and bug fixes as you safeguard production content.

Fabric has two main lifecycle management components:

• Version control of content: Git integration allows content owners and creators to create versions of their work. It can be used with web-based development in a workspace, or when teams develop in a client tool, such as Power BI Desktop. Version control (also called source control) is achieved by tracking all revisions to a project by using branches associated with local and remote repositories in Azure DevOps. Changes are committed at regular intervals to branches in the remote repository. When a content creator completes revisions that are tested and approved, their branch is merged with the latest version of the solution in the main remote repository (after they resolve any merge conflicts). Git integration can be specified for each workspace in the Fabric portal if the feature is enabled in the tenant settings.
• Promoting content: Deployment pipelines are primarily focused on release management in order to maintain a stable environment for users. You can assign a workspace to a stage (development, test, or production) in a deployment pipeline. Then, you can easily and systematically promote, or deploy, your content to the next stage.

When you combine the lifecycle management features, during your planning process, cosider using best practices. For example, you might choose to use Git integration for your development workspace and deployment pipelines to publish to your test and production workspaces. Those types of decisions require using the agreed-upon practice consistently. We recommend that you do a proof of concept to fully test your setup, processes, and permissions model.

Checklist of key decisions and actions when you plan for lifecycle management of your workspaces:

Workspace integration with Data Lake Storage Gen2

It's possible to connect a workspace to an Azure Data Lake Storage Gen2 account. You might take this approach for two reasons:

• Storage of Power BI dataflows data: If you choose to bring-your-own-data-lake, the data for Power BI dataflows (Gen1) could be accessed directly in Azure. Direct access to dataflow storage in Data Lake Storage Gen2 is helpful when you want other users or processes to view or access the data. It's especially helpful when your goal is to reuse dataflows data beyond Power BI. You have two choices for assigning storage:

  • Tenant-level storage, which is helpful when you want to centralize all data for Power BI dataflows into one Data Lake Storage Gen2 account.
  • Workspace-level storage, which is helpful when business units manage their own data lake or have certain data residency requirements.

• Backup and restore for Power BI semantic models: The Power BI semantic model backup and restore feature is supported for workspaces that are assigned to capacity or PPU. This feature uses the same Data Lake Storage Gen2 account that's used for storing Power BI dataflows data (described in the previous bullet point). Semantic model backups are helpful for:

  • Complying with data retention requirements
  • Storing routine backups as part of a disaster recovery strategy
  • Storing backups in another region
  • Migrating a data model

Checklist of key decisions and actions when you plan for workspace integration with Data Lake Storage Gen2:

Workspace integration with Log Analytics

Log Analytics is a feature of Azure Monitor. You can use Log Analytics to review diagnostic data generated by the Analysis Services engine, which hosts Power BI semantic models. Workspace-level logs are useful for analyzing performance and trends, performing data refresh analysis, analyzing XMLA endpoint operations, and more. Log Analytics is available only for workspaces assigned to capacity or PPU.

For more information about semantic model event logs, see Data-level auditing.

For more information about how to set up Log Analytics for use with Power BI, see Configure Log Analytics for Power BI. Be sure to understand prerequisites you must have in place to implement the integration.

Checklist of key decisions and actions when you plan for workspace integration with Log Analytics:

Other workspace properties

Several other workspace properties can provide helpful information. For governed workspaces, we recommend that you set these properties.

Here are some suggestions for how to set the key settings to improve the experience for your users:

• Workspace description: A good workspace description includes a brief but specific explanation of what type of content is in the workspace. You can use up to 4,000 characters to describe:

  • The purpose for the workspace
  • The target audience
  • The type of content published to the workspace
  • Whether the workspace is considered governed
  • Whether the workspace includes development, test, or production data
  • Who to contact for questions or support

• Workspace contacts: The workspace contact list includes the workspace administrators by default. If you have technical content owners that are different from the subject matter experts, you might find it helpful to specify other contacts. Other contacts could be groups or individuals who can answer questions about the workspace content.

• Workspace image: Consistent use of workspace images can be helpful for users when they scan a list of workspaces.

  Consider using an image to help users identify:

  • The ___domain or subject area
  • The business unit or team that owns and manages the content
  • A data workspace dedicated to storing reusable items, such as a lakehouse, warehouse, data pipeline, dataflow, or semantic model
  • A reporting workspace dedicated to storing analytical items, such as reports, dashboards, or metrics

• Data model settings: Allows workspace members, administrators, and users with Build permissions on the semantic models to edit Power BI data models by using the web interface. This setting is used with the Users can edit data models in the Power BI service tenant setting. This setting should align with your decisions and processes for how to create, manage, and deploy content. Also, consider your method for version control as described earlier.

Checklist of key decisions and actions when you consider other workspace properties:

Other technical factors

Other technical factors might influence your workspace setup:

• Integrating content with other tools and services might have licensing implications. For example, if you embed a Power Apps visual in a Power BI report, you must have relevant Power Apps licenses.
• Per-workspace storage limits apply to the amount of data you can store in a Pro workspace. If using capacity or PPU isn't an option, consider how to work within the storage limits during the workspace planning process.
• When you install a template app from Microsoft AppSource, the app creates a new workspace that has a narrow subject and scope.

Checklist of key decisions and actions when you consider other technical factors:

Related content

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

• Introduction to Power BI implementation planning