Power BI for intermediates: 7 mistakes you don't want to make

As you become more experienced in Power BI, you will eventually progress from a beginner to an intermediate. At this point, you are probably somewhat comfortable and familiar with various features and aspects of the tool, and you’ve likely seen a few different scenarios in the models, reports, and other items that you’ve worked with. DAX, Power Query, and other areas of Power BI might still hold plenty of mysteries for you, but you are comfortable with the general steps and processes involved with making models, reports, or both. 

However, as an intermediate, your journey is only really just beginning. You will likely make many mistakes as you learn and expand both your professional experience and comfort zone. However, a lot of these mistakes are a lot more “big picture” than the ones you make as a beginner, as you’ll see later in this article! 

We might define an intermediate as someone who is familiar with the basic data modelling and/or visualization concepts in Power BI, as well as some core processes like sharing reports, data security, and so forth. An intermediate likely knows what a star schema is and how to make one, and understands the basic best practices involved in creating quality models and/or reports. 

To clarify, an intermediate is not necessarily someone who is equally competent in both models and reports. In fact, the opposite is true… it is quite rare to find someone who is good at both data modelling and data visualization. Typically, someone tends to favour one or the other, be it intentionally or not. This specialization is also a typical trait of an intermediate in Power BI. An intermediate recognizes that it’s impossible to be equally good at all things, and chooses certain parts of the tool that they find important or interesting to get a deeper knowledge and expertise. Sometimes this is an explicit, intentional choice. Often, though, it’s a byproduct of circumstances, where the problems and scenarios they’ve faced have forced a specialization to address those problems. 

In general, though, an intermediate has a certain competence and confidence with their tool that a beginner doesn’t have. This isn’t measured in raw, explicit knowledge, but rather the implicit understanding about the kinds of scenarios that happen, and a general awareness of the tools and features available to address these scenarios. Intermediates typically (hopefully) have acquired a certain amount of critical thinking and adaptability such that they might not have the answer, but they should possess the skills and experiences about what to do and where to go to find it.

This is by far the most common and also the most impactful mistake that intermediates make… neglecting users. Intermediates have extended their comfort zone around the tools and technology that they’re learning, but users and their business are often well outside of that comfort zone. And rightfully so! Talking with users, understanding their business, and gathering requirements is hard. But it’s also incredibly important. 

If you don’t gather the right requirements, then it’s very unlikely that you will make the right solution, even though it might check all the boxes and best practices on paper. Experience and empirical research also demonstrate that the most effective way to gather these requirements is by engaging with users to understand their perspectives and needs. If you’re looking for more information and guidance about this, see this and related articles on data-goblins.com, or the BI solution planning guidance from Microsoft (both written by Kurt Buhler). 

To summarize, not engaging with users often leads to the following: 

• Not understanding the business processes and problems you’re modelling or reporting on. 

• Assumptions and decisions that lead to ineffective models and reports that users don’t use. 

• Adoption challenges due to issues with change management, user training, and other related processes. 

• Missed requirements and mistakes that result in more change requests and bugs during testing and after release. 

It’s important that even when you might think you are engaging with users, this still might not be happening correctly: 

• You could be engaging with only a few delegated or enthusiastic people, who don’t accurately represent or reflect the real user population. 

• You could be engaging with these people ineffectively, resulting in miscommunication or misunderstanding between you and them. 

• You could be engaging with these people too infrequently, resulting in you forming a mental model about how they think and what they do that is frozen in time and doesn’t reflect new information or context.

Reports and models that some intermediates make might work well or look nice in the short-term, but might be difficult to maintain, or be unsustainable and inflexible to change. These models and reports might work well during development and testing – even upon the initial release – but they have a tendency to underperform over time as more users, data, and changes become necessary.  

• For models, this typically happens when intermediates lean on convoluted or hard-coded DAX and design patterns to solve problems, or design the model and upstream transformations in a way that considers the current business data and logic, while neglecting future inevitable evolutions and expansions of that data and logic. 

• For reports, this occurs when intermediates spend a lot of effort creating a report that looks really nice during development and in screenshots. However, these reports might perform poorly, be impractical in use, or have so many convoluted tricks and customizations that they are extremely difficult to fix or change.   

To avoid this mistake, intermediates should take a future-oriented perspective during development. It is important to consider not just the current situation, but also to anticipate future changes and evolutions of the models, reports, business, and users. Certain proactive steps should be taken to safeguard against possible errors, make changes easier to make, and avoid disruptions. 

These considerations often lead to more development time and effort but consequentially result in less cost to changes and issues down the line. Furthermore, ensuring more robust and sustainable models and reports can also result in better adoption, since users will find these models and reports more trustworthy.  

Related to the previous points, many intermediates and technical teams define success in a Power BI project as deploying and releasing the model and reports. Once the report is in the hands of the users, it’s done. Success! Right?  

Wrong. The best definition of success for a Power BI project is when the reports and models are delivering value for the business; they’re being used. A common mistake is when intermediates create reports and models, but don’t even know if these models and reports are being used. Tracking the usage of models and reports is essential to get information about whether they’re having an impact or not. 

Some tips to avoid this mistake: 

• Define proactively who the users are, and how frequently you expect them to use reports 

• Actively follow up with usage metrics, either using the out-of-the-box usage metrics reports or other solutions, like the admin monitoring workspace reports, custom solutions, or third-party tools. 

• Filter out developers and support teams from usage metrics so that they don’t contaminate the data and show false trends 

• Interpret the data in a context. Just because there’s a downward trend doesn’t mean anything negative for the tool, such as when there’s a holiday or a slow time for the business. 

• Engage with users regularly to gather qualitative feedback, get input to drive adoption, and help users use the reports. This article explains one way to do this. 

As intermediates become familiar with the patterns, features, and tools they use to solve certain problems, they also develop preferences and opinions. This is normal, but there’s a tendency to over-generalize and sometimes over-commit to these things. Sometimes, intermediates (and even experts) can become dogmatic, 

Intermediates are also often looking for the “best” solution for a particular problem when the truth is that none might exist. Each solution or approach could have pros and cons that must be weighed and have a different level of impact, depending on the circumstances. Here are a few examples: 

• Rigid adherence to rules, like “never use pie charts” or “never use calculated columns”. 

• Dismissal of third-party tools; using only first-party tools when alternatives can help. 

• Inflexibility to consider alternative, “less optimal” solutions that could still be the best and simplest approach for their scenario or problem. 

To avoid or mitigate this mistake, intermediates should remain open-minded to alternative approaches, and ensure that they are both critical and sceptical, focusing on understanding their problem and taking a solution-oriented mentality to solve it.

A key progression in the maturity of a Power BI developer is to shift their thinking from models/reports to a layered approach with stages. In other words, a common mistake is that intermediates typically neglect to think of the lifecycle of their model and report throughout not only development, but also afterward when it’s used, updated, and eventually retired and archived. If you want more information about the lifecycle of models and reports, it’s covered in-depth in this documentation from Microsoft. 

This is a mistake because it can lead to issues like:  

• Trying to do everything in Power BI, when it might be better to push transformations to other upstream Fabric items like dataflows, data pipelines, or notebooks, and store data in a lakehouse or data warehouse. 

• Avoidable mistakes and regressions in reports or models due to using the same workspace for development, testing, and distribution. 

• Difficulties collaborating with other creators / developers, and issues with merging changes and conducting parallel work. 

• Not having a formal or structured process for testing/validation, deployment/release, etc., can lead to chaotic and stressful projects. 

You can mitigate or avoid this mistake by: 

• Investing time and effort into discussing and defining processes for the different lifecycle stages for your models and reports. 

• Having an intentional workspace strategy to separate content by purpose, item type, development stage, or all three. 

• Using approaches for version control, such as OneDrive refresh, Git integration, or custom source control solutions. 

• Using approaches to facilitate deployment of models and reports between workspaces, such as deployment pipelines, Git integration with branching strategies, or custom solutions. 

Testing is critical to ensure that the models and reports you make are high-quality. Sometimes, testing means that you need to fix bugs, or to make changes to optimize a model or report, either to improve its performance or its experience. This is a normal part of development for most Power BI projects of varying sizes, from small team projects to enterprise deployments. 

However, the unfortunate reality is that many, many, projects will under-invest in this testing and development or even neglect it entirely. Testing is often left to a few days and a handful of individuals without any structured process or clear outcomes in mind. The result is often reports and models that underperform, and an intensive period of user feedback and “hyper care” with a lot of rushed changes after a disappointing release. 

To avoid this, you want to ensure that you clearly understand the importance of testing and optimization and define how you will approach it. This is something that varies greatly depending on a wide range of variables, so we can’t offer you prescriptive advice that would be helpful in a few paragraphs or bullet points.   

Here are some resources for optimization: 

• Optimization guide from Microsoft (free). 

• Optimizing DAX video course from SQLBI (paid). 

Here are some resources for testing: 

• Validate content (testing models and reports; Microsoft Learn; free). 

• Power BI migration guidance (free). 

• John Kerski – Making Your Power BI teams more Analytic (Blog Series). 

To their own detriment, once someone becomes familiar with a tool or technology, they can become too comfortable with what they know and neglect newer or different approaches. For intermediates with Power BI, they can settle with the features and approaches that they use now, and neglect learning about newer options that arise. They might also avoid pushing themselves to get a better or deeper understanding of the current challenges in their team, organization, or in the market. 

When intermediates stop learning, they can end up in uncomfortable situations where they’re ill-equipped to deal with new scenarios and problems that arise. Worse, they might defer to approaches and features out of habit and preference, rather than opting for a choice that would be the most effective and useful for all involved. This can lead to a lot of frustration and wasted time or resources. 

Sometimes – like in consultancy firms – intermediates might feel like this learning should come to them; like their primary source of learning should be formal trainings, seminars, or workshops. This is common because these formal, organized sessions are how most beginners get their knowledge and grow to become intermediates in the first place. However, once reaching that “intermediate” milestone (and debatably well beforehand), Power BI professionals should feel encouraged to take accountability for their own learning. 

By actively and continuously learning, intermediates can grow not only their knowledge, but also their careers. They can equip themselves with the tools and skills to solve new problems and scenarios that they’ve not yet encountered.  

A good way to avoid this mistake is the following: 

• Follow-up with regular blog posts from the Power BI and Fabric teams. You don’t have to read or understand them in their entirety; just skimming for keywords is usually sufficient. 

• Try out new preview features with sample data or in a sandbox environment so that you can evaluate what it does, how it works, and more importantly, why you might use it. 

• If you have time and energy, consider creating a portfolio project with personal or sample data, or follow-up with some of the regular community challenges like Workout Wednesday. 

Here are some other common mistakes that intermediates might make, which we didn’t have the time to elaborate on in this short article: 

• Assuming that Power BI reports – or Power BI at all – is the right tool to solve a problem. Sometimes, Power BI just isn’t the best option. It depends on the scenario and context, and it won’t necessarily be the best tool for every individual, team, or organization. 

• Over-reliance and over-confidence in the answers from generative AI tools. 

• Under-estimating the time it takes to create and deliver useful reports, either due to under-estimating the complexity of the business and its users or over-simplifying the report design and creation process.  

• Over-emphasizing design and aesthetics in reports and dashboards, over their usefulness. 

• Not commenting complex DAX or Power Query code, or adding descriptions to tables and fields in the model. 

• Sharing reports directly rather than via a workspace app (Power BI Pro or PPU) or Fabric Org App (if you have Fabric). 

• Under-estimating the complexity of licensing and distribution, particularly when embedding and external users are involved. 

• Not considering the performance impact of Row-Level Security on models and reports.