Today, we’ll look at Power BI workspaces, apps, and how to keep changes from mucking up reports. In the software development lifecycle, a distinct space to test new reports ensures consistent results. Moreover, it’s part of good governance. This post builds on: How to Get Power BI Service to Work for You. Thanks to Krissy and Nar for prodding me to go further! Around here, we don’t require pre-publication peer review. But we do learn from each other.
Note: This article requires the use of Power BI Pro, Office 365, and SharePoint Online. It’s ok if SharePoint on premises is your main intranet.
Two Issues with Power BI Workspaces and Apps
First, reports in Power BI workspaces and apps share a single dataset. And this data is updated whenever the workspace is updated. Second, workspaces and their apps have the same access. So, creators can publish reports without review.
1. The Power BI workspace and app share the same dataset.
When the publishing changes to the workspace, the data for the app changes too— even without updating the app. As a result, changes to the data model risk breaking the report. Also, you need to refresh the data before uploading or right after, so that stale data doesn’t replace fresh data.
Shared data in Power BI Service is by design, even if it has unplanned results. It reflects certain assumptions about self-service BI that doesn’t align with the real world. In this ideal, creating a report means applying visualizations to a stable dataset from a data warehouse. Even if you have a data warehouse, you still must refresh the report at the time of updating to avoid stale data. So, I added an item at ideas.powerbi.com to make updates upon changing a report.
2. A second issue is the partial separation of creating from testing.
As designed, the shared dataset does not deliver this separation. It’s too easy to make changes. If there are few creators and report consumers, this can work. As more people use Power BI, stable processes are a must. See Rob’s Power BI Adoption Curve.
A Two-Space Solution for Power BI Workspaces and Apps
To get the benefits of a testing space, you need a second workspace. If the production space is Contoso Reports, the second space would be Contoso Reports-BETA. Report creators need editing rights on this workspace. While the workspace is for development, the app of the beta space is for testing. Once changes are ready, publish the app to a group of users for testing.
How to move reports from development to production?
- In SharePoint Online, copy the pbix file from BETA to production team sites.
The report in the Power BI workspace updates automatically if you sourced it using Get Data from the service. - Refresh the report in the service.
- When refresh is complete, update the app to republish.
In this process, there are two manual steps: copying the file and republishing the app. Report creators don’t need access to the production team site or workspace.
What did I miss?
Dashboards. No way yet to move dashboards between workspaces. In fact, let’s add some steps.
Create a dashboard in the beta workspace, documenting the fields used and any slicers. When updating the report in the beta workspace, testers need to review the dashboard. If the dashboard breaks during development, the creator needs to change the dashboard and keep a list of changes.
After the report is in the production workspace, the publisher needs to pin similar tiles to the production dashboard (and fix any broken tiles before republishing the app).
Let’s look at the process.
Better living through syncing.
This chart shows syncing. First, there’s syncing between the PC and the SharePoint Online Team Site. Then, there’s syncing from the team site to the Power BI workspace. This syncing is done with Get Data from the service. Details on setting this up are in the post: How to Get Power BI Service to Work for You. However, moving files from beta to production is manual. And, publishing from Power BI workspaces to apps is also manual. Thus, these steps ensure stable results for report readers.
Wait, is this agile BI?
Agile is all about flexibility: ways to respond to changes and support individuals and their interactions. So, in my chart, I show report creator and publisher. In a small company, one person may wear both hats. Let me put on my publisher hat to push out this report. In some places, it could be an admin from the business side. In other groups, it could be a Power BI team leader. Similarly, report creators could be business users and/or full-time Power BI developers. Further, testing would mean business users and developers working together to lay out acceptance criteria. After all, “[link removed due to 404] everyone is responsible for quality.” Then, both groups test results at the same time while the report is in beta.
So, this is one way and not the only way to reach the goal. Let me know what you think.
More Resources for Power BI Workspaces, Apps:
- Power BI Content Workflow — with Apps by Steve Howard of Angry Analytics blog.
- Great for how to show the process, and helpful to understand apps.
- Distribute to Large Audiences with Power BI Apps – Ajay Anandan.
- Introduces Power BI Workspaces, Apps.
- Soon: “Creating app workspaces will not create corresponding entities in O365 like group workspaces do.”
- Which in no way blocks the process shown here.
- How to Get Power BI Service to Work for You – my post using SharePoint Online to manage pbix source files.
- Automatically Install Apps – Lukasz Pawlowski.
- In February 2018, Microsoft made a way to push apps to users.
Where It’s At: The Intersection of Biz, Human, and Tech*
We “give away” business-value-creating and escape-the-box-inspiring content like this article in part to show you that we’re not your average “tools” consulting firm. We’re sharp on the toolset for sure, but also on what makes businesses AND human beings “go.”
In three days’ time imagine what we can do for your bottom line. You should seriously consider finding out 🙂
* – unless, of course, you have two turntables and a microphone. We hear a lot of things are also located there.
