10.1 Workspaces, Apps, and Content Distribution

Microsoft Power BI Data Analyst PL-300

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the PL-300 Exam The Power BI Ecosystem

2 Chapter 1: Get or Connect to Data

1.1 Data Source Types and Connections 1.2 Storage Modes: Import, DirectQuery, and Direct Lake 1.3 Data Source Settings and Parameters

3 Chapter 2: Profile and Clean the Data

2.1 Data Profiling in Power Query 2.2 Resolving Errors, Nulls, and Data Quality Issues 2.3 Data Types and Type Detection

4 Chapter 3: Transform and Load the Data

3.1 Column Transformations and Data Types 3.2 Grouping, Aggregating, Pivoting, and Unpivoting 3.3 Merge Queries, Append Queries, and Relationship Keys 3.4 Query Folding and Load Performance

5 Chapter 4: Design and Implement a Data Model

4.1 Star Schema Design 4.2 Relationships, Cardinality, and Cross-Filter Direction 4.3 Table and Column Properties 4.4 Calculated Columns and Calculated Tables

6 Chapter 5: Create Model Calculations with DAX

5.1 DAX Fundamentals and Measures 5.2 The CALCULATE Function 5.3 Time Intelligence Measures 5.4 Statistical Functions, Semi-Additive Measures, and Calculation Groups 5.5 Essential DAX Patterns and Functions Reference

7 Chapter 6: Optimize Model Performance

6.1 Performance Analyzer and DAX Query View 6.2 Model Size Reduction and Cardinality Management 6.3 DAX Optimization Patterns

8 Chapter 7: Create Reports

7.1 Visual Types and Selection 7.2 Visual Formatting and Conditional Formatting 7.3 Copilot in Power BI Reports 7.4 Report Page Configuration and Slicers

9 Chapter 8: Enhance Reports for Usability and Storytelling

8.1 Bookmarks, Navigation, and Drillthrough 8.2 Sorting, Selection Pane, Mobile Layout, and Accessibility 8.3 Export Settings and Automatic Page Refresh

10 Chapter 9: Identify Patterns and Trends

9.1 The Analyze Feature and AI Visuals 9.2 Using Copilot to Summarize the Semantic Model 9.3 Advanced Analytics Patterns

11 Chapter 10: Create and Manage Workspaces and Assets

10.1 Workspaces, Apps, and Content Distribution 10.2 Subscriptions, Alerts, and Semantic Model Refresh 10.3 Dashboards and Advanced Distribution

12 Chapter 11: Secure and Govern Power BI Items

11.1 Row-Level Security (RLS) 11.2 Sensitivity Labels, Item Access, and Governance 11.3 Deployment Pipelines and Content Lifecycle

10.1 Workspaces, Apps, and Content Distribution

Key Takeaways Explain This Topic AI

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.

Last updated: June 2026

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).