Colleagues: if I have sent you to this post, it is because I respect you and want to make sure we use common language communicating about our Power BI project. This post is written with an audience in-mind who may be less familiar with Power BI than those of us immersed in the product all day long. Not intending to be critical or insulting but to help align our customers, and Sales, Contract and Project Management teams who write services contracts, proposals and customer communications.
Using common language is critical but often trivialized, when describing requirements, deliverables and project expectations. When people are working together, depending on each other to complete important tasks, they must have a clear understanding of the common language and terminology. It is usually only after a word, phrase or abbreviation has been used with an assumed meaning that we realize the error and have gotten ourselves into trouble. Often, on a daily basis, I review project proposals and requirement documents containing inaccurate language related to Power BI project work. I also getting a lot of virtual eye-rolling when correcting seemingly inconsequential language. But I can also cite many cases when subtle misinterpretations became costly mistakes.
Why is this important? As service providers, we engage with customers using documentation, such as a Statement of Work (SOW), services agreement and requirements specifications. If an important document like an SOW isn’t accurate, it promotes a lack of confidence, confusion and unnecessary rework. Or, even worse; it may not be legally binding. If challenged, the details do matter quite a lot.
"When I said that I wanted a Dashboard with a Column Chart on a tab, I really meant that I wanted a Report Page with a Bar Chart."
Power BI Object Names
Our documentation, requirements and internal communication must align to the official product documentation from Microsoft. If not, then using different words to describe expectations will result in confusion and potential cost overruns. There is enough opportunity for mistakes when using the right terminology, which is compounded when making up our own language.
The product name: Power BI
This first item is the most fastidious, so indulge me as we get this out of the way. The name of our product is Power BI (with a space). It is not PowerBI and it is not PBI. Is this a minor point? …yes. Trivial? …perhaps but using the product name correctly and consistently demonstrates that we know how to at least spell the product name as it conforms with official Microsoft documentation. Admittedly, Microsoft have many different products inconsistently named with two capitalized words that may or may not have a space between them. Unlike PowerPoint and SharePoint, Power BI includes a space.
Reports and Dashboards
The visual user experience for Power BI is called a Report and not a Dashboard. Again, this may seem trivial, but it is important, not only because it is inaccurate, but there is such a thing as a Power BI Dashboard… which is quite different than a report. As not to challenge and correct my customers, when someone tells me that they want to create a Dashboard, I will usually clarify by asking if they want to create a “dashboard-style report”, and then document the requirement as a Report. Nearly all Power BI projects include at least one report, and a fraction of those projects might also include a dashboard.
The functional and differences between Reports and Dashboards is described in detail here.
The individual visual presentation layers within a report are referred to a Pages. A single report can have as many Pages as is practical. Some people might refer to report pages as Tabs, since each report page displays a labelled tab at the bottom of the screen in Power BI Desktop. Similarly, an Excel Workbook consists of multiple Worksheets, which some users incorrectly refer to as tabs. However, for a published report viewed through a web browser, page navigation is performed using page labels listed in a panel to the left of the report canvas and there is no concept of “tabs”. Therefor the term “Tabs” is both inaccurate and confusing.
Semantic Data Model
Also called a Tabular Model or Power BI Data Model, every Power BI project contains a data model consisting of multiple tables and relationships. When a Power BI Desktop (PBIX) file is published to the service, the data model is called a Datset and visual components of the PBIX file become a Report. In most Power BI projects, the Dataset contains a cached copy of the data, which is held in memory during development and stored in the Power BI service after it is deployed. This is one of the reasons Power BI perform so quickly.
By contrast, database developers often refer to the schema of a data warehouse or datamart database as a data model as well. So, in large-scale project that include data warehouse design and Power BI, the database data model and semantic data model are two different work items.
Report visuals are the individual items place on a report canvas to display or interact with data. Visuals commonly consist of charts, tables and matrices. Specialized and special-purpose visuals include maps, scatter plots and KPI indicators.
Drill-down functionality occurs within a single visual on a report page. Drill-down navigation allows a user to progressively move through a hierarchy of grouped level items, like from Years to Quarters and then to Months – all within a single visual.
Drill-through navigation is a feature that takes the report user from one visual on a page to another page or report in the context of a selected item. The purpose is to typically move from summary to related details contained in another report or page.
The most common object in Power BI used to perform calculations is called a Measure. Most numeric values on a report are measures, but a measure differs from a numeric field in that it is based on a calculation expression defined using the DAX language. Summable numeric fields are sometimes referred to as “implicit measures” and DAX-based measures are referred to as “explicit measures”.
A KPI (Key Performance Indicator) is both a concept and a programmable object that can be created in SQL Server Analysis Services and Power Pivot in Excel. Interestingly, Power BI Desktop lacks the ability to define KPI objects even though they are included in the underlying modeling architecture. KPIs (in the SSAS sense) are largely replaced by dynamic formatting features or specialized visuals in Power BI, that are easier to define for self-service report creators.
The purpose for a KPI is to derive a visual indicator by comparing the Actual measure value with a Target or Goal measure value. Business rules determine the state of the indicator when the actual value is a certain degree higher or lower than the goal. KPI indicators are often displayed using an icon or symbol (such as a traffic light symbol), where the shape and color represent the KPI state (e.g. “Good”, “Bad”, “Neutral”, “Improved”, “Worse”). The individual values (e.g. Actual, Target or Goal) are typically based on measures. Key Performance Indicator (KPI) visuals – Power BI | Microsoft Learn
8 thoughts on “Power BI Object Names – Why Standards Are Important”
I like this, I hope you continue and define a few more “words”. There is a lot to cover.
HARD disagree with this.
Good article, Paul!!!
Great article. Names and terms can be confusing. Clarifying this helps everyone involved. To add to this confusion there’s unfortunately a typo in the post. The term Dataset in bold, is misspelled datset. 🙂