Governed Self-Service: a Power BI Rollout

Governed Self-Service: a Power BI Rollout

Power BI has gained a lot of op popularity in the past years. Due to the large portfolio of functionalities and the high customer adoption, Power BI has become the preferred go-to tool for analytics and reporting. In the first steps of a self-service tool rollout, the tool is provided to the business users and some training is provided. These users publish their first report on a ‘workspace’, a report that probably never will be opened again! Months later, additional workspaces have been created named ‘Test Test’ containing reports such as ‘Sales V3 Final.pbix’. The so-called self-service heaven has evolved in a graveyard of try-out reports. This article will provide no-nonsense tips and tricks on a governed approach of rolling-out self-service. 

To Power BI or not?

The first question that should always be made, is whether this report really needs to be in Power BI? By default, operational systems already provide a set of tools that allow to filter and visualise the data stored in the application. If the operational system can address the business question, then why not use the default reporting tool? Do not make the mistake of migrating each report to Power BI! When should it be in Power BI? Here is a list that addresses that specific question:

  • Latency: It is allowed to have latency between the operational system and the reporting system. In most scenario’s, Power BI reports are only refreshed once a day.
  • Performance & Complexity: If the business question or reporting need contains a lot of complexity, there are scenario’s in which the operational system is so highly pressurized that it impacts other users. Offloading this to Power BI will improve the efficiency for both the operators of the application and those consulting the report.
  • Multi-Source & Added Logic: Power BI does allow to combine/blend other sources and add additional logic, this is often not the case in your operational systems.

Report creators should be encouraged to consider if it wouldn’t be a better scenario of housing the report in the operational system itself or if Power BI would be the better place.

User personas in Power BI

It is easy to explain the Power BI users as group of 100 users:

  • 75 Report Consumers: This large group of users is only able to use the ‘app’ functionality in Power BI Service in which it can use the provided filters, mark ‘filter combinations’ as a personal bookmark and drill through to other pages. This user is not part of a workspace and thus cannot make alterations to any report.
  • 20 Ad-Hoc Report Creators: These users are members of a workspace in which the members can edit Power BI content. Business users can connect to up-to-date data sources within this workspace, blend additional sources and add custom logic to result in a ‘sandboxed solution’. These report creators sell their ideas (= Power BI results) to the business responsible which triggers a debate with the Business Responsible. Once the Business Responsible is convinced that the new insights are value added for the organization, he then takes further actions.
  • 3 Business Responsibles: These guard the quality of the created reports. Once an ad-hoc report has proven to be useful, it translates the requirements to the BI developer which then recreates/optimizes the logic for daily use. The Business Responsible could decide to transfer the ‘sandboxed report’ to the ‘app environment’ or make slight alterations to existing reports within the app environment to result in the same insights.
  • 2 Report Developers: The report developer are experts in working with Power BI and these persons doesn’t necessarily need to have expert domain knowledge upon the reports he creates. This report developer needs to make sure that the reports are designed in the ‘App Workspace’ in such a way that refresh-stability, correctness and performance can be guaranteed. Technical terms such as ‘Cross-Filtering’, ‘DAX’ and ‘Row Level Security’ do not fear him or her.

The report creation process

Following steps describe the process from creation to consumption of a report. It is not uncommon that ‘back-and-forth-hopping’ happens between several steps.

  • Firstly, a report is created in the sandbox by an ad-hoc report creator. This report can be created using SQL databases combined with Excel files and other sources. The calculations may be persisted and some dirty-solutions are applied. For the creator, this report results in added value.
  • The report creator then has a meeting with the Business Responsible and explains why and how this new view improves the business processes within the organization. If the business responsible is convinced, he requests the BI developer to have a look at this sandbox report.
  • The BI developer applies best practices in data-modelling, data visualization, filtering, etc. He/She also makes sure that the sources are accessible and stored in logical places (= minimize the chance that ‘manual files’ result in errors). He then deploys this refurbished version within the app-workspace but marks it as ‘not included within the app’.
  • It is the task of the Business responsible to have a second look at it, validate the numbers and the visualisations and update the reporting portfolio (e.g. Azure Data Catalog).
  • As a last step, the new report gets communicated to the consumers of the app by the business responsible, which finishes the report creation process. Within meetings, only the reports published throughout the app may be used, as these are validated by the business responsible and the numbers are confirmed to be correct.

Working with multiple domains, how?

 If you have multiple domains within your organization (e.g. Sales and Finance), then just duplicate this framework per domain. You’ll then have two workspaces (a sandbox and an App) and a business responsible for each domain.


Most organizations use the standard pro-licensing, in which each user is assigned a ‘Power BI Pro’ license. For very large organizations, it can be economically better to opt for the ‘Power BI Premium’ licensing. Going ‘Premium’ allows you to pay one fixed fee which allows the ‘Report Consumers’ to consult the ‘Power BI App’ for free. However, organizations that do use the ‘Premium’ option still need to pay a ‘Power BI Pro’ license for those that need to work within the workspaces. As you can imagine, the different roles described above fit perfectly into an organization that allows to ‘start Pro’, and ‘grow Premium’ if required. 

Final notes

This article describes one of our proven ways of both enabling self-service within the organization and keep it governed. The framework can help your organization getting started with Power BI, oftentimes slight alterations are made to personalize it per organization. In need of some help? Do not hesitate to contact Lytix or directly the author Sander Allert and he will be glad to exchange ideas on this subject!

Sander Allert

Sander Allert is an experienced BI architect with a passion for following new trends. Sander is passionate about data in all of its aspects (Big Data, Data Science, Self-Service BI, Master Data, …) and loves to share his knowledge. Do you need help on architectural decisions, do not hesitate to invite Sander over for a coffee to share some ideas.