Power BI Service: Publishing, Sharing and Workspaces

Building a report in Power BI Desktop is half the job. The other half happens in the Power BI service: getting the report to the right people, with the right access, refreshed on schedule and secured. Most mistakes at this stage are not technical; they are about who can see what. This guide covers publishing, workspaces and their roles, licences, the main ways to share, and what sharing actually exposes.

Publishing

From Power BI Desktop, Publish sends the file's semantic model and its reports to a workspace you choose (Microsoft Learn: publish from Desktop). The service then holds two items, the semantic model and the report. Edits made to the report in the service are not saved back to your Desktop file, so pick one place to edit and stick to it; for team work, keep the Desktop file as the source and republish.

Workspaces and roles

A workspace is a shared container for semantic models, reports, dashboards and other items. My workspace is personal; shared workspaces are where teams collaborate. Access is granted through four roles (Microsoft Learn: workspace roles):

Assign roles to groups rather than individuals where possible; a person in several groups gets the highest role among them. One detail matters for security: row-level security applies only to Viewers, so anyone given Contributor or above sees all the data. Row-level security in Power BI explains.

Licences decide who can share and view

• Shared capacity: everyone added to a workspace needs a Pro or Premium Per User licence, and sharing requires Pro or PPU for both sender and recipient.
• Premium or Fabric capacity: Viewers can access content without a Pro licence. Microsoft notes this applies to P SKUs and to F SKUs of F64 or larger; smaller F SKUs still require Pro for viewers.
• Publishing to a workspace requires Pro or PPU.

Check which capacity a workspace uses before promising access to a large audience.

Choosing how to share

Microsoft's own guidance maps scenarios to methods (Microsoft Learn: sharing):

For most organisational reporting, apps are the best default. An app packages chosen reports and dashboards from a workspace into a read-only experience, distributed to groups or everyone, with its own navigation. Authors keep working in the workspace and update the app when changes are ready, so readers never see work in progress. Deployment pipelines add development and test stages before the production workspace behind the app.

Sharing links come in three types: People in your organization, which works for anyone internal who has the link; Specific people, including guest users; and People with existing access, which grants nothing new. Links can optionally allow resharing and Build permission.

What sharing really exposes

Microsoft's documentation is emphatic on this: when you share a report, you also share access to its underlying semantic model. A reader's access is not limited to what the report shows. Hiding a table, column, measure, visual or page is not a security measure; readers with access can still reach the data, for example through Analyze in Excel if they have Build permission. To restrict data, use row-level security for rows and object-level security for columns and tables.

Publish to web deserves a special warning. It makes a report publicly accessible on the internet without sign-in, including the underlying data in the semantic model. Use it only for data that is genuinely public, and check your organisation's policy first.

Keeping it running

Published content needs ongoing care:

• Refresh: schedule it in the semantic model's settings; data refresh covers limits and failures.
• Gateways: needed for data on private networks; see the gateway guide.
• Endorsement: mark trusted semantic models as promoted or certified so authors reuse them.
• Formatted, printable output: paginated reports cover invoices and pixel-perfect documents.

A publishing checklist

1. Publish to a shared workspace, not My workspace, for anything others rely on.
2. Give edit roles only to people who build content; everyone else is a Viewer or an app user.
3. Confirm refresh is scheduled and succeeding.
4. Apply row-level security where data must be restricted, and test it.
5. Distribute through an app, and update the app deliberately.
6. Never use Publish to web for internal data.

Publishing reports to the Power BI service, sharing dashboards, workspace management and scheduled refresh are part of the Power BI service and deployment module of the Power BI course.

Sources

• Roles in workspaces in Power BI (Microsoft Learn) — Microsoft Learn
• Share and collaborate on Power BI reports and dashboards (Microsoft Learn) — Microsoft Learn
• Publish from Power BI Desktop (Microsoft Learn) — Microsoft Learn