Power BI Service: Workspaces, Apps, and Dataset Sharing

Power BI Service transforms locally authored reports and data models into governed, collaborative analytical assets that entire organisations can consume at scale. This chapter covers the Service-side collaboration model most heavily tested on PL-300: workspace roles, dataset endorsement, Power BI Apps, dashboard tiles, and scheduled refresh.

1. The Power BI Service Collaboration Model

From Desktop to Service: The Publication Pipeline

Publishing a .pbix to the Power BI Service crosses a governance boundary. The Service separates the report from the dataset, creating two independent artefacts that can be managed, secured, refreshed, and shared independently. A single certified dataset can power dozens of reports authored by different teams, eliminating redundant modelling.

The pipeline begins with Home → Publish in Power BI Desktop and a target workspace selection. Understanding which actions affect the dataset, the report, or both is a core PL-300 exam theme.

Workspace Architecture and the Shared Dataset Pattern

A workspace holds datasets, reports, dashboards, and dataflows — and carries a permission model, a capacity assignment, and optionally a deployment pipeline association. The recommended enterprise pattern organises workspaces around data domains rather than teams. Cross-workspace dataset consumption is enabled by the Build permission, distinct from workspace membership.

Workspaces in Premium capacity (or PPU) unlock paginated reports, deployment pipelines, XMLA endpoint access, and free-user sharing. Shared capacity requires all consumers to hold a Pro licence.

2. Workspace Roles: Permission Boundaries

The Four-Role Permission Model

Power BI workspaces implement a four-tier additive role hierarchy applying at the workspace level, not to individual artefacts.

The key PL-300 trap: Contributors can create and modify content but cannot publish the workspace app. A Contributor who wants to publish must be elevated to Member or Admin.

Build Permission: Cross-Workspace Dataset Consumption

Build permission allows a user to create new reports, dashboards, or composite models against a shared dataset without being a workspace member. It can be granted explicitly via the dataset's Manage permissions panel, inherited by Contributor+ workspace roles, or distributed automatically through app publication.

Role Assignment Best Practices

Assign workspace roles to Azure AD security groups (e.g., SG-PBI-FinanceAnalytics-Contributor) rather than individual users to delegate maintenance to the identity team. Guest users can be added to workspaces only when both AAD cross-tenant invitation settings and the Power BI tenant setting "Allow guest users to edit and manage content" are enabled.

3. Dataset Endorsement: Promotion and Certification

The Endorsement Hierarchy

Endorsement signals trustworthiness across the tenant with two tiers: Promoted (owner-applied, signals readiness) and Certified (governance-team-applied, signals organisational validation). Both tiers appear as badges in workspace views, the data hub, and Power BI Desktop's dataset discovery experience.

Promoted Endorsement

Applied by the dataset owner, or any workspace Admin or Member, via Endorsement and discovery in dataset settings. No tenant configuration required; available in all workspace types. The Promoted badge drives discovery in the data hub and encourages consumers to adopt governed data over shadow datasets.

Certified Endorsement

Requires a Power BI administrator to enable certification under Tenant settings → Endorsement and discovery → Certify datasets and to designate the authorised security groups. Only members of those groups can apply the Certified badge. The Service records the certifier's identity and timestamp, creating an audit trail.

4. Power BI Apps: Packaging and Distributing Curated Content

App Architecture and the Audience Model

A Power BI App is a curated, read-only package of workspace content distributed to defined audiences. Apps solve a fundamental UX problem: workspace Viewers see all content including drafts, whereas app audiences see only the content the publisher has selected in a custom navigation structure. A single app can serve multiple audiences, each seeing a different content subset.

Row-level security interacts with the audience model: audience configuration controls which reports are visible; RLS controls which data rows are visible within those reports.

Creating and Publishing an App

Publishing requires at minimum the Member role. The publication panel guides through three steps: Setup (name, description, logo, theme), Navigation (content selection and structure), and Permissions (audience definition). Navigation items can be renamed independently of the underlying artefact's workspace name, insulating consumers from technical naming conventions.

Audience Configuration and Access Management

Audience members — users or security groups — receive app access automatically on publication without needing workspace membership. The Entire organisation option makes the app available to all licensed users while still respecting RLS. App consumers who hold Build permission on the underlying dataset can use Edit a copy to create personalised reports in their own workspace.

5. Dashboard Tiles: Pinning, Live Pages, and Streaming Data

Dashboards vs. Reports

Reports are multi-page analytical documents with cross-filtering, drill-through, and bookmarks, connected to a single dataset. Dashboards are single-page collections of tiles sourced from multiple reports and datasets — designed for at-a-glance monitoring without report-style interactivity. Dashboards are a Service-only artefact and cannot be created in Power BI Desktop.

Pinning Tiles from Reports

Analysts pin visuals from published Service reports using the Pin visual icon. Pinned tiles maintain a live connection to source reports: when the dataset refreshes, dashboard tiles reflect updated data automatically. Clicking a tile navigates consumers to the full interactive source report.

Pinning Live Report Pages

An entire report page can be pinned as a live page tile, rendering all its visuals in an interactive tile directly on the dashboard canvas — including slicer interaction without leaving the dashboard.

Streaming Datasets and Real-Time Tiles

Streaming datasets are push-based: external systems push rows via the Power BI REST API and dashboard tiles update within seconds. Three types exist with different storage and query characteristics:

6. Scheduled Refresh: Configuration and Failure Management

Refresh Architecture and Prerequisites

Scheduled refresh pulls updated data from sources and reloads the in-memory dataset. Three prerequisites must be satisfied: (1) data source credentials configured in dataset settings, (2) an on-premises data gateway (or VNet gateway) for private-network sources, and (3) the dataset must not be a live connection to Analysis Services.

In shared capacity, datasets can be refreshed up to 8 times per day. In Premium capacity, up to 48 times per day (every 30 minutes).

Configuring Scheduled Refresh

Dataset owners navigate to Scheduled refresh in dataset settings to configure frequency, time zone, specific times, and failure notification recipients. The Service does not guarantee exact execution times — use the Power BI REST API triggered from Azure Data Factory or Logic Apps for precision SLAs.

Refresh Failure Notifications and Remediation

7. Lab

# CE-17: Acquire token, assign Contributor group, endorse dataset, grant Build
TOKEN=$(curl -s -X POST "https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token" \
  -d "client_id=${CLIENT_ID}&client_secret=${CLIENT_SECRET}&scope=https://analysis.windows.net/powerbi/api/.default&grant_type=client_credentials" \
  | jq -r '.access_token')
# Add security group as Contributor
curl -s -X POST "https://api.powerbi.com/v1.0/myorg/groups/${WORKSPACE_ID}/users" \
  -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
  -d '{"identifier":"'${SG_OID}'","groupUserAccessRight":"Contributor","principalType":"Group"}'
# Apply Promoted endorsement
curl -s -X PATCH "https://api.powerbi.com/v1.0/myorg/datasets/${DATASET_ID}" \
  -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
  -d '{"endorsementDetails":{"endorsement":"Promoted"}}'
# Grant Build permission to consumer group
curl -s -X POST "https://api.powerbi.com/v1.0/myorg/datasets/${DATASET_ID}/users" \
  -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
  -d '{"identifier":"'${CONSUMER_OID}'","datasetUserAccessRight":"Build","principalType":"Group"}'

# CE-18: Configure refresh schedule and monitor history
curl -s -X PATCH "https://api.powerbi.com/v1.0/myorg/datasets/${DATASET_ID}/refreshSchedule" \
  -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
  -d '{"value":{"enabled":true,"days":["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "times":["06:00","06:30","07:00","07:30","08:00","08:30"],
    "localTimeZoneId":"Eastern Standard Time","notifyOption":"MailOnFailure",
    "recipients":{"values":["powerbi-ops@contoso.com"]}}}'
# Trigger on-demand refresh
curl -s -X POST "https://api.powerbi.com/v1.0/myorg/datasets/${DATASET_ID}/refreshes" \
  -H "Authorization: Bearer ${TOKEN}" -d '{"notifyOption":"MailOnFailure"}'
# Poll refresh history (last 5 entries)
curl -s "https://api.powerbi.com/v1.0/myorg/datasets/${DATASET_ID}/refreshes?\$top=5" \
  -H "Authorization: Bearer ${TOKEN}" \
  | jq '.value[] | {status,startTime,endTime}'

8. Summary

Chapter: 9 of 12  |  Status: v0.1 Draft  |  2026-07-08