Building an Enterprise Deployment Model with Power BI

Listen, Power BI is pretty amazing. You wouldn’t be reading this if you didn’t already sort of believe that.

I’m guessing I don’t have to convince you anymore that, all things considered, developing Power BI reports is relatively easy. In fact, I probably don’t even have to prove that licensing and TCO is lower than our competitors.

The majority of questions/concerns/fears I hear from customers these days are around proper deployment and administration of the tool. If any of the below questions ring a bell, this article is for you. (Side note: see my prior post here for best practices around tenant-level permissions)

1. How do I deploy content to production?

2. What type of users/permissions do I need to have a successful roll out?

3. How can I empower analysts to build their own reports while preserving a single source of truth?

4. Who needs a Pro license?

First things first, let’s align on some Power BI terms that I’ll be using in the rest of this post:

1. Workspace: a development environment within the Power BI Service configured for collaboration (also called App Workspace) – all permissions referenced in this guide are for the new Workspace v2 (WSv2), currently in Public Preview
2. App: a read-only, production environment within the Power BI Service configured for consumption.
3. Data Source: physical data stores (e.g. SQL Data Warehouse, Excel files) for Power BI to connect to when building models.
4. Dataset: a data model built inside Power BI Desktop that’s a collection of one or many data sources. Can be reused to create additional reports from once published to the Power BI Service.
5. Release Manager: a user who publishes content from a Workspace (development) to an App (production) for end users to consume.
6. Developer: a user whose primary job is to connect to data sources in order to build and publish Datasets to Workspaces (think ETL developer)
7. Power User: a user whose primary job is to connect to Power BI Datasets in order to build and publish Reports to Workspaces (think Report Writer)
8. QA: a user whose primary job is to test created content prior to deployment to Apps
9. End User: a user who only consumes published App content.

Now let’s take a look at user permissions, licenses, and roles:

User Type	Access to Data Source?	Access to WS + Dataset?	Need Pro License?	Workspace Role
Admin	No	Yes	Yes	Admin
Release Manager	No	Yes	Yes	Member
Developer	Yes	Yes	Yes	Contributor
Power User	No*	Yes	Yes	Contributor
QA	No*	Yes	Yes	Viewer
End User	No*	No**	No***	None

*Yes, for DirectQuery w/ SSO data sources (see here and scroll to Scenario #3 for more info)
**Can only Analyze in Excel from Apps – cannot create new Reports or access Workspace
***Yes, for content hosted on non-Premium capacity

Workspace Role	Definition
Viewer*	View content within the workspace Replaces read-only workspace
Contributor	All Viewer privileges Add/edit/delete content within workspace
Member	All Contributor privileges Publish and update Apps Reshare – add new users to be Members or lower
Admin	All Member privileges Can change and delete workspaces Add additional Admins

*Viewer role will be available when WSv2 goes GA – not available at time of writing

A couple things to note from the above:

1. Users should not be defined globally – rather, they should be defined based on the data they have access to and their role within a given workstream. (For example, a financial analyst may be a Power User for a dataset built from a Finance Datamart, but a Developer for building a dataset from a collection of forecasting Excel spreadsheets.)
2. A Release Manager doesn’t necessarily have to be a separate, distinct user, but one entrusted with promotion to production permissions.

Given all the above, here is how we would build a deployment model for a single workstream, with steps listed below.

1. Create a new App Workspace based on domain of future, published content and end user needs. Grant the appropriate user permissions as listed above.
2. Using Power BI Desktop, if a Power BI Template (PBIT) exists, a Developer opens the Template, enters parameters as appropriate, and saves as PBIX #1. If not, Developer opens Power BI Desktop, connects to Data Sources, and creates a new report and saves as PBIX #1.
3. Developer uploads PBIX #1 file (and PBIT, if appropriate) to Dev Site in OneDrive for Business.
4. Developer publishes PBIX #1 from OneDrive for Business to Workspace. This creates a Dataset and Report in the Power BI service, and Developer can create creates Dashboards within the service as needed.
5. Power User connects live to published Dataset to create additional Reports as needed. Because the Power User doesn’t have access to the Data Sources, he/she only has read permissions on the Dataset. Power User creates report and saves as PBIX #2.
6. Power User uploads PBIX #2 file to Power User Site in OneDrive for Business.
7. Power User publishes PBIX #2 from OneDrive to Business to Workspace. This only creates a new report in the Power BI service, as the report is connecting live to the previously published Dataset.
8. QA performs end user and report validation testing on report, collaborating with Developers & Power Users as needed.
9. When ready for production, Release Manager publishes content from Workspace to App, sharing with AD groups/users for End User consumption. Datasets never get published in Apps – only Reports and Dashboards.
10. End User consumes content in App.

And that’s it!

Questions/comments/feedback? I’d love for you to drop me a line.

11/19 Update:

After rereading the post and getting some feedback from the community, I wanted to expand and clarify a few points from above:

1. The main reason I’m recommending OneDrive is because there is no currently any version control support within the Power BI Service. I know this is being worked on, though, by the product group as part of a large, future ALM release, so stay tuned.
2. I’ve not specifically mentioned Dataflows but they more or less follow the same model today as they are attached to Workspaces. Dataflows should still be created by Developers (as they require access to Data Sources) and will help over time to a) certify data and b) make it easier for business users to consume data. Dataflows are still in Public Preview, though, and still have some kinks to work out. But I definitely believe they are the future and would encourage you to check them out.
3. As of time of writing, the source of any Dataset lives within a PBIX file. Because of this, it is critical that you only grant access to this original file to users empowered to modify this Dataset, hence my splitting OneDrive into two separate sites/folders/permission groups.