5.1.2. Apps, Dashboards, and Distribution Methods
💡 First Principle: Distribution should separate editing from consuming. Collaborators belong in the workspace; consumers should receive a curated, read-only package they can't accidentally break. Each distribution method trades scale, control, and convenience differently.
Apps are the primary way to distribute content broadly:
- Each workspace can publish one app that bundles selected reports, dashboards, paginated reports, and links, with its own navigation, branding, and description.
- Audiences let one app show different content to different groups (for example, Executives see all pages; Sales sees only sales reports). Each audience has its own access list and content visibility.
- Changes in the workspace aren't visible to app users until an author selects Update app, so you can work on content without exposing drafts.
- App permissions include granting app users Build on the underlying semantic models (to create their own reports) and allowing reshare. Admins can configure apps to install automatically for users.
- Publishing and updating an app requires Admin or Member role (or Contributor when the workspace setting allows contributors to update the app).
Dashboards are single-page canvases created only in the service by pinning tiles from reports (individual visuals, or live pages that keep slicers interactive), from Excel, from Q&A, or as text, image, video, and web content tiles. Dashboards can combine visuals from multiple reports and semantic models on one page, support data alerts on certain tiles (5.1.3), and have mobile views. A dashboard tile links back to the report it came from.
| Distribution method | Best for | Key characteristics |
|---|---|---|
| Workspace access (roles) | Creators and collaborators | Edit rights by role; not for consumers |
| App | Broad, governed consumption across a department or organization | Versioned (Update app), audiences, read-only, central management |
| Direct sharing of a report or dashboard | Ad hoc sharing with a few people | Per-item; harder to govern at scale; recipients need appropriate licenses |
| Links (people in your organization, specific people, existing access) | Quick sharing of a single item | Link scope controls who can use it |
| Embed in SharePoint Online or Teams | Putting reports where people already work | Respects Power BI permissions and RLS |
| Embed (secure) in a portal or app | Internal sites with authentication | Users sign in; permissions enforced |
| Publish to web | Public, anonymous content only | No authentication, anyone with the link can view; never for confidential data; admin may disable |
| Subscriptions / export | Scheduled email delivery or offline copies | Snapshots, not interactive (5.1.3) |
⚠️ Exam Trap: When a stem says "share reports with 300 people in the sales department, prevent them from editing, and control when they see updates," the answer is an app (with an audience if needed), not adding them to the workspace as Viewers or sharing each report individually. Publish to web is never correct when data is internal or confidential.
Reflection Question: Why does the "Update app" step exist, and what problem would occur if app users saw workspace changes the moment authors saved them?
