Data Governance in Microsoft Fabric: Purview Integration, Sensitivity Labels, and Access Control

A Canadian financial services firm migrating from Azure Synapse to Microsoft Fabric raised a concern that comes up in nearly every regulated-industry deployment: “We can see all the data engineering benefits, but our compliance team needs to know who can access what data, where sensitive data lives, and how data flows from source systems to the reports our executives use. How does Fabric answer those questions?”

Data governance is where enterprise data platform migrations either succeed or stall. The technical architecture of a Lakehouse or a DirectLake semantic model matters — but if the governance model is opaque or disconnected from existing organisational tools, regulated industries cannot adopt the platform at all. This post covers what Microsoft Fabric’s governance model actually provides, where it is strong, and where it requires supplemental controls.

Why Governance Is the Hard Part of Unified Platform Migration

Most data platform migrations focus on the technical migration: moving Spark jobs from Synapse to Fabric, rebuilding pipelines, validating query outputs. Governance is often treated as an afterthought — something to “sort out after we go live.”

This is a mistake. Governance decisions made post-migration are much harder to enforce than those designed into the architecture from the start. Which teams can write to the Silver Lakehouse? Who can create Power BI reports that expose salary data? How do you ensure that a developer’s test Lakehouse cannot access production personal data? These questions require architectural answers, not documentation.

Microsoft Fabric’s governance architecture addresses these questions through a layered model: workspace roles for platform access, item-level permissions for fine-grained sharing, row-level and object-level security in semantic models, sensitivity labels from Microsoft Purview, and automated cataloguing and lineage via Purview scanning.

Microsoft Purview’s Role in Fabric

Microsoft Purview is Microsoft’s unified data governance product — a separate Azure service that scans, classifies, and catalogues data assets across an organisation’s data estate. Fabric integrates with Purview in two directions:

Purview scans Fabric: Purview can scan Fabric workspaces, cataloguing Delta tables in Lakehouses, semantic model schemas, and KQL Databases. Scanned items appear in the Purview Data Catalog with inferred schema, data classification (detecting columns that contain PII, financial data, or other sensitive content categories), and lineage.

Fabric inherits Purview sensitivity labels: Sensitivity labels defined in Microsoft Purview Information Protection (formerly Azure Information Protection) propagate through Fabric. A label applied to a Delta table in OneLake is inherited by Power BI reports that read from that table in DirectLake mode — the report carries the same sensitivity label as its source data.

For Canadian organisations with existing Microsoft 365 E5 licensing, Purview capabilities are often already licensed. The integration with Fabric extends the governance model that applies to SharePoint, Teams, and Office documents into the data engineering layer — a coherent extension of an existing investment.

Sensitivity Labels: End-to-End Data Classification

Sensitivity labels are the most practically impactful Purview integration in Fabric for regulated industries. The flow works as follows:

1. A Purview administrator defines sensitivity labels (e.g., “Public”, “Internal”, “Confidential”, “Highly Confidential - PII”)
2. A data engineer applies the “Highly Confidential - PII” label to the customer_pii Delta table in the Silver Lakehouse
3. When a Power BI developer creates a DirectLake semantic model that includes the customer_pii table, the semantic model inherits the “Highly Confidential - PII” label automatically
4. Any Power BI report created from that semantic model also inherits the label
5. When a user downloads report data to Excel, the Excel file carries the sensitivity label, which enforces encryption and restricts sharing based on the label’s policy

This end-to-end label propagation — from OneLake Delta table through semantic model to downstream reports and exports — is unique to the Microsoft stack. No other data platform provides this level of label inheritance across the full analytics chain.

Practical governance use case: A Fabric deployment for a payroll analytics application applies a “Highly Confidential - HR” sensitivity label to the compensation tables in the Gold Lakehouse. Power BI reports based on those tables cannot be published to a workspace where non-HR users have access; the label policy blocks export of report data to CSV by default; and the Purview audit log captures every access event.

Workspace Roles: The Foundation of Fabric Access Control

Fabric workspaces use a four-role model:

Role	Capabilities
Admin	Manage workspace settings, add/remove members, delete workspace
Member	Create and edit items, share items, manage permissions on items
Contributor	Create and edit items, run notebooks and pipelines
Viewer	Read items (Lakehouses, reports, semantic models) but cannot create or edit

The least-privilege principle applied to Fabric workspaces:

• Data engineers working in development workspaces: Contributor
• Data engineers in production workspaces: Contributor (cannot manage workspace settings; only Admins can modify the workspace configuration)
• BI developers who create Power BI reports: Contributor (to create reports) or Member (if they also need to share items)
• Business users consuming Power BI reports: Viewer
• No end user should have Admin or Member access to production data workspaces

A critical architectural decision: separate workspaces for dev, test, and production. In a single-workspace architecture, a developer with Contributor access can read production data by querying Lakehouse tables directly. In a three-workspace architecture with separate Lakehouses, production data is isolated in its own workspace, and developers access it only through the interfaces (Power BI reports, shared semantic models) that have row-level security applied.

Item-Level Permissions: Sharing Without Workspace Access

Workspace roles grant access to everything in a workspace. Item-level permissions allow sharing a specific Lakehouse, Warehouse, or semantic model with a user who does not have workspace membership.

A common pattern: the Gold Lakehouse contains multiple business domain tables (finance, HR, operations). The finance team should see finance tables; the HR team should see HR tables. Rather than creating separate Gold Lakehouses for each domain (which multiplies the number of workspaces and Lakehouses to manage), you use item-level permissions:

• Grant the finance team ReadAll permission on the Gold Lakehouse (access to all tables)
• Grant the HR team access only to the hr_semantic_model semantic model (not the Lakehouse directly), with row-level security applied within the model

This pattern keeps the data engineering architecture simple (one Gold Lakehouse) while enforcing appropriate data access boundaries at the item and model layer.

Row-Level Security and Object-Level Security in Semantic Models

Row-level security (RLS) is applied in Power BI semantic models using DAX filter expressions. An RLS role definition specifies which rows a user can see when they access the model through a Power BI report.

Example RLS for a regional sales model where managers see only their region’s data:

[region_code] = LOOKUPVALUE(
    DimUser[region_code],
    DimUser[email_address],
    USERPRINCIPALNAME()
)

When a user from vancouver.manager@company.ca opens a sales report, Power BI evaluates this RLS filter, looks up their region_code in the DimUser table, and limits all sales data to that region. The filter is invisible to the user and cannot be bypassed from the report interface.

Object-level security (OLS) hides entire columns or tables from specific roles. A useful pattern for compensation data: define an OLS rule that hides the base_salary and bonus_amount columns for all roles except the “HR Analytics” role. Users outside that role see the employee table but cannot see salary columns — even if they try to access the data via Excel connected to the semantic model.

Limitation: RLS and OLS in Fabric apply at the semantic model layer. A user with direct Lakehouse access (Viewer or higher workspace role, or ReadAll item permission on the Lakehouse) can query the underlying Delta tables via the SQL analytics endpoint or a Spark notebook and bypass RLS. For data that requires strict row-level protection at the storage layer, access to the Lakehouse itself must be restricted, and data access must be channelled through semantic models.

Data Lineage in Fabric: Tracing a Measure to Its Source

Fabric’s workspace lineage view provides a visual map of dependencies between Fabric items. For a Power BI report, you can trace:

Power BI Report → Semantic Model → Gold Lakehouse (Delta table)
                                ↑
                         Silver Lakehouse (Delta table)
                                ↑
                          Bronze Lakehouse (Files zone)
                                ↑
                          Eventstream / Pipeline (source)

This lineage view — available in the Fabric portal via the workspace view — is sufficient for impact analysis (if I change this Delta table schema, which reports break?) but is not as detailed as the end-to-end lineage available in Microsoft Purview.

Purview’s lineage captures column-level lineage (which source columns contribute to which output columns in a transformed table), cross-workspace lineage, and lineage to systems outside Fabric (SQL Server, Salesforce, SAP via Purview connectors). For compliance reporting that requires detailed lineage documentation, Purview is the appropriate tool.

Managed Private Endpoints for Regulated Environments

For regulated industries where Fabric workloads must not traverse public internet networks, Fabric supports managed private endpoints — private network connections from Fabric’s managed VNet to resources in your organisation’s Azure VNet (SQL Server, Azure Key Vault, on-premises data sources via ExpressRoute or VPN Gateway).

Managed private endpoints require an F64 or higher capacity SKU. For Canadian financial services firms operating under OSFI B-10 guidance on third-party risk, the managed private endpoint configuration is typically a requirement for production Fabric deployments that connect to core banking or trading systems.

Compliance Use Case: Canadian Financial Services

For Canadian financial services organisations evaluating Fabric under OSFI and PIPEDA:

PIPEDA compliance: Microsoft’s Data Processing Agreement for Fabric includes the standard PIPEDA-relevant provisions for Canadian data processors — data residency options (Canada Central and Canada East regions), data handling terms, breach notification commitments, and subprocessor transparency. Organisations must ensure Fabric capacity is provisioned in a Canadian Azure region.

OSFI B-10 (Third-Party Risk Management): OSFI B-10 requires federally regulated financial institutions to conduct technology risk assessments for material third-party arrangements. For Fabric, this includes reviewing Microsoft’s SOC 2 Type II and ISO 27001 certifications, assessing concentration risk (Microsoft as a dominant cloud provider), and documenting the contractual and operational controls in the Microsoft Customer Agreement and Data Processing Agreement.

Quebec Law 25 (Act 25): Quebec’s stricter provincial privacy law requires explicit data subject rights (access, correction, deletion) for personal data processed by Quebec-based organisations. Fabric’s Purview integration supports data discovery (locating where PII is stored) and sensitivity classification; deletion workflows for data subject requests require process-level documentation beyond what Purview automates.

Comparison: Fabric Governance vs AWS Lake Formation + Glue Data Catalog

Capability	Fabric + Purview	AWS Lake Formation + Glue Catalog
Data cataloguing	Purview (automatic scan)	Glue Data Catalog (crawler-based)
Column-level security	OLS in semantic models only	Lake Formation column-level grants
Row-level security	RLS in semantic models	Lake Formation row-level filters (Iceberg)
Sensitivity labelling	Microsoft Purview (propagates to BI)	AWS Macie (classification, no propagation)
Data lineage	Fabric lineage view + Purview	AWS Glue lineage (limited)
Cross-cloud governance	Purview supports multi-cloud scanning	Lake Formation AWS-native only

AWS Lake Formation’s column-level and row-level security at the storage layer is more mature than Fabric’s — Lake Formation grants enforce access at the S3 / Iceberg table level, not just at the BI semantic model layer. For organisations with strict storage-layer access control requirements, this gap in Fabric is meaningful.

See our related guide on migrating from Azure Synapse to Microsoft Fabric for how governance configurations migrate from Synapse to Fabric.

Conclusion

Microsoft Fabric’s governance model — workspace roles, item-level permissions, semantic model RLS/OLS, and Purview sensitivity label integration — is coherent and practical for most enterprise environments. Its strongest differentiator is the end-to-end sensitivity label propagation from OneLake through Power BI, which no other platform currently matches. Its primary gap is the absence of storage-layer row-level security — a limitation that requires architectural compensating controls in high-sensitivity deployments.

Evaluating Microsoft Fabric for your organisation? Infra IT Consulting helps Canadian and international businesses assess, architect, and implement modern data platforms. Book a discovery call →