Admin API settings
Admin API settings control the use of Power BI admin APIs and the information contained within the responses from admin API requests. For more information about admin APIs, see the Further reading section in this chapter.
- Allow service principals to use read-only Power BI admin APIs: Enables or disables the ability of service principals assigned to registered Azure AD web apps to access Power BI admin APIs without having a signed-in user. The service principal must be included in an allowed security group. Enabling this setting provides the service principal read-only access to all the information available through Power BI admin APIs. Only enable this setting if necessary.
- Enhance admin APIs responses with detailed metadata: If enabled, additional information is included in Power BI admin API requests by allowed users and service principals. Only enable this setting if necessary.
- Enhance admin APIs responses with DAX and mashup expressions: If enabled, additional information is included in Power BI admin API requests by allowed users and service principals regarding the metadata about queries and expressions comprising Power BI items. Only enable this setting if necessary.
Dataflow settings
Dataflow settings control the creation and use of dataflows.
- Create and use dataflows: Enables or disables the ability of users to create dataflows. This setting can only be enabled for the entire organization. However, dataflows cannot be created in My workspace workspaces so only administrators, members, and contributors to non My workspace workspaces can create dataflows. It is recommended that you enable this setting and utilize dataflows to curate data connections.
Template app settings
Template app settings control whether users can publish or install template apps. For more information about template apps, see the Further reading section in this chapter.
- Publish Template Apps: Enables or disables the ability of users to develop template app workspaces for distribution to clients outside of the tenant. Only enable if required.
- Install template apps: Enables or disables the ability of users to install template apps created outside of their tenant. Only enable if required.
- Install template apps not listed in AppSource: Enables or disables the ability of users to install template apps not published in Microsoft AppSource. Such template apps are not validated by Microsoft. Only enable if required.
Q&A settings
Q&A settings control whether or not dataset owners are able to review questions asked by other users as well as whether synonyms can be shared between datasets:
- Review questions: Enables or disables the ability of dataset owners to review questions asked about their data via the Q&A feature of dashboards in the service or the Q&A report visual. If using Q&A within your organization, it is recommended that this feature be enabled so that dataset owners can improve their Q&A settings over time.
- Synonym sharing: Enables or disables the ability of dataset owners to share synonyms defined within their datasets with others. If leveraging Q&A, then it is recommended to enable this setting. Shared synonyms show up in the Suggested terms area when defining synonyms for a dataset. It is recommended that this setting be enabled.
Dataset security
Dataset security settings control who is allowed to republish datasets within Power BI:
- Block republish and disable package refresh: If enabled, blocks anyone except the dataset owner from publishing updates. This includes dataset deployment updates from Power BI deployment pipelines. Enabling this setting may be viewed as a security feature by organizations but carefully consider the broader implications around usability and administration before enabling this feature.
Advanced networking
Advanced networking controls whether or not users can access the Power BI tenant via a private link and/or public internet. See the Further reading section of this chapter to learn more about this feature.
- Azure Private Link: Enabling this feature can increase security by allowing users to use a private link to access the Power BI tenant.
- Block Public Internet Access: Enable this feature only in conjunction with enabling Azure Private Link as this blocks access to the Power BI tenant from the public internet meaning that users that do not have access to the private link cannot log in to the tenant.
Goal settings
Goal settings control whether or not users are allowed to create and use goals and scorecards:
- Create and use Goals: Enables or disables the ability of users to create and use goals and scorecards. Enabling this feature can be beneficial to end users.
Share data with your Microsoft 365 services
This section controls the Power BI tenant’s ability to interact with a Microsoft 365 tenant that is not in the same geographic region:
-
Allow your Microsoft 365 services to process or store Power BI data which may be outside of your Power BI tenant’s geographic area: If enabled, permits the Power BI tenant to share information with a Microsoft 365 tenant that is not in the same geographic region. This allows certain features such as favorites and
search results to function when the Power BI tenant and Microsoft 365 tenant are in different geographic regions. Only enable this feature if absolutely necessary.
Insight settings
Insight settings control the ability of users to receive automatic insights about their reports:
- Receive notifications for top insights: Enables or disables the ability for users to be notifi d about top insights for reports. Enabling this feature can be benefi al to end users.
Now that we have covered the various Power BI tenant settings, let’s next take a look at governing the deployment of Power BI content.
Deploying Power BI content
Another way in which governance is commonly enforced is through the use of a phased approach for the development and deployment of content. A common approach used in software testing and engineering is called DTAP for Development, Testing, Acceptance, and Production. The letters of the acronym denote the environments and steps used during the engineering and testing of software and the particular steps and environments used can vary between three and five.
For example, the following steps might be followed as part of a software development DTAP process:
- While the software is being developed, this development occurs in a development environment that only the software developers can access.
- Once the software is deemed ready, the software is deployed to a test environment that closely mimics the target production environment.
- If tests are completed successfully, the software is then deployed to an acceptance environment where end users can test that the software meets business requirements.
- Once acceptance is achieved, the software is finally deployed to production.
Well-governed Power BI deployments should also follow a similar DTAP process for the creation of content. Power BI query parameters and the ability to publish content to multiple workspaces facilitate this process. While a DTAP process can be performed
manually, Premium users can leverage Power BI deployment pipelines to facilitate and automate this process.
To create and use a Power BI deployment pipeline, follow these steps:
-
In the Power BI service, create a premium workspace and publish the
LearnPowerBI.pbix report to this workspace.
- Open the workspace in the Power BI service and choose Create a pipeline in the ribbon as shown in Figure 12.9:
Figure 12.9 – Create a pipeline
- Provide a Pipeline name such as LearnPowerBI and click the Create button.
-
Assign the deployment stage for the workspace as Production and click the Assign
button as shown in Figure 12.10:
Figure 12.10 – Assign a workspace to the deployment stage of the pipeline
- The pipeline is created. Under the Production stage, click on the three vertical dots in the header of the workspace and choose Deploy to previous stage as shown in Figure 12.11:
Figure 12.11 – Deploy content to previous stage
- A new workspace called LearnPowerBI [Test] is created and the content is deployed to that workspace.
- Repeat the procedure in step 5 using the Test stage in order to create and deploy content to the Development stage. This creates a LearnPowerBI [Development] workspace and deploys the content to that workspace:
Figure 12.12 – Development and Test stages of a Power BI deployment pipeline
Once a deployment pipeline is deployed between stages, green checkboxes are present indicating that the content in both stages is the same or in sync with one another. If new or updated content is subsequently deployed to the Development stage, this icon indicates that the content is not in sync and allows you to Compare the differences as shown in Figure 12.13:
Figure 12.13 – Content is different between the Development and Test stages
To deploy the updated content from the Development stage to the Test stage, simply click the Deploy button in the Development workspace. For the Production stage, instead of a Deploy button, an Update app button is present, allowing you to create or update the app associated with the workspace.
In addition to making deployment between workspaces easy, pipelines also allow you to define rules for the different pipeline stages. These rules allow you to repoint data sources, for example, from development systems to test and production systems. The ability to define deployment rules is accessed by clicking the lightning bolt icon in the header of the appropriate stage, as shown in Figure 12.13.
We have now covered many different settings and methods for governing Power BI.
Let’s next explore the important topic of promoting the adoption of Power BI throughout an organization.
Adopting Power BI
The subject of an organization adopting a disruptive technology such as Power BI is a vast and complex subject and a complete treatment of this subject is beyond the scope of this book. However, this section introduces the topic and provides the essential strategies for adopting Power BI within an organization.
Adoption as covered here is the diffusion of a disruptive technology within an organization. It means that a technology progresses from being used infrequently by a small percentage of an organization to being used by the entire organization on a daily basis. Power BI, a self-service business intelligence technology, should be viewed as a disruptive technology that must be evangelized in order to promote its use throughout an organization.
The basic underpinnings of the diffusion of technology within a society is a well-researched subject within scientifi literature, popularized in 1962 by Everett Rodger’s seminal work, Diffusion of Innovation. The diffusion of innovation theory is most often presented as a bell curve similar to Figure 12.13 where adopters are classifi d into five categories:
Figure 12.13 – Diffusion of innovation bell curve
Geoffrey Moore later extended the diffusion of innovation work by Everett Rodgers and identified an adoption chasm between the early adopters and the early majority. While Rodgers’ and Moore’s work mainly dealt with disruptive technologies adopted by society as a whole, many of the same principals and challenges apply to disruptive technologies such as Power BI when considering adoption by an organization.
Adoption strategies
If you are the first or one of the first Power BI users within your organization, then you fall into the innovators category of the diffusion of innovation bell curve. As an innovator, you are more prone to take risks and learn new technologies. As an innovator using Power BI, you understand the intrinsic business value that Power BI can bring to an organization regarding self-service business intelligence. The data analytics and visualization capabilities of Power BI can help organizations make better business decisions and improve the efficiency and effectiveness of business processes, making the business more
profitable. However, not everyone within an organization is willing to take risks, learn new technologies, or understands the potential business value of Power BI. Therefore, your first goal is to identify the potential early adopters of Power BI, but not all early adopters are created equal.
Early adopters should be considered based on their authority and influence within an organization. Early adopters who are executive leaders and/or whose opinions are
respected by their peers should be sought out when targeting early adopters because their opinions carry weight within their peer group and this influence or clout can further drive adoption by their peers. Early adopters who have little authority and are not influential within their peer groups are far less effective at driving adoption.
Once an appropriate group of early adopters has been identified, the next step is to identify a need or pain point that is compatible with a Power BI solution. This need or pain point could be many different things. For example, the need or pain point may take the form of the creation of manual processes for creating reports in Excel. A common theme is that raw data is imported into Excel, massaged, and then reported on. This process may take an hour or two every week. Power BI can help solve this problem by effectively eliminating this manual process. Another example is perhaps a regularly scheduled meeting that reviews different projects or initiatives within the organization. Often, these types of meetings require managers to review data from multiple systems in order to determine the health of each project or initiative. Power BI can help solve this problem by bringing together data from multiple source systems and reporting on that information in a visual way that makes the health of each project or initiative immediately clear. These are just two examples, but it should be clear that any task where Power BI
can save people time and energy is a good candidate because eliminating monotonous, manual effort is generally a winning theme for most individuals and organizations.
After identifying a need or pain point, the next step is to create a quick Proof-Of-Concept (POC). This POC does not have to be elaborate or even have real data behind it. Rather, the purpose of a POC is to convey the what if scenario. What if the need or pain point of the early adopter could be solved by Power BI? A simple POC that visually demonstrates the antidote or cure for the early adopter’s pain.
Assuming the POC is received favorably, the next step is to propose a business intelligence project that implements the concept demonstrated by the POC. Once this goal is reached, refer to Chapter 2, Planning Projects with Power BI, to plan and implement the solution.
Once you complete your fi st solution, it is no time to rest on your laurels. Evangelize the solution with peers and coworkers, but more importantly, repeat the process with the next pain point and/or early adopter. A single success is not likely to create the bandwagon effect necessary to hurdle the adoption chasm between early adopters and the early majority.
Repeated successes, however, can create the necessary tension and envy within other parts of the organization that allow you to bridge and eventually cross the adoption chasm.
Summary
Th s chapter diverged from the step-by-step, hands-on learning of Power BI to encompass the larger topics of the overall deployment, usage, governance, administration, and adoption of Power BI within an organization. Th s chapter explored various strengths and weaknesses of different usage models representing the big picture of how Power BI is deployed and
used within an organization. When Power BI is deployed and used by an organization, the topics of governance and administration naturally come to the fore and thus this chapter also covered important governance and administrative topics such as tenant settings and the process of deploying Power BI content. Finally, Power BI used by a single individual is powerful but when used by an entire organization can create a data culture that makes the entire organization more effi t and effective and thus we covered the topic of adoption and proposed adoption strategies that can assist in diffusing the disruptive technology of self-service analytics and business intelligence throughout an organization.
In the next chapter, we leave the big picture and organizational issues behind and focus on you, the individual, and how you can leverage your knowledge of Power BI to advance your career.
Questions
As an activity, try to answer the following questions on your own:
- What is a Power BI usage model?
- What usage model is used by many new Power BI deployments?
- What are the strengths and weaknesses of the centralized usage model?
- How do the distributed and golden dataset usage models address the weaknesses of the centralized usage model?
- What are the overall goals of governance in terms of Power BI?
- What approach is recommended when it comes to configuring Power BI tenant settings?
- How are Power BI tenant settings accessed?
- A phased approach for the development and deployment of content is called what?
- What feature in Power BI Premium enables the phased development and deployment of content?
- What is an important trait of early adopters?
Further reading
To learn more about the topics that were covered in this chapter, please take a look at the following references:
- Administering Power BI in the admin portal: https://docs.microsoft.com/ en-us/power-bi/admin/service-admin-portal
- Sensitivity Labels in Power BI: https://docs.microsoft.com/en-us/ power-bi/admin/service-security-sensitivity-label-overview
- Power BI REST APIs: https://docs.microsoft.com/en-us/rest/api/ power-bi/
- Configuring Azure Log Analytics for Power BI: https://docs.microsoft. com/en-us/power-bi/transform-model/log-analytics/desktop-
log-analytics-configure - Data classification for dashboards: https://docs.microsoft.com/en-us/ power-bi/create-reports/service-data-classification
- Tutorial: Embed Power BI content using a sample embed for your customers application: https://docs.microsoft.com/en-us/power-bi/ developer/embedded/embed-sample-for-customers
- What are Power BI template apps?: https://docs.microsoft.com/en-us/ power-bi/connect-data/service-template-apps-overview
- Private endpoints for accessing Power BI content: https://docs.microsoft. com/en-us/power-bi/admin/service-security-private-links
- Understand the deployment process: https://docs.microsoft.com/en-us/ power-bi/create-reports/deployment-pipelines-process
- Power BI adoption roadmap: https://docs.microsoft.com/en-us/ power-bi/guidance/powerbi-adoption-roadmap-overview
