10.1 Workspaces, Apps, and Content Distribution
Key Takeaways
- Workspace roles are Admin, Member, Contributor, Viewer; the tested boundary is that Contributors can edit content but cannot publish apps or manage access, while Members can.
- Apps bundle selected workspace content into a curated read-only experience (with multiple audience groups) and require no workspace access; consumers see changes only after Update app.
- Dashboards are single-page tile canvases built only in the service, and data alerts, the Q&A box, and Feature on Home are dashboard-only features.
- Choose distribution by audience: apps for broad consumers, workspace sharing for collaborators, subscriptions for automated delivery, embed for portals, and Publish to web only for public data.
- An on-premises data gateway is required for on-prem sources (SQL Server, local files, Oracle, SAP) but not for cloud sources; Promoted endorsement is open to members while Certified requires authorized certifiers.
Quick Answer: Workspaces are containers (reports, semantic models, dashboards, dataflows) with four roles — Admin, Member, Contributor, Viewer. Apps package selected workspace content into a curated, read-only experience for broad audiences who never touch the workspace. Dashboards are single-page tile canvases built only in the service. Choose distribution by audience: apps for broad consumers, workspace sharing for collaborators, subscriptions for automated delivery, embed for portals, and Publish to web only for genuinely public data. Gateways bridge on-premises sources.
Workspaces
A workspace holds reports (.pbix), semantic models (datasets), dashboards, dataflows, paginated reports, and scorecards. Create one from Workspaces -> New workspace (name, description, optional license mode). My workspace is personal scratch space — you cannot publish an app from it — so production content belongs in a shared workspace.
Workspace roles (memorize the boundaries)
| Role | Key permissions |
|---|---|
| Admin | Everything: manage members, delete the workspace, publish/update apps, manage all content |
| Member | Add/edit/delete content, publish and update apps, share items, manage some settings |
| Contributor | Create/edit/delete content, but cannot publish apps or manage member access |
| Viewer | View and interact only — no editing |
The most-tested line is Contributor vs. Member: a Contributor can build content but cannot publish the app or add members; a Member can. Assign roles under Workspace -> Manage access, ideally to security groups rather than individuals.
Apps
An app bundles chosen workspace content into a curated, read-only package: custom navigation, branding (name/logo/theme), and no workspace access required for consumers. Build it from Workspace -> Create app (or modern "Create app" experience), select content, design navigation, and set the audience — modern apps support multiple audience groups so different teams see different subsets of the same app. After you change content in the workspace, consumers see nothing new until you click Update app.
| App | Workspace sharing | |
|---|---|---|
| Audience | Large / org-wide | Small / collaborative |
| Access | Read-only, curated | Role-based (Viewer..Admin) |
| Navigation | Custom | Default content list |
| Content | Selected items only | All workspace content |
Dashboards
A dashboard is a single-page canvas of pinned tiles from one or more reports, Q&A, Excel, or streaming data — and it exists only in the service (you cannot build a dashboard in Desktop). Pin a visual via its Pin icon, or pin a whole report page as a live tile. Key dashboard-only features: data alerts, the integrated Q&A box, and Feature on Home.
| Dashboard | Report | |
|---|---|---|
| Pages | Single | Multi-page |
| Built in | Service only | Desktop or service |
| Data | Tiles from many models | One model per report |
| Alerts | Yes (on tiles) | No |
Content distribution methods
| Method | Audience | Use case |
|---|---|---|
| App | Large/org-wide | Standard consumer reporting |
| Workspace sharing | Small teams | Co-authoring/development |
| Direct share | Individuals | Quick ad-hoc access |
| Subscription | Scheduled recipients | Automated PDF/link delivery |
| Embed | Portals/Teams/SharePoint | Embedded analytics |
| Publish to web | Public internet | Public data only — no auth |
Gateways
A gateway lets the cloud service reach on-premises sources. It is required for on-prem SQL Server, local files, Oracle, SAP, etc.; it is not required for cloud sources (Azure SQL, SharePoint Online) or public web APIs.
| Type | Use |
|---|---|
| On-premises data gateway (standard) | Shared, IT-managed, supports scheduled refresh and DirectQuery for many users |
| Personal mode | Single user, refresh only |
Promoting and certifying
| Endorsement | Meaning | Who sets it |
|---|---|---|
| Promoted | Ready for broad use | Any workspace Member/Admin |
| Certified | Meets org quality standards | Only admin-authorized certifiers |
Certified content carries a badge in search, steering users to trusted data and reducing shadow BI.
Licensing and capacity for distribution
A subtle but tested point: who needs which license to consume content. In a workspace backed only by Pro (shared capacity), every viewer who opens a report or app needs their own Pro license. Put the workspace on Premium/Fabric capacity and free users can consume the content (the capacity pays for them), which is the standard pattern for broad, org-wide distribution. Premium Per User (PPU) is the middle option: the author and every viewer need a PPU license, but you get Premium features without buying capacity — economical only when the audience is small.
So "distribute a report to 5,000 mostly-viewer users most cost-effectively" points to Premium/Fabric capacity + an app, not Pro and not PPU.
App audiences and update behavior
Modern apps support multiple audience groups: within one app you define audiences (e.g., "Sales", "Executives") and grant each access to a different subset of pages, so one published app serves several teams. Remember the update gate: editing a report in the workspace does not change what app consumers see until a Member/Admin clicks Update app. This is by design — it lets authors stage changes and validate before releasing them, and it is a frequent exam detail ("a fix is in the workspace but consumers still see the old version — why?").
On the exam
Common items: pick apps for a 200-person read-only audience (not adding 200 Viewers); choose Premium/Fabric capacity + app to let free users consume at scale; diagnose a failed scheduled refresh on on-prem SQL as a missing gateway; explain why app consumers don't see a workspace change (Update app not clicked); distinguish Promoted (any member) from Certified (authorized only); and separate Contributor from Member permissions (Contributors can't publish apps).
A department of 200 people needs read-only access to a set of Power BI reports. They should NOT be able to edit content or see the underlying workspace structure. What is the best distribution method?
A report uses data from an on-premises SQL Server. After publishing to the Power BI Service, scheduled refresh fails. What is the most likely issue?
What is the difference between "Promoted" and "Certified" endorsement in Power BI?
A workspace Contributor needs to publish the workspace's app to the organization but finds they cannot. Why?