Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

power-bi/05-service-and-workspaces/feature-sharing-and-distribution.md
feature-sharing-and-distribution.mdv1 · history
CurrentApplies to ServiceUpdated last monthSource Microsoft Learn ↗

What it does

The set of routes content takes from a workspace to a consumer: direct sharing with named people, shareable links, workspace Viewer access, apps, Teams, and external sharing through Microsoft Entra B2B. They all grant permission on the underlying semantic model as well as the report.

Key facts

  • Three link types when you share a report. "People in your organisation" works for anyone signed in to the tenant but never for guests. "Specific people" names individuals or groups and does work for B2B guests. "People with existing access" grants nothing — it's just a URL.
  • Link settings default to including Reshare and excluding Build. Build permission is what lets recipients create their own reports on the model.
  • Reports can be shared by link. Dashboards can be shared by direct access only.
  • A single report supports up to 1,000 sharing links. The dashboard sharing box takes up to 100 users or groups at a time.
  • Free-licence recipients need both the report and its semantic model on capacity. A report on capacity fed by a model in a non-capacity workspace still prompts them to upgrade.
  • External sharing needs the tenant setting on. Recipients get an emailed link, sign in, and see the item in a standalone browser window rather than the normal portal. Access is tied to the exact email address invited — forwarding the link doesn't work.
  • Microsoft 365 unified groups can't be used for direct sharing or email subscriptions. Security groups and mail-enabled distribution groups can. For external members, it has to be a security group.
  • Publish to web puts the report and all of its data on the public internet with no authentication. It's a separate feature with its own risks.

When to use / skip

Ranked, roughly: apps first for anything with an audience, workspace roles for the people who build, direct sharing for genuine one-offs, external sharing when there's a contractual reason and someone has thought about it. Direct sharing is the one people over-use — it feels quick, and six months later nobody can answer "who can see the margin report". If you find yourself sharing the same report to the fifth person, stop and publish an app.

Configuration decisions

  • Whether "people in your organisation" links are allowed at all. Turning them off in tenant settings forces everything through named people or existing access, which is a defensible position in a regulated client.
  • Whether Build permission travels with shared content, which decides whether consumers become authors.
  • Whether external sharing is enabled, and whether B2B guests can edit and manage content — two separate tenant settings.
  • Whether distribution runs on security groups or named users. Groups every time, unless the audience is genuinely three people.
  • Whether Publish to web is disabled outright. On most tenants it should be.

Gotchas

  • Sharing a report shares the whole semantic model. The consumer sees every table, column and row in it through Analyze in Excel or export, regardless of what the report displays. Hidden isn't secure — only RLS and OLS are.
  • Removing someone's access to a dashboard doesn't automatically remove access to the related reports and models. There's a prompt for it and people click past it.
  • Reports distributed to you inside an app can't be reshared. The consumer has to go back to the app owner, which surprises them every time.
  • On-premises Analysis Services models with role-based security show external users no data at all.
  • Direct-access sharing sends an email notification to individuals but not to groups, so group members find out by being told.

Consultant notes

  • Draw the distribution model on a whiteboard in week one: who builds, who reviews, who consumes, and by what route. It takes an hour and prevents most of the access chaos that shows up at month three.
  • The "sharing a report shares the model" point is worth stating explicitly to anyone with sensitive data. Most business users assume the report is the boundary. It isn't.
  • Publish to web comes up in almost every project as "can we just put it on the intranet". Answer the actual requirement — embedding, or a public-facing report with no data sensitivity — rather than saying no flat.
  • Guest access is more work than clients expect: Entra B2B invitations, tenant settings, and in some flows the Directory Readers role. Scope it as a piece of work, not a checkbox.

Have another look if the tenant sharing settings get reorganised again, or if guest access requirements change.

Was this accurate?
Related
Power BI apps05-service-and-workspacesPower BI in Microsoft Teams07-embedding-and-integrationFree users and content viewing10-licensingWorkspaces and workspace roles05-service-and-workspacesWorkspace and model topology11-decision-guidesPower BI licensing overview10-licensing