Post last updated: October 10, 2022
I was on a very cool virtual hangout a while back hosted by Jan Mulkens. While we meandered through discussion of various topics, one topic came up that I want to write a bit more about. Essentially the question was: Why deliver content with a Power BI app? After all, we have workspaces and we have sharing so why bother with the extra layer of an app?
For clarity’s sake on the word app: I’m referring to the app you create from a Power BI workspace for the purposes of distributing read-only content to users. I’m *not* referring to the mobile app for purposes of this conversation.
Before we answer that question, let’s start with a short summary of the different ways to distribute content in Power BI.
You might also want to check out my diagram on Power BI permissions.
Ways to Distribute Content in the Power BI Service
Excluding subscriptions and embedding scenarios, there are three main ways to distribute content once it’s been published to the Power BI Service: sharing, workspaces, and apps.
Per-Item Sharing
In the Power BI Service, sharing is an actual feature. Therefore, it’s a word we want to use carefully—sometimes people literally mean using the sharing feature; other times they mean it in a more general way.
Individual items (like reports and dashboards) can be shared. There are two types of sharing: a sharing link and direct access sharing.
Sharing USED to always mean read-only for the recipient. The evolution of the meaning has changed. Now sharing means that permissions are specified for an individual item. (This is different from, say, workspace permissions or app permissions which both set security for a collection of items.)
Example scenario: Sharing can be used effectively when a user or group needs access to one piece of content but has no need to view everything in a workspace or everything in an app. Sharing is best suited to informal scenarios where content is shared with just one person, or a few people who work closely together.
Gotchas to watch out for:
Sharing should be the exception rather than the rule (I recommend looking at using workspaces or apps first - because they both set permissions for a collection of items, rather than item by item). Since sharing permissions are set per individual item, it can become a good bit of maintenance and error-prone if overused.
Sharing should rarely be used from personal workspaces, and definitely not for mission-critical content, since only one person can maintain the original content in a personal workspace.
Any changes to the item are viewable to recipients of the share immediately after the changes are saved in the Power BI Service.
Since it’s prominent in the Power BI Service, sharing tends to be overused by new users before they become aware of workspaces and apps.
The default for the sharing link is to share with the entire organization. I recommend having your Power BI administrator disable this in the tenant settings. That’ll make the ‘specific people’ (i.e., users and groups) the default instead. Specifying users and groups is much more common anyway, and a much safer choice for people who are moving fast.
Workspaces
Workspaces are where we publish content to. They serve as not only a content organization boundary, but also a security boundary.
There are 4 security permissions to be applied for users of the ‘new’ workspace experience: Admin, Member, Contributor, and Viewer. Workspaces are primarily used by content collaborators, authors, and QA/testing teams - but could be used by viewers too in some cases.
The above screenshot of permissions is a simplified view - to give you the general idea. Refer to the authoritative documentation for a complete list.
Example scenario: For small teams who work together closely, it might be very practical to use use the workspace for not only content creation and testing but also for content distribution. For instance, perhaps there is a manager or a colleague who only needs viewer rights only to the content.
Gotchas to watch out for:
The workspace permissions always apply to ALL content within a workspace.
Row-level security won’t take affect for any user who has edit permissions on the content in a workspace.
Any report/dashboard changes are viewable to recipients of the share immediately after the changes are saved in the Power BI Service.
See also my blog post on Workspace Planning Criteria.
Also see the Workspace Planning guidance that I wrote for the Power BI Implementation Planning guidance.
Apps
A Power BI app can be thought of as a packaged-up set of reports and dashboards published for a set of consumers. Every report and dashboard can be included or excluded for an app audience.
A nice feature of apps is that you can customize the navigation menu to organize content. You can also include hyperlinks to additional documentation, related systems, and so on.
There is a secondary level of permissions for an app, so this offers flexibility when you want to set up security for the app consumers differently than the workspace. These permissions are set when you publish the app and are always read-only, and they apply to the collection of items you’ve set up for that specific audience.
Some teams utilize apps as the deployed production solution, and the workspace as dev/test. This is a lightweight way to handle the separation but it’s not without a downside - see the 2nd gotcha below.
Example scenario: If you need to distribute content widely, for instance dozens of sales personnel across the organization, that’s where using an app to distribute content starts to really make sense. An app with its nice navigation experience is a better experience for consumers.
Gotchas to watch out for:
Only one app can be published per workspace. However, you can create multiple audiences per app. This is a great way to “mix and match” content and target audience.
Although changes to reports and dashboards aren’t visible to app viewers until the app is republished, dataset changes always take effect immediately. This includes data refresh but also potentially breaking changes to tables, calculations, and relationships.
Permissions and content are always published together. Be careful of this when publishing, if you have reports in the workspace that aren’t ready to be seen by app viewers. The best way around this is to use security groups instead of individuals for securing an app (that way you don’t have to republish the app to make a permissions change).
So, Why Use an App?
To answer the original reason for this blog post…here are the reasons I would use an app:
Distributing content broadly to a large number of users
Distributing some or all reports/dashboards from within the workspace
Using a nice navigation menu including hyperlinks to additional documentation or a related system
Using a separate level of security since which is decoupled from the workspace security
Controlling the publishing process and the timing when consumers can view report/dashboard changes (see gotcha #2 above though about datasets)
Pushing apps to the downstream users so they automatically appear in the user’s apps menu (this is disabled by default in the tenant settings - if you allow this for specific content authors who will use this feature prudently, it is a nice convenience for the app viewers to not have to go fetch the app)
Allowing users to copy the reports to their My Workspace and customize them [optional - can be disabled when you publish the app]
Allowing users to connect to the underlying datasets to create their own reports without needing access to the workspace (this is known as the ‘build’ permission spoken of in relation to shared datasets) [optional - can be can be disabled when you publish the app]
Like This Content?
Check out our Power BI Deployment & Governance online course.
