Power BI users are not all in the same category. If you treat everyone the same, then you wouldn’t have a successful Power BI adoption. You would likely spend too much on the training and gain much less of adoption. In this article, I’ll explain what are the different types of users and what are proper actions for each category.
There are different types of Power BI users
In the world of Power BI, there are different type of users in an organization. You have some users who are developing the model, 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 browse the report (in mobile app, or browser, or through an embedded web experience). This user might interact with the report just for filtering, highlighting, drill-through etc, but would never change or create 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 do some modifications in the way visuals presented. This request might have come from their managers, or they just themselves 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 bring 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 is the group that builds data models (and also reports) used by the rest of the organization (end-users), and also their data models are often is an important source for the report visualizers and self-service champions.
Depends on the user group, you should also have different type of access level, and different way of sharing the content with the audience. Here are some suggestions:
If you give an end-user the full edit rights to a data model and report, it can be harmful. A report visualizer just need a live connection to the data model to build visualization. Every type of user require a different level of access. Here are some suggestions;
End-users: Access the model through Power BI apps, or embedded with 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 View only access to the workspace, or even using the app are some of the methods for that. These users will not have edit access on the dataset.
Self-service champions: this group also have read-only access to the central dataset and models. However, they can IMPORT data from other sources and combine it with this model and build a new model and also report for themselves.
Central model developers: this is 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 training option usually is enough. This would include showing them how to navigate in 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 normally do this training as the module of Power BI for data analysts which takes two days. The users will learn everything about 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 is a group who wants to build their own data model, it is important that they learn about modeling in Power BI in addition to the visualization. The training for this group will take longer and includes the training for report visualizer, but also includes some parts of modeling, Power Query, and DAX. In our training program, this would be sometimes close to a week of training, 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 of course visualization. This group is very 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.
The layers and user categories are different in each organization
Each organization might have different layers. In small business, 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 what is 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 through time. You might have a report visualizer that now is interested (or his/her job function is changed) to do 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 important?
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
I’ll explain these items in another article later. please share your thoughts with me (in the comments below) about how the layer structure is within your organization and how do you deal with that?