Power BI implementation planning: Workspaces at the tenant level

This article describes strategic implementation planning that you do at the tenant 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.

This article might be helpful for self-service creators who create, publish, and manage content in workspaces.

Because workspaces can be used in different ways, most tactical implementation decisions are made at the workspace level. You make some strategic planning decisions at the tenant level.

We recommend that you make tenant-level workspace decisions as early as possible because they affect everything else. Also, it's easier to make individual workspace decisions when you're clear about your overall workspace goals and objectives.

Workspace creation permissions

The decision of who is allowed to create workspaces in the Power BI service is a data culture and governance decision.

You have two options:

• All (or most) users can create new workspaces: This approach usually aligns with existing decisions for other applications. For example, when users are permitted to create their own SharePoint sites or Teams channels, it makes sense that Fabric adopts the same policy.
• Workspace creation is limited to a select set of users: This approach usually indicates a governance plan is in place or is planned. Managing this process can be fully centralized (for example, if only IT is permitted to create a workspace). A more flexible and practical approach is when it's a combination of centralized and decentralized individuals. In this case, specific satellite members of the CoE, champions, or trusted users are trained to create and manage workspaces on behalf of their business units.

You should set up the Create workspaces tenant setting in the Fabric admin portal according to your decision on who is allowed to create workspaces. For more information, see Govern workspaces.

Checklist of key decisions and actions when you plan who can create workspaces:

Workspace naming conventions

Workspace naming conventions are an agreed-upon pattern for how workspaces are named. Usually, naming conventions are a requirement and not a suggestion.

It can be difficult to strictly enforce naming conventions when many users possess the permission to create workspaces. You can mitigate this concern with user education and training. You can also conduct an auditing process to find workspaces that don't conform to the naming conventions.

The workspace name can convey additional information about the workspace, including:

• Purpose: A workspace name should always include a description of its content. For example, Sales Quarterly Bonus Tracking.
• Item types: A workspace name can include a reference to the types of items it contains. For example, use Sales Data to indicate the workspace stores items like a lakehouse or semantic models. Sales Analytics could indicate that the workspace stores analytical reports and dashboards.
• Stage (environment): A workspace name might include its stage. For example, it's common to have separate workspaces (development, test, and production) for lifecycle management.
• Ownership and responsibility: A workspace name might include an indication of who's responsible for managing the content. For example, use of an SLS prefix or suffix can indicate that the sales team owns and manages the content.

Having consistent workspace names helps everyone. The user experience is improved because users can find content more easily. Also, administrators can oversee the content more easily when you use predictable naming conventions.

We recommend that you include the workspace naming conventions in your centralized portal and training materials.

The following list describes more considerations related to workspace naming.

• Use short yet descriptive names: The workspace name should accurately reflect its contents, with the most important part at the beginning of the name. In the Fabric portal, long workspace names can become truncated in user interfaces, requiring the user to hover the cursor over the workspace name to reveal the full name in a tooltip. Here's an example of a short yet descriptive name: Quarterly Financials.

• Use a standard prefix: A standard prefix can arrange similar workspaces together that are sorted. For example: FIN-Quarterly Financials.

• Use a standard suffix: You can add a suffix for additional information, such as when you use different workspaces for development, test, and production. We recommend appending [Dev] or [Test] suffixes but leaving production as a user-friendly name without a suffix. For example: FIN-Quarterly Financials [Dev].

• Be consistent with the Power BI app name: The workspace name and its Power BI app can be different, particularly if it improves usability or understandability for app consumers. We recommend keeping the names similar to avoid confusion.

• Omit unnecessary words: The following words might be redundant, so avoid them in your workspace names:

  • The word workspace.
  • The words Fabric or Power BI. Many Fabric workspaces contain items from various workloads. However, you might create a workspace intended to target only a specific workload (such as Power BI, Data Factory, or Synapse Data Engineering). In that case, you might choose a short suffix so that the workspace purpose is made clear.
  • The name of the organization. However, when the primary audience is external users, including the organization's name can be helpful.

Checklist of key decisions and actions when you plan workspace naming conventions:

Workspace domains

Essential to the planning and implementation process is being clear about how you want content owned and managed. Clarity is especially critical when responsibilities for creating and managing data assets are decentralized among many departments or business units. Sometimes this approach is called a distributed, federated, or data mesh architecture.

One way to support workspace ownership and management in Fabric is by using domains. A ___domain provides a way to logically group multiple workspaces that have similar characteristics. For example, you might create a ___domain to group all your sales workspaces together, and create another ___domain to hold your finance workspaces.

Here are the key advantages of using domains:

• Domains group similar workspaces into a single management boundary.
• Domains permit certain tenant settings to be managed at the ___domain level. For more information, see Override tenant-level settings.
• Domains help users find relevant data. For example, they can use filters in the OneLake catalog.

The following table lists different ways you can organize related workspaces:

Here are some questions to consider when you plan for Fabric domains in your tenant:

• How does each workspace map to a ___domain? Each workspace can be assigned to only one ___domain, so be prepared to do some detailed planning. Consider creating a matrix diagram that lists workspaces in the rows and domains in the columns to help you plan how they're assigned. If you discover that you need to reorganize workspaces, you can reassign the ___domain in the workspace settings or in the admin portal.
• Who is authorized to manage a ___domain? Users assigned the Domain Administrator role are authorized to manage an existing ___domain. When possible, assign ___domain administrators who directly own and manage the content for the ___domain. Domain administrators should be experts who are familiar with internal, regional, and governmental regulations for the subject area. They should also be familiar with all internal governance and security requirements. For more information, see Domain roles.
• Who is allowed to assign workspaces to a ___domain? Users assigned the Domain Contributor role define which workspace administrators can assign a workspace to a ___domain. If you allow more users to assign workspaces to a ___domain, you should frequently audit the accuracy of the assigned groupings. If you allow only specific groups of users or Fabric admins and ___domain admins, you have more control over how domains are assigned. For more information, see Domain roles.
• Do you have specific compliance needs or restrictions, such as geographic area? Keep in mind that the geographic area for data storage is set for each capacity rather than for the ___domain. Consider how assigning a workspace to a ___domain and to a capacity affects your planning process.

For more information, see Govern domains.

Checklist of key decisions and actions when you plan for workspace domains:

When you plan for workspace domains, key decisions and actions include:

Workspace creation process

If you decide to limit who can create workspaces, the broader user population needs to know what the process is to request a new workspace. In this case, it's important to establish a request process that's easy and convenient for users to find and follow.

It's also critical to respond quickly to a request for a new workspace. A service-level agreement (SLA) of 2 to 4 hours is ideal. If the process to request a new workspace is too slow or burdensome, people will use the workspaces they have, so they can keep moving. If they elect to skip creating a new workspace, what they use instead could be suboptimal. They might choose to reuse an existing workspace that isn't well-suited to the new content, or they might share content from their personal workspace.

The following table lists the information to collect in a request for a new workspace:

This table includes the minimum amount of information required to set up a workspace. However, it doesn't include all possible configurations. In most cases, a workspace administrator takes responsibility for completing the setup after the workspace is created. For more information, see Workspace-level settings.

You can choose from many technology options to create an online form for the workspace creation request. Consider using Microsoft Power Apps, a low-code software option that's ideal for building simple web-based forms and applications. The technology you choose to use for creating a web-based form depends on who is responsible for creating and maintaining the form.

Checklist of key decisions and actions when you plan the process to request a new workspace:

Workspace governance level

Not all workspaces need the same level of oversight. Certain workspaces might be considered governed. A governed workspace results in more requirements and expectations for its content. Some organizations use the term managed instead of governed.

Four key decision criteria determine the level of governance required:

• Who owns and manages the BI content?
• What is the scope for delivery of the BI content?
• What is the data subject area?
• Is the data or the BI solution considered critical?

You might start out with two levels of workspaces: governed and ungoverned. We recommend that you keep the governance levels as simple as possible. However, depending on your specific circumstances, you might need to subdivide the governed classification. For example, critical content that the enterprise Power BI team manages might have a unique set of governance requirements. Critical content that business units own and manage might be subject to a slightly different set of requirements. In some cases, decisions are tailored to individual business units.

The following table lists some of the most common requirements when a workspace is considered governed.

Checklist of key decisions and actions when you plan workspace governance level:

Next step