Even great tools have problems. Power BI is a great tool, as proven by its rapid adoption, robust performance, and native cloud platform. But it's those who know a platform best can acknowledge its weaknesses while appreciating its strengths. So this isn't intended as a "bash", just an honest assessment of things to consider, especially when planning a new Power BI initiative.
Inherent by design
Some problems are baked right into Power BI's DNA. This isn't too surprising; easy problems can being solved in monthly releases. These problems stem from the very earliest design decisions, when "Power BI" was just a twinkle in Amir Netz' eye. Ironically, many of the features that put the "power" in Power BI can also be the roots of the issues
A twinkle in Amir's eye
This is not a comprehensive list, nor is it a "hit piece" on Power BI. Rather, this is an expression of common frustrations and limits that we consider "must know" factors:
- Power BI is not one tool.
- DAX is inescapable, though sometimes hidden.
- DAX is actually not that easy or simple... at first.
- Design flexibility often implies architectural costs and complexity; e.g., you don't have to import data, but practically, you often must.
- Visual design is more of a suggestion than something you can specify exactly.
- Reports can be configured, but they cannot act.
- Power BI is designed to span from individual work to organization-wide distribution.
- The admin and monitoring tools are second-class.
Let's look at each problem.
Power BI is not one tool
Power BI is at least three discrete tools, and that's just looking at Power BI Desktop. Power BI grew out of three Excel add-ins: Power Pivot became the Power BI data model (and is also the SSAS/AAS Tabular model); Power Query became ... well Power Query is still called Power Query; Power View became the Power BI report canvas (but now there are also Paginated reports, which are SSRS reports (to address this confusion between report types, one author (Greg, it's Greg) suggests we should bring back the name "Power View" to refer to interactive reports, as opposed to Paginated)). There are also additional tools and features in the Power BI Service, such as Dashboards, Apps, Excel workbooks, Dataflows, and much more coming soon to the same UI with Fabric.
Thus, it is very difficult to define what makes someone good at Power BI. If you are "good at Power BI", does that mean you are a visualization specialist? An expert at data modeling? A DBA (of SSAS Tabular, not a traditional RDBMS)? An ETL engineer? A reporting administrator? In many BI environments, these roles would belong to different individuals using different tools.
Power BI includes at least four programming languages: M for Power Query, VBScript in Paginated reports, JavaScript for custom visualizations, DAX (oh DAX! Every Italian's favorite language is the subject of our next two problems in Power BI). Beyond these, you may need to use SQL as a native language for source queries or R or Python in Power Query or their respective visuals. Many programmers can spend a career writing just one or two languages, yet Power BI makes a half dozen readily available and useful. Power BI is not "a tool", but a platform that consists of a suite of tools. It is unreasonable to expect a single person to be expert in all that Power BI offers.
Power BI comprises many tools, and so needs a team to be expert in every aspect. Do not make the mistake of underestimating what it means to adopt Power BI.
DAX is inescapable
Contrary to what Microsoft, Gartner, and other industry sources would lead you to believe, Power BI is a database tool first and foremost, not a visualization tool. You can open up Power BI Desktop and do lots of work in Power Query/M and in the data model, without ever needing to touch a report page or viz; it is impossible to render any viz without the work having been done first to create a data model.
The data model may be an import model, a DirectQuery model, a Fabric Direct Lake model, or some combination of these with Composite models and Hybrid tables available. The inescapable truth is that there will be a data model; your viz will generate DAX queries against that model; there will be DAX.
If you are adopting Power BI, you are going to need to become at least familiar with DAX and the Tabular model, if not deeply familiar. This compounds with the next Power BI problem.
DAX is actually not that easy or simple
We've heard it said that "DAX is simple, but not easy." It was said by the guys who teach DAX in their excellent book, so I give a lot of credence to that statement. However, to the DAX novice bringing experience from Excel (most likely) or perhaps SQL, Python, or another BI tool, DAX may as well be from another planet.
The same DAX expression used in two different places in the same Power BI report can give two different results. That's basically the definition of DAX (Greg would call it "tautological") but beginners to DAX call it, "WHY!?!" It can feel a lot like playing the card game Mao for the first time; you know there must be rules but you cannot understand them until someone tells you what they are!
DAX is a language for querying Tabular data models (backed by the VertiPaq storage engine, another deep topic for another day). But it's always discovered in the context of building a visualization. And really, until you understand how those data models work, DAX is just plain confusing. So you will reach a point where you simply must stop trying to change your DAX until it works, and instead take a few hours to research and understand evaluation context. Once you do, DAX starts to make a lot more sense.
Coming from a programming background, I (Brent) tended to believe that most languages were alike, with most of the differences being in syntax, convention, and implementation specifics on memory management and other common tasks. However, many of them are built for different purposes and on different layers of abstraction. C# and Python are general purpose programming languages designed to programmatically represent different layers of computer architecture like network, storage, and compute. SQL is a language optimized for querying and manipulating rows in tables in an relational database management system (RDBDS). And DAX is a language for querying Tabular data models in various contexts. Unless you've done that before, you have a learning hump to get over to really unlock the "power" in Power BI.
Greg has an excellent write up on his personal blog here if you'd like to check out his full rant on this topic. For now, just know that there will come a point (or many) that DAX will seem inscrutable. But once you know the rules, it does become easier. Easy just comes with practice.
You may not get the exact visualization you want
Many times a team begins a data visualization effort with a very clear picture of exact the data visualization they want to create. This can pose a challenge in Power BI. You can make many useful visuals, and there's a chance that you can create an alternative visual that will communicate the exact same information as your grand vision. But will it look exactly like the beautiful mock up you built in Adobe Illustrator? There's a good chance it probably won't, especially using only out-of-the-box visuals.
Power BI launched in 2015. It replaced Excel Power View, which was a Silverlight add-in. When the Excel add-ins became Power BI, they got to keep Power Query and Tabular and DAX, but the visualization layer was a complete rewrite into HTML and JavaScript. So they got to keep the progress made from 2010-2015 with the data engine technologies, but the data visualization technologies were brand new. There was catch up to do on the visualization front. A lot of early development and new features in Power BI visuals was building what many would consider to be basic functionality.
The paradigm of Power BI visuals is that each type of visual is an island unto itself. They share many common properties, but a visual can have any unique set of properties. It's been a years-long process even to make sure that all the visuals can support the same font sets. That means if you are coming in with a pixel-perfect wire-frame with spacing and fonts specified, you might struggle to recreate it precisely.
Workarounds to this come in the form of custom visuals. You can turn to flexible code-generating tools like charticulator or embed custom visuals in R or Python. There are more and more excellent options in the Business AppSource store for Power BI visuals, though figuring out the capabilities and licensing of each one can be painstaking.
But to get exactly the behavior and look you want, you are very likely to have to turn to creating your own custom Power BI visual. If you are a web programmer, this is actually not all that difficult. It's all JavaScript, HTML, and CSS, just dealing with data structures that are well documented and packaged up in specific ways.
The simplest solution to this, however, is simply to change what you want. Again, you can almost always get very close and achieve a similar outcome using the default supported visuals that will tell the same story and, best of all, be supported by Microsoft – not you – as part of your ongoing Power BI licensing costs. When you are planning Power BI report development, keep in mind that it is not a pixel-perfect reporting tool.
Power BI reports cannot act
Power BI reports consist of visualizations on a canvas. As discussed above, viz generate DAX queries: this is the only intelligent thing viz can do. The way that viz graphically represent data is up to the viz developer (e.g., bars or columns). There are also many properties for each viz. Some of those viz can be conditionally formatted. Conditional formatting is controlled by DAX: you can define simple rules based on the value of an additional measure added to the query. Complex behavior in conditional formatting requires you to put all of the logic into a DAX measure. No matter how complex the DAX, though, conditional formatting just allows you to change some properties of a single visual. Conditional formatting is constrained to operate only on a subset of properties that Microsoft has chosen to support, and can only operate based on the result of a measure in the viz's own query.
Bookmarks allow you to save some state of the report – specifically page, data selections, and viz visibility – and recall that state at a later time. We will mention the UI challenges of working with bookmarks in complex reports, but otherwise not belabor that specific point. The UI can be improved, whether natively or by an external tool, much more easily than the core behavior can be changed. There can be no dependencies among bookmarks or logic to be implemented when their state is recalled. Bookmarks are constrained to recall a hard-coded state.
Buttons can be bound to one of several navigation actions, such as a bookmark, page navigation, or drill-through, but not multiple. Buttons are constrained to implement one hard-coded action.
People often want to build more sophisticated behavior in Power BI, and run into the constraints of these three report elements (conditional formatting, bookmarks, and buttons). The evaluation model of a Power BI report, though, is that a user performs an action and all queries for the page are run concurrently. There is no logic that happens before or after the queries all run. There is no place to implement logic, other than in the DAX measures that are used in individual viz.
Thus, it is impossible to implement a behavior that depends on the state of the report. It is impossible to make a drill-through button that will go to one of two pages depending on which viz has a selection in it. It is impossible to conditionally hide one viz based on selections in another. It is impossible to change a viz's own title or properties based on selections made in that self-same viz – i.e., conditional formatting cannot be based on selections in the viz that the conditional formatting is applied to.
The brief hints of behavior we get in Power BI largely come from DAX measures. This is its own problem, as the database (SSAS Tabular is a relational database; Power BI data models are Tabular databases) layer needs to have intimate knowledge of how the presentation layer (reports) will lay out specific visual elements, and the report author must be able to write gnarly queries (in the form of DAX measures) to change basic viz properties. Power BI's growth seems not to be hindered by this limitation, but all large Power BI deployments I have seen eventually run into this problem: they want to build a more web-application-like experience, but are limited by Power BI reports' lack of behavior.
Power BI is designed to span from an individual to an organizational scale
Power BI is sold as a self-service BI tool. Power BI is sold as a tool for citizen developers. Power BI is sold as an enterprise BI platform. Power BI is sold as a suite of tools and capabilities for BI professionals. Power BI is designed to support sharing and easy distribution of content. Power BI is designed to be viral within an organization. Power BI has been massively successful at growing within organizations.
Many of Power BI's features are designed with row-level security in mind; it is totally fine to share a potentially-sensitive report widely if RLS is configured properly, because only allowed users will see allowed data. This ease of sharing can create security concerns if RLS is not implemented properly on datasets. It is difficult to fully lock down sharing and distribution in Power BI without also destroying its value as a self-service tool and a tool for citizen developers.
Power BI is designed with a high priority on sharing and distribution. In our experience, organizations that try to treat Power BI as a fully centrally managed platform do not see good adoption across their organization. If you adopt Power BI, you need to have a strategy and approach for governance at scale in a self-service environment.
Administrative and operational tools are lacking
Microsoft captures a wealth of data and metadata about your Power BI tenant. They make some of this data available via the Service UI, through the admin portal, and via the Capacity Metrics App. That said, there is much more data available behind the Power BI REST APIs and Log Analytics. Data retention is limited for the APIs and expensive for Log Analytics. Getting the full value from the operational data Microsoft captures for your Power BI tenant is a full reporting project in and of itself and with plenty of ongoing maintenance as the Service expands.
The Power BI Service offers minimal automation or configuration and essentially no bulk editing features. The API surface area covers almost all of the operations you may want to automate and the maintenance and editing actions you may want to perform in bulk. Anything you may want to do on this front will require you to script everything yourself.
If you want to adopt Power BI and operate at scale, you will need to build or buy the tooling necessary to do so successfully.
Conclusion
Power BI truly is powerful, but it is not without fault. This article represents a collection of challenges the authors regularly face. If you find yourself frustrated with your Power BI work, that is totally natural. You are not alone. We all feel that way sometimes. Feel free to reach out to us at hello@powerbiops.com to share your frustrations or problems with Power BI.
Sponsored
Disclosure: the authors of this article and editors of Power BI Ops are partners and co-developers of this product.
If you would like whole-tenant monitoring for Power BI at your organization, check out Argus PBI. We provide a single, unified view into all activity (refreshes and user activity) and end-to-end security lineage.
