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/08-governance-and-security/feature-sensitivity-labels.md
feature-sensitivity-labels.mdv1 · history
CurrentApplies to ServiceUpdated last monthSource Microsoft Learn ↗

What it does

Applies Microsoft Purview Information Protection labels to semantic models, reports, dashboards, dataflows and paginated reports. The label is visible in the service, travels with the data, and — this is the part that matters — applies the label's encryption settings to files exported out of Power BI.

Key facts

  • In the Power BI service, labelling does not affect access. Access is governed solely by Power BI permissions. Encryption settings are applied only when data leaves via a supported export path.
  • In Power BI Desktop it's different: a label with encryption settings does control who can open the .pbix. Without the right rights-management permissions, the file won't open.
  • Supported export paths are Excel, PDF, PowerPoint (via Export as image only), Analyze in Excel, live-connection PivotTables in Excel, and download to .pbix. Labels and encryption are not applied to .csv or any other path. Admins can block unsupported export paths.
  • New reports and dashboards inherit the label from the parent semantic model or report on creation. If the label can't be applied, Power BI doesn't block creation.
  • Downstream inheritance pushes a label applied to a semantic model or report onto content built from it. A tenant setting decides whether users tick a box each time or it happens automatically. It's capped at 80 downstream items — above that, no inheritance happens at all and only the original item gets the label.
  • Labels can be inherited from data sources; Azure Synapse Analytics and Azure SQL Database are the supported sources.
  • Mandatory label policies force users to label content they create or edit. Default label policies auto-apply a label to unlabelled content.
  • Labels persist in embedded views — embed for your organisation, Microsoft 365 apps such as Teams and SharePoint, and secure URL embedding — and survive export to Excel from those views.
  • Admin REST APIs exist to set and remove labels in bulk.
  • Not supported: Do Not Forward labels, user-defined permission labels, HYOK labels, template apps, B2B and multi-tenant scenarios.

When to use / skip

If the client already runs Purview labels across Microsoft 365, extending them to Power BI is close to free and closes an obvious hole — exported spreadsheets are how sensitive data actually escapes. If they don't have a label taxonomy yet, don't build one for Power BI alone; that's a Purview programme, not a BI task, and a taxonomy invented by the BI team will be wrong. Be blunt about what it buys: it protects exports and it gives you reporting on where sensitive content lives. It does not stop anyone in the service from opening a report they have permission to open.

Configuration decisions

  • Which existing label taxonomy applies, and whether any labels need Power BI-specific guidance in the custom help link.
  • Downstream inheritance mode: user-controlled by checkbox, or fully automatic.
  • Whether mandatory labelling, default labelling, both or neither is turned on — and what the default is, if you use one.
  • Whether unsupported export paths are blocked, which is the setting that decides whether .csv is a hole in the whole scheme.
  • Whether to run the admin APIs to backfill labels across an existing tenant rather than waiting for users to do it.

Gotchas

  • Parent labels are a trap. An item with a parent label escapes mandatory label policies, isn't inherited, and export from it fails outright. If a label acquires sublabels after it's been applied, existing items quietly land in this state.
  • Export fails when a label can't be applied — for example if the label was unpublished or deleted by the security admin. Users see a report that won't export and no obvious reason why.
  • Downstream inheritance silently does nothing past 80 items. It doesn't partially apply and it doesn't warn.
  • .csv export carries no label and no protection. If exports are the threat model, blocking unsupported paths is the control, not the labels.
  • In rare cases only the person who applied a protected label has the usage rights for it. If they leave, access to the .pbix goes with them, and recovery needs an admin running the set/remove label admin APIs.
  • Information protection doesn't support B2B or multi-tenant scenarios, so external sharing is outside the scheme entirely.
  • Publishing a .pbix with a protected label via a service principal isn't supported and will fail. Unprotected labels are fine.

Consultant notes

  • Frame this to the client as export control plus visibility, and say plainly that it isn't an access control inside the service. Getting that wrong in a steering meeting is worse than not mentioning it.
  • The protection metrics report in the admin portal is the artefact that makes this real to a CISO. Show it early.
  • Coordinate with whoever owns Purview. Power BI is a consumer of their taxonomy, and label changes made elsewhere will land on your content without warning.
  • If mandatory labelling is going on, do a comms round first. Users hitting a save block with no explanation generates more tickets than the policy is worth in its first week.

Revisit if the downstream inheritance limit changes, or if B2B scenarios pick up information protection support.

Was this accurate?
Related
Power BI vs native Dynamics 365 reporting11-decision-guidesPower BI on Dynamics 365 dashboards07-embedding-and-integrationXMLA endpoint09-alm-and-deploymentPower BI in Microsoft Teams07-embedding-and-integrationSemantic model fundamentals01-semantic-modelsPower BI in model-driven apps07-embedding-and-integration