Dear colleague, if I have sent you to this post, it is because I respect you and want to make sure we are on the same page as we communicate 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. This short post just covers the basics in simple terms.
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 fraction of those projects might also include a dashboard.
The functional and differences between Reports and Dashboards is described in detail here.
Report Pages
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.
Visuals
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 Navigation
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
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.