Power BI usage scenarios: Customizable managed self-service BI
This article forms part of the Power BI implementation planning series of articles. This series focuses primarily on the Power BI workload within Microsoft Fabric. For an introduction to the series, see Power BI implementation planning.
As described in the Fabric adoption roadmap, managed self-service BI is characterized by a blended approach that emphasizes discipline at the core and flexibility at the edge. The data architecture is usually maintained by a single team of centralized BI experts, while reporting responsibility belongs to creators within departments or business units.
However, when the core data architecture doesn't include all data required, semantic model (previously known as a dataset) creators can extend, personalize, or customize existing shared semantic models. New specialized semantic models can be created that meet business requirements not met by existing centrally delivered semantic models. Importantly, there's no duplication of core data. This usage scenario is called customizable managed self-service BI.
This customizable managed self-service BI scenario is the second of the self-service BI scenarios. This scenario builds upon what can be done with a centralized shared semantic model (that was introduced in the managed self-service BI scenario). A list of all scenarios can be found in the Power BI usage scenarios article.
For brevity, some aspects described in the content collaboration and delivery scenarios topic aren't covered in this article. For complete coverage, read those articles first.
The following diagram depicts a high-level overview of the most common user actions and Power BI components to support customizable managed self-service BI. The primary focus is on providing content creators in the business units with the ability to create a specialized data model by extending an existing shared semantic model. The goal is to achieve reusability whenever possible and to allow flexibility to meet additional analytical requirements.
The scenario diagram depicts the following user actions, tools, and features:
|Semantic model creator A develops a model using Power BI Desktop. For a semantic model that's intended for reuse, it's common (but not required) for the creator to belong to a centralized team that supports users across organizational boundaries (such as IT, enterprise BI, or the Center of Excellence).|
|Power BI Desktop connects to data from one or more data sources.|
|Data model development is done in Power BI Desktop. Additional effort is made to create a well-designed and user-friendly model so it can be used as a data source by many self-service report creators.|
|When ready, semantic model creator A publishes their Power BI Desktop file (.pbix) that contains only a model to the Power BI service.|
|The semantic model is published to a workspace dedicated to storing and securing shared semantic models. Since the semantic model is intended for reuse, it's endorsed (certified or promoted, as appropriate). The semantic model is also marked as discoverable to further encourage its reuse. The lineage view in the Power BI service can be used to track dependencies that exist between Power BI items.|
|Data discovery in the data hub is enabled because the semantic model is marked as discoverable. Discoverability allows the existence of a semantic model to be visible in the data hub by other Power BI content creators who are looking for data.|
|Semantic model creator B uses the data hub in the Power BI service to search for discoverable semantic models.|
|If semantic model creator B doesn't have permission, they can request Build permission on the semantic model. This starts a workflow to request Build permission from an authorized approver.|
|In Power BI Desktop, semantic model creator B creates a live connection to the original shared semantic model that's located in the Power BI service. Since the intention is to extend and customize the original semantic model, the live connection is converted to a DirectQuery model. This action results in a local model in the Power BI Desktop file.|
|Power BI Desktop connects to data from additional data sources. The goal is to augment the shared semantic model so that additional analytical requirements are met by the new specialized semantic model.|
|Relationships are created in Power BI Desktop between the existing tables (from the shared semantic model, also known as the remote model) and new tables just imported (stored in the local model). Additional calculations and modeling work is done in Power BI Desktop to complete the design of the specialized model.|
|When ready, semantic model creator B publishes their Power BI Desktop file to the Power BI service.|
|The new specialized semantic model is published to a workspace dedicated to storing and securing semantic models that are owned and managed by the department.|
|The specialized semantic model remains connected to the original Power BI shared semantic model. Any changes to the original shared semantic model will affect downstream specialized semantic models that have dependency on it.|
|Other self-service report creators can author new reports connected to the specialized semantic model. Report creators can choose to use Power BI Desktop, Power BI Report Builder, or Excel.|
|Report creators create new reports using Power BI Desktop.|
|Reports are published to a workspace dedicated to storing and securing reports and dashboards.|
|Published reports remain connected to the specialized semantic model that's stored in a different workspace. Any changes to the specialized semantic model affect all reports connected to it.|
|To connect to data sources that reside within a private organizational network, an On-premises data gateway is required for data refresh.|
|Power BI administrators oversee and monitor activity in the Power BI service.|
The following are some key points to emphasize about the customizable managed self-service BI scenario.
Shared semantic model
The key aspect of making managed self-service BI work is to minimize the number of semantic models. This scenario depicts a shared semantic model that contributes towards achieving a single version of the truth.
For simplicity, the scenario diagram depicts just one shared semantic model. However, it's not usually practical to model all organizational data in a single semantic model. The other extreme is to create a new semantic model for every report, as less experienced content creators often do. The goal is to find the right balance, leaning toward relatively few semantic models and creating new semantic models when it makes sense to do so.
Augment the initial shared semantic model
Sometimes self-service creators need to augment an existing semantic model with, for instance, additional data that's specific to their department. In this case, they can use DirectQuery connections to Power BI semantic models. This feature allows for an ideal balance of self-service enablement while taking advantage of the investment in centrally managed data assets. The scenario diagram depicts a DirectQuery connection. The act of converting a live connection to a DirectQuery connection creates a local model that allows new tables to be added. Relationships can be created between tables from the original shared semantic model (the remote model) and new tables just added (the local model). Additional calculations and data modeling can be done to customize the new data model.
This scenario highlights reusing a shared semantic model. However, sometimes there are situations when data modelers want to limit the creation of downstream data model. In that case, they can enable the Discourage DirectQuery connections property in the Power BI Desktop settings.
Semantic model endorsement
Because shared semantic models are intended for reuse, it's helpful to endorse them. A certified semantic model conveys to report creators that the data is trustworthy and meets the organization's quality standards. A promoted semantic model highlights that the semantic model owner believes the data is valuable and worthwhile for others to use.
It's a best practice to have a consistent, repeatable, rigorous process for endorsing content. Certified content should indicate that data quality has been validated. It should also follow change management rules, have formal support, and be fully documented. Because certified content has passed rigorous standards, the expectations for trustworthiness are higher.
Semantic model discovery
The OneLake data hub helps report creators find, explore, and use semantic models across the organization. In addition to semantic model endorsement, enabling semantic model discovery is critical for promoting its reuse. A discoverable semantic model is visible in the data hub for report creators who are searching for data.
If a semantic model isn't configured to be discoverable, only Power BI users with Build permission can find it.
Request semantic model access
A report creator might find a semantic model in the data hub that they want to use. If they don't have Build permission for the semantic model, they can request access. Depending on the request access setting for the semantic model, an email will be submitted to the semantic model owner or custom instructions will be presented to the person who is requesting access.
Publish to separate workspaces
There are several advantages to publishing reports to a workspace different from where the semantic model is stored.
First, there's clarity on who's responsible for managing content in which workspace. Second, report creators have permissions to publish content to a reporting workspace (via workspace admin, member, or contributor roles). However, they only have Read and Build permissions for specific semantic models. This technique allows row-level security (RLS) to take effect when necessary for users assigned to the viewer role.
Dependency and impact analysis
When a shared semantic model is used by other semantic models or reports, those dependent objects can exist in many workspaces. The lineage view helps identify and understand the downstream dependencies. When planning a semantic model change, first perform impact analysis to understand which semantic models or reports should be edited or tested.
Typically, a data gateway is required when accessing data sources that reside within the private organizational network or a virtual network. The On-premises data gateway becomes relevant once a Power BI Desktop file is published to the Power BI service. The two purposes of a gateway are to refresh imported data, or view a report that queries a live connection or DirectQuery semantic model.
For customizable managed self-service BI scenarios, a centralized data gateway in standard mode is strongly recommended over gateways in personal mode. In standard mode, the data gateway supports live connection and DirectQuery operations (in addition to scheduled data refresh operations).
The activity log records user activities that occur in the Power BI service. Power BI administrators can use the activity log data that's collected to perform auditing to help them understand usage patterns and adoption. The activity log is also valuable for supporting governance efforts, security audits, and compliance requirements. With a customizable managed self-service BI scenario, it's particularly helpful to track usage of the original shared semantic model as well as dependent semantic models.
In the next article in this series, learn about reusing data preparation work with dataflows in the self-service data preparation scenario.