11.2 Sensitivity Labels, Item Access, and Governance
Key Takeaways
- Sensitivity labels from Microsoft Purview classify content (Public, General, Confidential, Highly Confidential) and can enforce encryption, watermarks, and export blocks.
- Labels inherit downstream (a Confidential model passes Confidential to its reports and exports) and apply the most restrictive label; they can block an export even when Report settings allow it.
- Sharing a report grants View plus automatic Read on the model; Build lets a user author new reports and Reshare lets them grant access - 'author but not share' needs Build without Reshare.
- Lineage view diagrams the data flow from source to dashboard; Impact analysis quantifies how many reports, dashboards, users, and workspaces depend on a model before a breaking change.
- Governance best practice: label at creation with inheritance, certify a single-source model, control Build, manage access via security groups, and use deployment pipelines for promotion.
Quick Answer: Sensitivity labels come from Microsoft Purview and classify content (Public, General, Confidential, Highly Confidential), optionally enforcing encryption, watermarks, and export limits; they inherit downstream and travel with exports. Item-level access governs who can view/reshare a report; semantic-model permissions (Read, Build, Reshare, Write) govern who can author from a dataset. Lineage view and Impact analysis show data flow and the blast radius of a change before you make it.
Sensitivity labels
Labels are defined in the Microsoft Purview compliance portal, enabled by the Power BI/Fabric admin, and require users to be licensed for Microsoft Purview Information Protection.
| Label | Typical meaning | Typical enforcement |
|---|---|---|
| Public | Shareable externally | None |
| General | Internal, non-sensitive | Basic marking |
| Confidential | PII/financial/competitive | Encryption, restricted sharing |
| Highly Confidential | PHI, material non-public, classified | Strong encryption; can block export/screenshots |
Apply a label in the service (Settings -> Sensitivity label) or in Desktop (Home -> Sensitivity).
Inheritance and enforcement
Labels propagate downstream: a Confidential semantic model passes Confidential to every report built on it, and exports (PDF, Excel, PowerPoint, .pbix download) carry the label. Downstream content takes the most restrictive applicable label. Enforcement can include encryption of exported files, watermarks/content marking, export restrictions (a Highly Confidential label can block Excel/PDF export and screenshots), and access restrictions. This is why an export permitted in Report settings can still be blocked at run time by the label's policy.
Item-level and semantic-model permissions
When you share a report, the recipient gets View on the report plus Read on the underlying model automatically. Two checkboxes add more:
- Allow recipients to share -> Reshare.
- Allow recipients to build content -> Build on the model.
Semantic-model permissions to know:
| Permission | Allows |
|---|---|
| Read | View data via existing reports |
| Build | Connect to the model and create new reports |
| Reshare | Grant access to others |
| Write | Modify the model (rare) |
The most-tested pairing: a user who must author their own reports but not share the model needs Build without Reshare.
Lineage and impact analysis
Workspace -> Lineage view draws the data flow: sources -> dataflows -> semantic models -> reports -> dashboards, with refresh status and dependencies. Before a breaking change, run Impact analysis (semantic model -> More options -> Impact analysis) to see how many reports, dashboards, users, and workspaces depend on the model. Use it before renaming/removing columns, changing types or relationships, or deprecating a source. Lineage shows the diagram; Impact analysis gives the quantitative blast radius.
Governance best practices
- Apply sensitivity labels to datasets and reports at creation and rely on inheritance.
- Promote a certified semantic model as the single source of truth.
- Control Build to govern who can create content from a model.
- Check lineage/impact analysis before changing shared models.
- Manage access with security groups, not individuals.
- Monitor with admin protection metrics (label coverage, export activity) and the admin/scanner APIs.
- Use deployment pipelines for controlled dev -> test -> prod promotion (covered fully in 11.3).
Sensitivity labels vs. RLS — two different protections
A classic exam confusion is treating sensitivity labels and RLS as interchangeable. They are orthogonal. RLS controls which rows a user sees inside the report based on role membership. A sensitivity label classifies the content and enforces protection (encryption, export limits, watermarks) that travels with exports — but a label does not filter rows. A Confidential label still lets an authorized viewer see every row the model exposes; it just stops them from, say, emailing an unencrypted Excel extract outside the org.
Robust governance often uses both: RLS so each manager sees only their region, and a Confidential label so any export of that data stays encrypted.
The permission ladder, end to end
Walk the full chain the exam tests. To view a report, a user needs report access (View) + Read on the model — granted automatically when you share. To build their own reports from the model, they need Build. To grant others access, they need Reshare. To change the model, they need Write (rare). Two checkboxes in the Share dialog map directly to these: "Allow recipients to share" grants Reshare; "Allow recipients to build content" grants Build. The frequently tested combination — "let an analyst create reports from our certified model but not hand the model to anyone else" — is Build without Reshare.
Granting Read only would block report creation entirely.
Governance tooling beyond labels
Two service tools round out governance. Lineage view (workspace toolbar) draws the dependency graph from sources through dataflows and semantic models to reports and dashboards, with refresh-status badges — use it to see how things connect. Impact analysis (semantic model -> More options) gives the numbers: how many reports, dashboards, users, and workspaces depend on this model, so you can gauge the blast radius before renaming a column, changing a data type, altering a relationship, or deprecating a source.
Pair these with endorsement (Promoted/Certified) and admin protection metrics (label coverage, export activity) for a complete governance posture, and prefer security groups over individual grants so access stays auditable.
On the exam
Common items: a report built on a Confidential model inherits Confidential; Build without Reshare lets a user author but not share a model; Impact analysis quantifies affected reports/users before a change while Lineage view shows the dependency diagram; a sensitivity label can block/encrypt an export even when export is otherwise allowed; and RLS (row filtering) is distinct from sensitivity labels (classification/protection) — they are often used together.
A dataset is labeled "Confidential" in the Power BI Service. A user creates a new report from this dataset. What sensitivity label does the new report inherit?
A user needs to create their own reports using a published semantic model but should NOT be able to share it with others. Which permissions should you grant?
Before renaming a column in a shared dataset, you want to understand how many reports and users will be affected. Which feature should you use?
A report's export settings allow PDF export, but a user cannot export it to PDF. What is the most likely cause?