Sensitivity labels on semantic models: Purview that report authors can follow
Purview rollouts fail when authors see twelve labels and pick Confidential on everything — or nothing. Power BI inherits sensitivity labels from the semantic model onto reports, exports, and (when configured) downstream files. That only helps if the model label is right.
Three labels, not a taxonomy novel
| Label | Use on | Export / share behavior (illustrative) |
|---|---|---|
| Public / General | Published KPIs already in the annual report | Free to export |
| Internal | Default for certified models | Org-only, watermark optional |
| Restricted | PII, M&A, payroll, pre-earnings | Block download / guest share; encryption if your MIP policy says so |
Map these to existing Microsoft Information Protection labels. Do not invent a parallel BI-only scheme.
Label the model first
- Apply the label on the semantic model (or lakehouse/warehouse where your policy starts)
- Confirm inheritance on reports and org apps
- Test Export to Excel and Analyze in Excel — this is where labels earn their keep
- Test a guest user path if partners exist
RLS is not a sensitivity label. RLS hides rows. Labels travel with the file when someone exports what they can see.
Author experience
- Default label on new models in prod workspaces: Internal
- Promote to Restricted is a pipeline checklist item, not a hope
- Support ticket template: “wrong label” with who can re-classify (security group, not each author)
Admin gotchas
- Labels require the right Fabric / Power BI and Purview licenses and tenant switches
- Service principals used for refresh should not need to decrypt every Restricted file in the lake to succeed — design the Gold layer so refresh identities see what they must
- Do not label Dev sandbox the same as Prod payroll. Over-classification trains people to ignore banners
Standing up three MIP labels that survive first contact with report authors? Book a 30-minute call.