OneLake Governance & Security: Domains and Access
A practitioner's guide to OneLake governance and security in Microsoft Fabric — domains, workspaces, access control, and a layered model that scales.
Microsoft Fabric collapses data engineering, warehousing, real-time analytics, data science, and business intelligence onto a single logical data lake called OneLake. That consolidation is the platform's greatest strength and its sharpest governance risk. When every team, every workload, and increasingly every AI agent reads and writes from the same lake, a sloppy access model does not stay local — it becomes an organisation-wide exposure.
This post is a practitioner's guide to OneLake governance and OneLake security: how to use Fabric domains, workspaces, and a layered access model to keep a fast-growing data estate both usable and defensible. It is grounded in how we design Fabric platforms at CC Conceptualise — not in marketing diagrams.
TL;DR / Key takeaways
- Governance in Fabric is layered: domains delegate ownership by business area, workspaces are the security boundary, and OneLake access roles enforce folder- and table-level least privilege inside a lakehouse.
- Design domains top-down from your operating model and workspaces bottom-up from delivery teams. One shared mega-workspace is the most common and most damaging anti-pattern.
- OneLake shortcuts are convenient but cross a trust boundary — treat every one as a documented data-sharing decision with a named owner.
- Fabric domains and Microsoft Purview are complementary: domains organise governance inside Fabric, Purview provides cross-estate classification, lineage, and sensitivity labels.
- The domain/workspace/access structure you build is the same evidence base GDPR, the EU AI Act, DORA, and NIS2 auditors expect. Design it for compliance from day one.
Why OneLake Changes the Governance Problem
In a traditional estate, each system had its own storage, its own access model, and its own blast radius. A misconfigured permission in the CRM database did not expose the finance warehouse. OneLake removes those walls by design. Every workspace's data is a folder in one tenant-wide lake, addressable through a single namespace and readable by any engine — Spark, T-SQL, KQL, Power BI, and the new generation of Fabric Data Agents that query data autonomously.
That unification is exactly why customers adopt Fabric. It is also why governance must be deliberate rather than emergent. The questions you have to answer are no longer "which database holds this," but "who owns this body of data, who is allowed to touch which slice of it, and how do I prove that the answer is correct." Domains, workspaces, and access roles are the three instruments for answering those questions.
The Three Layers of OneLake Governance
It helps to think of Fabric governance as a hierarchy where each layer has one job.
| Layer | Scope | Primary purpose | Who manages it |
|---|---|---|---|
| Domain | A group of workspaces for a business area | Delegate ownership, apply tenant-level policy, shape the OneLake data hub | Tenant admin + domain admins |
| Workspace | A collection of items (lakehouses, warehouses, models, reports) | The collaboration and security boundary; lifecycle stage | Workspace admins |
| Item & OneLake access role | A single item, or folders/tables within a lakehouse | Least-privilege data access; row/column security | Item owners, data engineers |
The mistake we see most often is conflating these layers — using workspaces as if they were domains, or granting workspace-wide roles where an item-level or folder-level grant would do. Each layer exists precisely so you do not have to over-grant at the one above it.
Domains: organising by business meaning
A Fabric domain is a logical grouping of workspaces that maps to a part of your operating model — Finance, Supply Chain, Customer, Manufacturing. Domains are where you delegate governance: a domain admin can set default sensitivity labels, control who may create workspaces in the domain, and curate which data products appear in the OneLake data hub for that business area. Subdomains let you reflect organisational depth without sprawl.
Design domains top-down. Start from your business capability map or your data-product taxonomy, not from the teams that happen to exist today. A domain should outlive a reorg; a workspace often will not.
Workspaces: the real security boundary
A workspace is where items live and where most access decisions are enforced through four built-in roles:
| Role | Can view | Can build/edit | Can manage access | Typical assignee |
|---|---|---|---|---|
| Admin | Yes | Yes | Yes | Platform/data product owner |
| Member | Yes | Yes | Yes (add others) | Senior engineers |
| Contributor | Yes | Yes | No | Engineers, analysts who build |
| Viewer | Yes | No | No | Business consumers |
Because the workspace is the security boundary, its granularity determines your blast radius. The pattern we apply on delivery is one workspace per data product per lifecycle stage — for example sales-dev and sales-prod — grouped under the domain that owns sales data. This keeps deployment pipelines clean, makes access reviews tractable, and means a mistake in a development workspace never touches production data. For how this lakehouse layering maps onto bronze/silver/gold zones, see our Fabric medallion architecture guide.
OneLake access roles: least privilege inside the lake
Workspace roles are coarse — a Viewer sees everything in the workspace. Real-world data rarely respects that granularity. OneLake data access roles let you define security at the folder and table level inside a lakehouse: a role might grant read on the gold schema's curated tables while denying access to the raw bronze landing zone that still contains unmasked personal data.
You then compose this storage-layer security with the query-layer controls you already know:
- OneLake data access roles — folder- and table-level read scoping inside the lakehouse.
- Row-level security (RLS) — restrict rows by user identity in the SQL endpoint and semantic model.
- Column-level security (CLS) — hide or mask sensitive columns.
- Object-level security (OLS) — hide entire tables or columns in the semantic model.
- Sensitivity labels — classification that travels with the data and governs export.
The discipline is least privilege at every layer rather than one broad grant at the top. A consumer of a gold dataset should never need Contributor on the workspace that produces it.
Shortcuts and the Trust Boundary
OneLake shortcuts are one of Fabric's most useful features and one of its quietest risks. A shortcut is a pointer — to another lakehouse, to ADLS Gen2, or to an external store such as S3 — that makes remote data appear local without copying it. Access is evaluated against both the OneLake permission model and the source's own access controls.
Two failure modes recur. The first is over-exposure: a shortcut surfaces source data to a workspace audience broader than the source ever intended. The second is ambiguous authority: nobody can say anymore where the authoritative copy of a dataset actually lives, which undermines lineage and breaks regulatory provenance claims. Treat every shortcut as a deliberate, documented data-sharing decision with a named owner and a recorded justification — never as a quick convenience to avoid a pipeline.
The same caution applies to AI access. When a data agent or an Eventhouse query layer reaches across workspaces — for instance via the patterns in our piece on Fabric Eventhouse and the remote MCP — it inherits the identity and permissions it runs under. Governance has to account for non-human consumers, not just people.
Domains vs. Purview: Who Does What
A frequent question from CISOs is whether Fabric domains replace Microsoft Purview. They do not; they complement it.
| Capability | Fabric domains | Microsoft Purview |
|---|---|---|
| Organise workspaces by business area | Yes | No |
| Delegate governance to domain owners | Yes | Partially |
| Cross-estate data catalogue | Fabric only | Yes (Fabric + beyond) |
| Sensitivity labels & classification | Consumes labels | Defines & applies labels |
| Lineage across systems | Within Fabric | End-to-end |
| Data loss prevention / policy | Limited | Yes |
In practice you define classification, sensitivity labels, and DLP policy in Purview, and those labels flow through to Fabric items and any downstream export. You then use domains to organise and delegate the day-to-day governance experience inside Fabric. Govern classification once, enforce it everywhere.
A Practical Rollout Sequence
When we stand up OneLake governance for an enterprise, the order of operations matters as much as the design:
- Map domains to your operating model before creating a single workspace. Agree owners.
- Define the workspace pattern — one per data product per lifecycle stage — and templatise it.
- Integrate Purview so sensitivity labels and DLP exist before sensitive data lands.
- Codify access — workspace roles and OneLake data access roles defined through deployment pipelines or APIs, not portal clicks.
- Govern shortcuts with an approval and ownership register.
- Schedule access reviews per domain owner on a fixed cadence to catch drift.
This sequence makes governance a property of the platform rather than a remediation project after the first audit finding.
Governance Is Your Compliance Evidence Base
For European enterprises this is not abstract. GDPR demands you know where personal data lives and who can access it. The EU AI Act expects provenance and access control over training and grounding data. DORA and NIS2 require demonstrable control over critical data assets and their supply chain. Every one of those obligations is satisfied by the same artefacts: a clear domain ownership map, scoped workspaces, least-privilege access roles, and Purview-driven classification and lineage. Build the structure once and it serves both your engineers and your auditors.
FAQ
What is the difference between a Fabric domain and a workspace for governance?
A domain is an organisational grouping of workspaces that maps to a business area — finance, supply chain, customer — and is the unit where you delegate ownership and apply tenant-level governance policy. A workspace is the actual security and collaboration boundary where items live and where you assign roles. Domains answer who owns and governs a body of data; workspaces answer who can touch specific items. You design domains top-down from your operating model and workspaces bottom-up from delivery teams.
How does OneLake access control actually work?
Access is layered. Workspace roles (Admin, Member, Contributor, Viewer) grant coarse access to everything in a workspace. Item-level permissions narrow that down to a single lakehouse, warehouse, or semantic model. OneLake data access roles then enforce folder-level and table-level security inside a lakehouse, and you compose these with row-level and column-level security in the SQL and semantic layers. The principle is least privilege at each layer, not a single broad grant at the top.
Should every team get its own workspace in Fabric?
Usually yes, with structure. A workspace is the security boundary, so collapsing many teams into one shared workspace forces you to over-grant access. The pattern we use is one workspace per team per lifecycle stage — for example a development and a production workspace per data product — grouped under the domain that owns that business area. This keeps blast radius small and makes deployment pipelines and access reviews straightforward.
How do Fabric domains relate to Microsoft Purview?
They are complementary, not duplicative. Fabric domains organise and delegate governance inside Fabric and drive the experience of the OneLake data hub. Microsoft Purview provides the cross-estate catalogue, data classification, sensitivity labels, lineage, and policy that span Fabric and the rest of your data landscape. Sensitivity labels applied in Purview flow through to Fabric items and downstream exports, so you govern classification once and enforce it everywhere.
Can OneLake shortcuts create a security gap?
They can if you ignore the trust boundary. A shortcut is a pointer to data living elsewhere — another lakehouse, ADLS Gen2, or S3 — and access is evaluated against the source as well as the OneLake permission model. The risk is accidentally exposing source data more broadly than intended, or losing track of where authoritative data actually lives. Treat every shortcut as a documented data-sharing decision with a named owner, not a convenience.
What does OneLake governance have to do with EU regulation?
Data governance is the substrate that GDPR, the EU AI Act, DORA, and NIS2 all depend on. You cannot demonstrate lawful processing, data minimisation, or AI training-data provenance without knowing where data lives, who can access it, and how it is classified. The domain, workspace, and access-role structure you build in OneLake is precisely the evidence base auditors and regulators expect — so it pays to design it for compliance from the start, not retrofit it later.
How do we keep OneLake access under control as the platform grows?
Treat access as code and review it on a cadence. Define workspace roles and OneLake data access roles through deployment pipelines or APIs rather than manual portal clicks, scope everything to least privilege, and run a periodic access review per domain owner. Pair this with sensitivity labels and Purview lineage so that drift — orphaned grants, over-broad shortcuts, unlabeled sensitive data — surfaces before it becomes an incident.
Designing or hardening a Microsoft Fabric platform and want the governance and security model right from the first workspace? Explore our AI & Data Platform Engineering services or get in touch — we have delivered this.
Topics