Power BI users are not all in the same category. If you treat everyone equally, you wouldn’t have a successful Power BI adoption. You would likely spend too much on the training and gain much less adoption. In this article, I’ll explain what the different types of users are and are proper actions for each category.
There are different types of Power BI users.
In the world of Power BI, there are different types of users in an organization. You have some users who are developing the model, and you also have some who are end-users. In bigger teams, we have more layers. The diagram below shows four types of users for Power BI in an organization.
The definition of the users above is:
End-user: someone who just browses the report (in the mobile app, web browser, or through an embedded web experience). This user might interact with the report just for filtering, highlighting, drill-through, etc., but never change or create a report.
Report visualizer: this is a much smaller category than the end-user group. For this group, the currently built reports are not enough; they need to modify how visuals are presented. This request might have come from their managers, or they prefer another way of presenting that data. This group, however, will not change the data model or import new data tables. They might, however, have a few calculations added here and there.
Self-service champions: a smaller group than report visualizer. This group not only does visualization but also steps further and brings new data into the model. They might have some data sources which they want to integrate into the existing analysis, and they would do some extra calculations based on that too.
Central model developers: this is the smallest group of Power BI users in every organization. This group builds data models (and reports) used by the rest of the organization (end-users). Also, their data models are often an important source for report visualizers and self-service champions.
Depending on the user group, you should also have different types of access levels and different ways of sharing the content with the audience. Here are some suggestions:
Giving an end-user full edit rights to a data model and report can be harmful. A report visualizer just needs a live connection to the data model to build the visualization. Every user type requires a different level of access. Here are some suggestions;
End-users: Access the model through Power BI apps or embedded with a read-only option into a web application. This would ensure that these users would never be able to change the report.
Report visualizer: read-only to the dataset. However, they can build their own reports. This level of access can be provided in different ways. Using the Viewer access to the workspace or even using the app are some methods for this purpose. These users will not have edit access to the dataset.
Self-service champions: this group also has read-only access to the central dataset and models. However, they can import data from other sources, combine it with this model, build a new model, and report for themselves. They can also create a chained dataset with a DirectQuery connection to the Power BI dataset.
Central model developers are the only group with full edit access to the dataset and reports.
Each group requires a different training type because they are doing different functions.
End-users: this is the quickest Power BI training option; a couple of hours of training is usually enough. This would include showing them how to navigate the app and drill-through in reports or learn about drill down and up and some ways to get most of the existing Power BI reports.
Report visualizers: This group should be fully trained in visualization. We usually do this training as the module of Power BI for data analysts, which takes two days. The users will learn how to create useful visualizations in Power BI. There won’t be any point in training this group of users on data modeling.
Self-service champions: Because this group wants to build its own data model, they must learn about modeling in Power BI in addition to visualization. The training for this group will take longer and includes the training for the report visualizer, but it also includes some parts of modeling, Power Query, and DAX. This would sometimes be close to a week of training in our training program, but we split it into multiple sessions.
Central model developers: For this group, you would require the deepest dive Power BI training option. A deep dive training on Power Query, DAX, M scripting sometimes, Modeling, and visualization. This group is likely to be the go-to resource for the self-service champions and report visualizers when they have a question. This group also requires a bit of architecture, administration, and governance training. This group requires multiple weeks of training, which need to be split into multiple sessions.
Here is a comprehensive agenda of a Power BI training that covers all the agenda items mentioned above.
The layers and user categories are different in each organization
Each organization might have different layers. In small businesses, you often find two or three layers. The two layers can be the report developer and end users.
In larger organizations, sometimes you find layers within layers. The central developer layer can also split into Data transformation developers, data model developers, and core visualizer developers.
You should dig into the culture of users within your organization and find out the structure of layers for your organization.
Users can move between layers.
Once a user is in a layer, it doesn’t mean he/she will stay in that layer forever. Users change their function over time. You might have a report visualizer interested (or his/her job function is changed) in doing some self-service stuff. You should be ready to upskill users to ease their process of moving them to another layer.
Why knowing Power BI users is essential?
Why is it important not to mix these user groups? Or why is it important to even know these groups? Can’t we have the same training for everyone? Can’t they all use the same materials etc.? Here are some answers if you have any of these questions; if you mix all these groups together and treat them all the same, you will get to these problems very likely;
- Spending too much training budget when not needed
- Losing interest in downstream user layers
- Upstream user layers will likely start their own way of doing things
- The mix-up will hurt the governance more than anything else
- The trust in Power BI in the organization will vanish slowly
- Power BI adoption may fail