Power BI App Workspaces have come a long way over the past couple of years. New features provide powerful methods for deploying reports; centralizing the heavy lifting around data modeling, while still giving users the ability to share reports and self-service reporting. Having a good strategy for organizing App Workspaces will lower the Power BI maintenance costs and effort for your organization.
Power BI Workspace Types
There are three types of Workspaces in Power BI:
- App Workspace | Power BI Only – Creating a new Workspace from Power BI no longer creates an Office 365 Group or Team. This type of workspace is only for deploying Power BI assets.
- Classic Workspace | Office 365 Group / Microsoft Team – A Workspace created in Microsoft Teams and available in Power BI. The Classic Workspace concept will eventually go away in Power BI, but may still exist in your organization.
- App Workspace | Office 365 Group / Microsoft Team – An upgraded version of the “Classic Workspace”. This type of workspace has all the features of an App Workspace and also has some useful BI collaboration features: File share, Wiki, and Microsoft Teams collaboration. In PowerBI.com, click on Edit This Workspace > Advanced > Upgrade now to switch from Classic to App Workspace.
Classic Workspaces were very restrictive in deployment – all the components of a Power BI report had to live inside a single Workspace. App Workspaces allow for flexible deployment options across many Workspaces and add features for Power BI Apps.
Splitting Data Models and Reports
When deploying to PowerBI.com, it’s common to encounter these scenarios:
- Many Reports deployed against a single data model.
- Reports pointing at the same underlying data are deployed across many Workspaces.
- Users want self-service reporting, but don’t necessarily want to put the data model together themselves. They’d prefer to be consumers of data.
To accommodate these scenarios, it’s important to understand the concept of splitting a Data Model from a Report in Power BI. Splitting is accomplished by having the following .pbix file structure:
- File 1: Import Data and define Relationships, Calculations, and Security Roles. Publish to PowerBI.com.
- File 2 (3, 4, 5…): Create a new file and select the data source of “Power BI Dataset”, pointing at File 1. Define the Pages, Visuals, Slicers, and Filters. Publish to PowerBI.com.
With this file structure in place, the PowerBI.com Lineage view demonstrates the Dataset name and Report names are different, and many Reports point to one Dataset.
PowerBI.com Lineage view
Data Model Workspace
With the background about Workspace types and splitting of Data Models and Reports, a strategy can be developed for deployment of Power BI files. The first strategy decision is where to deploy, secure, and maintain the organization’s Data Models.
Create a Workspace For Data Models
For the Data Model Workspace, I prefer an “App Workspace | Office 365 Group / Microsoft Teams” deployment. There are useful Power BI and Office 365 functions in this context including:
- Power BI Datasets – Central repository for official data models.
- Power BI Dataflows – Central repository for official data transformations.
- Power BI Security – Access restrictions for data.
- Office 365 Files – Storage and OneDrive local synchronization of Power BI .pbix working files.
- Office 365 Files – Storage of additional managed sources of official supplementary BI data, such as managed Excel files.
- Wiki – BI Documentation using Office 365 Wiki or Teams Wiki.
PBI Data Models
Usage of Dataflows
Dataflows in Power BI are useful when the same transformed data is used across multiple Data Models. Dataflows allow Power Query transformations to happen outside of the Data Model .pbix file – instead, the transformed data is consumed by the Data Model file. As an example, some organizations use unique accounting date ranges, commonly referred to as “5-4-4” accounting periods – basically custom reporting date ranges. A Business Analyst might want to bring these same date ranges into many Power BI Data Models as a “Fiscal Period Date” Dimension. This could be accomplished through 1) a Managed Excel file where an Accountant manages the Fiscal date ranges and 2) a Dataflow that turns the date ranges into a proper BI Date Dimension. Required assets can all be managed in the Data Model Workspace using the File storage and a Power BI Dataflow.
Managed Excel file where an Accountant manages the Fiscal date ranges
Dataflow that turns the date ranges into a proper BI Date Dimension
Security Roles
Power BI treats Datasets differently based on the existence of Security Roles:
- No Security Roles defined – Workspace Viewers can see all data.
- 1+ Security Roles defined – Workspace Viewers cannot see any data unless also assigned a Role.
It’s a good idea to have at least one Security Role defined in the Data Model file (e.g. “AllData”), so Users or an AD Group must be explicitly granted access to each individual Dataset. The AllData role doesn’t need any conditions applied, its mere existence is effectively blocking Viewer level data access by default.
Security Role defined in the Data Model file
Endorsement
Datasets and Dataflows can have Promoted or Certified Endorsement badges granted by a Power BI administrator. These attributes are helpful for self-service reporting; the badges communicate to Users how diligently a Data Model is being managed by Power BI Admins or Power Users. For example, Promoted might mean “this Dataset is modeled correctly and on a refresh schedule” and Certified might mean “this Dataset is documented and changes well managed”. The exact meaning of Promoted and Certified is whatever your organization communicates to the users; they will see a badge when selecting a Dataset from Power BI Desktop.
Selecting a Dataset from Power BI Desktop
Power BI Report Workspace
Most of the heavy lifting in this strategy is done through the Data Model Workspace, but report consumers will need a place to access the Power BI Reports and Dashboards. Existing Office 365 Groups / Teams can be utilized for this purpose; however, my experience is typical Teams don’t align with the deployment of standard reports, as reports tend to cross between many Teams or Departments.
Reports Only
The “App Workspace | Power BI Only” style of the Workspace is useful for deploying Reports. There’s minimal overhead for these Workspaces – they are a lightweight option to manage the Report definitions, Apps, and Security for widely distributed Reports.
Manage the Report definitions
Create An App
A standard Power BI Report Workspace contains a list of Reports, which is sufficient when getting started. Creating an App provides more features around publishing and navigating an App Workspace. Some key Power BI App features include:
- A unique App URL to share with report consumers.
- Publish and test a Report in the Workspace prior to including it in the App.
- Control of the App menu, including designating a default Dashboard, specified report sort order, and report tabs hidden from navigation.
Creating an app
Security
The Reports Only Workspace has different security permissions than the Data Model Workspace. Generating Data Models is centralized and report writing is more distributed. More users would be “Viewers” of the Data Model, but Members or Contributors of a Report Writing Workspace.
Existing Team / Office 365 Group
Existing teams or Office 365 Groups may be useful to deploy reports, especially “self-service” reports for a Team. These reports can still point to shared Datasets, so long as you upgraded to “App Workspaces”. My Workspace is also a good spot for self-service reports pointed to shared Datasets.
Summary
There are quite a few technologies in play here; there are myriad ways to make things work. This post outlines one specific path that can be effective. Different organizations have a variety of unique requirements; please Contact Us for assistance deploying Power BI in your organization and connect with us on LinkedIn and Twitter. Joel Leichty is the Power Practice Manager at sa.global. He also writes about Power BI in a casual style at https://joelleichty.com/.
