Road to managed self-service BI

Many companies are widely using Power BI and are creating meaningful reports to gain insights into their data. This can be a great responsibility for the BI team. A lot of work goes into creating semantic models, writing correct DAX measures and having to create a report that fulfils the needs of the report consumers. Business users crave reports and want them fast but are often faced by limited IT occupancy. Imagine a world in which this can be overcome! Managed self-service BI lets business users connect to semantic models (formerly known as datasets) to allow them to build their own reports. This has many great advantages. Business users can create their own insights into the data they know best while still relying on support of the BI team who has built the underlying semantic model according to best practices.

In this post I will talk about managed self-service BI. I will go into more detail about what this means and how it is different from corporate BI. Finally, I will explain in more detail how I set up managed self-service BI at one of our clients. There I will focus on how to create a split between semantic models and reports as well as to set up the necessary security in the Power BI service.

Managed self-service BI

Microsoft identifies several BI scenarios. An overview is provided in figure 1.1. They can be classified into three categories: corporate BI, managed self-service BI and decentralized BI. A traditional organization is often working in a corporate BI scenario. In this case, the BI team creates the semantic models and the reports and then distributes these to the business users. You can find more information about corporate BI here. Access can be given via workspace roles, direct access or an app. This naturally depends on what best fits the organizational needs. The corporate scenario was in place at the client for many years. In 2024, the initiative was taken to implement managed-self service BI.

In Fig 1.1, the three roles are differentiated from each other between the responsibilities that both IT and the business users have when it comes to creating semantic models and reports. The more an organization moves from the right to the left, the more control and responsibilities are being handed over to the business teams. In this post I will go into more detail about the transition from corporate BI to managed self-service BI. Microsoft provides a good overview and a plan of approach for each scenario. The Microsoft documentation about managed self-service BI can be found here.

As explained before, during the corporate scenario, the BI team is responsible for semantic model and report creation. This often happens in the same pbix file. This changes (partially) when going to the managed self-service scenario. The BI team is still responsible for creating the semantic models using the Power BI desktop application. In here the connection is created to the underlying source and all necessary DAX measures are created. Naturally, the data model is also created. In this scenario, both the BI team and several business users can create reports. To enable this, there are two crucial steps that need to be taken care of: shared semantic models and LiveConnection.

Shared Semantic Models

One crucial aspect of implementing managed self-service BI is that the organization will need to start working with shared semantic models. These are created by the BI team. Each model is created in one pbix file. This file is then published to the Power BI service. Here the choice can be made to publish this to the domain/project workspace to which this semantic model belongs to. Personally, I favour to publish all BI semantic models to one workspace. By doing this, an easy overview is obtained, and it is easier to grant access to report builders and report consumers, which I will talk more about soon. If your organization has a Power BI premium licence, I advise to use deployment pipelines to enable added security and allow for proper testing before deploying a report to a large number of users. With deployment pipelines, you can deploy Power BI content, such as reports or semantic models, easily from one workspace to another. Therefore, you can have both dev, test and prod workspaces and assign different audiences to each workspace to allow validation of the content created.

Another reason why a split is being made between semantic models and reports is to have more security. If semantic models would be deployed to the same workspace to which the report is being published to and business users have a contributor role or higher, they would be able to modify the semantic model. This is a scenario that needs to be avoided. Therefore, access to the semantic model workspace is only given to the BI team members. I will talk more about the security and implementation of managed self-service BI in the Power BI service later.

Finally, an organization can choose to endorse and promote the semantic models build by IT. This allows for trustworthiness and reliability.

LiveConnection

Since a split is being made between semantic models and reports, report builders will need to connect to a Power BI semantic model via a LiveConnection. Semantic models that have been endorsed and promoted will appear first in the list. From here on, report builders can create their own reports with data that the BI team has created. There are advantages of doing this. Report builders can still see the underlying model and see the relationships but since they do not have access to the workspace, they are not able to modify the model in any way. In this way, multiple reports can be built on the same semantic model(s) and a single source of truth is taken.

Power BI service

Now that a split is occurring between semantic models and report, it is important that the necessary access rights are given to both the self-service report builders but also to guarantee that the consumers of your report still have access to the underlying semantic model. If both report and model were initially created in the same pbix, which is often the case in corporate BI, and you would distribute the report to consumers who have a workspace role higher than viewer in the Power BI service, they would have modifying rights to the model. However, if the semantic model and report are in two different workspaces and you don’t provide access in the semantic model to the report consumers, they would not be able to open the report anymore.

Like described above, self-service report builders will not have workspace access to the semantic model workspaces. Therefore, the following rights need to be given to the semantic models via direct access, preferably through Microsoft Entra ID groups:

• Read access to the Entra ID group of the report consumers
• Build access to the Entra ID group of the self-service report builders

If you use row-level security, make sure to add the AD group under security for each applicable semantic model

Fig 1.3 shows how to provide build rights to the self-service report builders. To enable read rights, all boxes need to be disabled. Unless you would like to notify your consumer or builder that he/she has received rights via an email. Members of the BI team naturally need workspace rights to the semantic model workspace.

Now that the self-service report builders have build rights on the semantic model, a couple of more steps need to be taken before they can publish reports to workspaces other than their personal one.

• Assign self-service report builders with a Power BI pro licence
• Creation of workspace(s) to which they can publish
• Give them a contributor (or higher) role in the self-service BI workspace.

Best practices I can share is to create an Entra ID group for the self-service report builders who need a Power BI pro licence. Another tip would be to make clear naming conventions as regards to the workspace names, audience names, Entra ID groups to clearly distinguish the self-service workspaces from the workspaces owned by the BI team.

During my project, the choice was made to provide them with contributor role in the self-service workspaces. This follows the principle of least access. With the contributor role, report builders can publish to that workspace but cannot share, publish or update an app. This setting can be disabled under advanced settings of the workspace. The choice was made in this organization to always distribute reports via apps. By doing this, the BI team remains responsible of the publication of an app. This is a choice, and different options are available if your organization has different requirements.

If the requirement is that the self-service report workspace is fully independent, a choice can be made to assign the self-service report builders with a contributor role and assign one or more business users, who will then act as team leads, with a member role. In this way, the team lead is the contact person with IT for technical questions, but they can add users to the workspace and publish new apps. More information about roles in the Power BI service can be found here.

Center of Excellence

Creating a split between semantic models and reports is a one-time action. However, the work does not stop here. Attention should be given to create a Center of Excellence (CoE). This is a key aspect of implementing and maintaining a successful Power BI governance. A CoE Is a dedicated Power BI team within the organization that managed Power BI content and supports individuals who are in any way interacting with Power BI. The team consists of a few Power BI experts who were most likely already in the BI team. First, they are the go-to contacts for self-service report builders regarding their (technical) Power BI questions. Furthermore, the role of the CoE is to provide necessary trainings on a regular interval to increase the Power BI awareness in the organization and raise the quality of reporting.

What is important is that the CoE is easily reachable. Ideally, a link should be found on a SharePoint or intranet site where users can log a ticket or ask questions. The following aspects can be available. This is a non-exhaustive list and can be filled in to the needs of each organization:

• How to get started with Power BI
• FAQ
• Guidelines (pbix template, JSON Theme, etc)
• How to request training
• How to log a ticket

Power BI is a very powerful data visualization tool that lets you build meaningful reports to gain insights into data. There are many aspects to consider. This can become a big responsibility for the BI team. To potentially gain faster insights, you can let business users create their own reports based on validated semantic models created by the BI team. This is possible via managed self-service BI. There are multiple advantages. The BI team still holds control over many aspects and will still create their own reports. Business users know the data of their domain very well and can come to potential new insights. They build reports based on semantic models that are created by experts and follow best practices. This leads to trustworthiness. However, setting up this governance can be quite complex. Key aspects of managed self-service BI are that self-service report builders will connect to shared semantic models via LiveConnection.

To achieve this, several steps need to be implemented In the Power BI service. Self-service report builders need to gain build access to the semantic models while report consumers need to have read access. Great attention should be given to assign correct workspace roles to follow the principle of least access. Finally, after implementing managed self-service BI, resources should be dedicated to building a center of excellence in the organization to support both business users as self-service report builders with all their Power BI questions. I also want to point out that I created this strategy based on the needs of the organization I worked for. This is a possible way of implementing managed self-service BI but it might be different in another organization.

Interested?

Are you interested in Power BI or do you want more information? Do not hesitate to contact us!