Subscribe
Share
Share
Embed
Fabric domains look like security boundaries. They're metadata. Every user in your tenant can see every domain name, the contributor role only matters in the hands of someone who is already a workspace admin, and the default domain keeps running when nobody's watching. This episode opens up what a domain actually is — and the specific trap teams walk into when they treat a label as a wall.
Episode 38 • 2026-09-18 Duration: 9:13
Fabric domains look like security boundaries. They're metadata. Every user in your tenant can see every domain name, the contributor role only matters in the hands of someone who is already a workspace admin, and the default domain keeps running when nobody's watching. This episode opens up what a domain actually is — and the specific trap teams walk into when they treat a label as a wall.
AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.
Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.
Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.
This podcast was generated by AI. Both voices are synthetic: Matthias is a cloned voice, Fabia is a designed AI co-host.
Brand design based on fabricperiodictable.com.
Architecture decisions for Microsoft Fabric. Anonymized real customer scenarios, cost realism, counter-arguments included. Weekly episodes aligned with Fabric Friday recordings.
The Fence That Isn't There
Episode 38 | 2026-09-18
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Matthias: A governance team names a domain after their most confidential initiative. Assigns the sensitive workspaces. Goes home on Friday thinking the boundary's in place.
[00:18] Fabia: Every user in the tenant can read that domain name.
[00:22] Matthias: The name?
[00:22] Fabia: Today we take apart what a Fabric domain actually is — what it genuinely gives you, and where it stops being honest when teams treat it as a fence.
[00:32] Fabia: So here's what a domain actually attaches. When you assign a workspace to a domain, every item in that workspace gets a domain attribute in its metadata. That attribute feeds two things — a filter in the OneLake catalog, and an anchor for delegated tenant settings like sensitivity labels and certification rules. And that's essentially it — domain-level tags too, which is more of the same: metadata, not access. There's no evaluation of who's asking, no permissions gate. The documentation says it plainly — domain assignment doesn't affect item visibility or accessibility for tenant users.
[01:12] Matthias: So it's a filing system.
[01:13] Fabia: It's a filing system where everyone can see the cabinet labels. Discovery and access are governed by workspace roles and item permissions. The domain attribute rides alongside those controls. It doesn't participate in them.
[01:28] Matthias: What I keep running into is the contributor confusion. A team hands their data stewards domain contributor, expects them to start organising workspaces into the right domains, and then nothing happens. Zero. And they can't figure out why.
[01:44] Fabia: Because domain contributor is permission to use power you already hold. The documentation's explicit — to assign a workspace to a domain, a contributor must also be a workspace admin. If your steward doesn't carry the Admin role on that workspace, the contributor title does precisely nothing.
[02:04] Matthias: And honestly, once you see the logic, it's sound design. Assigning a workspace to a domain changes its metadata, and through delegated settings, that can change how items get labelled. Fabric won't let someone do that to a workspace they don't own. But nobody reads it that way the first time they configure it.
[02:25] Fabia: We got a question from a listener. We put the sensitive workspaces in their own domain. Are they protected now?
[02:33] Matthias: No. And I'd say it's actively worse than neutral. You've told every user in the tenant which workspaces you consider sensitive, and you've protected none of them.
[02:44] Fabia: The documentation is unambiguous — domain assignment doesn't affect item visibility or accessibility. What protects those workspaces is workspace roles and item permissions. That's the boundary layer. The domain sits above it, categorises and describes. Access decisions live elsewhere.
[03:03] Matthias: And the real difficulty isn't explaining that. It's that the word 'domain' carries twenty years of Active Directory behind it. People hear it and think perimeter. In Fabric, it means a label on the filing cabinet.
[03:17] Fabia: There's a mechanism most teams configure once and then forget exists. The default domain. When you set it up for named users or a security group, Fabric does three things at once — it scans existing unassigned workspaces and pulls them in, it attaches itself to every new workspace those users create going forward, and it hands out the domain contributor role as a side effect.
[03:43] Matthias: It hands out a role?
[03:44] Fabia: Generally, yes — that's Microsoft's word, and they don't say when it doesn't. And unlike manual assignment, which can override an existing association if a tenant setting is on, the default domain won't. It's retroactive once, at setup, and then ongoing for everything created afterwards. It's the only assignment mechanism in Fabric that keeps running when nobody's watching. And if the membership of that security group changes in Entra ID, your domain topology changes with it. Without anyone opening the Fabric admin portal.
[04:19] Matthias: So your domain structure's coupled to your identity provider. And nobody's monitoring that coupling.
[04:26] Fabia: Worth checking right now. Domain settings, default domain. If there's a security group listed, that group's membership has become part of your domain topology — and it shifts every time someone joins or leaves.
[04:40] Matthias: Here's where it gets expensive, and I don't mean licensing. A workspace can only belong to one domain. Hard constraint. So when a workspace genuinely serves two business units — and every organisation has those — you're forced into a choice. Either you pick one domain and accept that the other unit's catalog experience is wrong, or you split the workspace. And splitting isn't free. You're duplicating semantic models, managing cross-workspace lineage, doubling refresh schedules. The capacity bill might not move — you might stay inside the same capacity tier — but the operational cost is real. That's hours of someone's week, every week, for a decision that started as metadata.
[05:26] Fabia: And the subdomain path doesn't rescue you. Subdomains carry general settings only — a name and a description. No admins of their own, they inherit the parent's. No contributors, no delegated settings. Your domain hierarchy can be two levels deep. Your administrative hierarchy is one. Plan the org chart against the shallower number.
[05:48] Fabia: I do want to push back on the takedown reading, though. Domains are genuinely useful when you come to them for what they actually are. In a tenant with three hundred workspaces and forty teams, that catalog filter is the difference between finding your data in two clicks and drowning in results. And the delegated sensitivity label — where a domain admin sets a default for new items across their business unit, and it's still a preview feature behind a tenant setting — that's real governance. A human decision always overrides it, automated labels go through a priority comparison, and the default catches unlabelled items the next time somebody saves them. That's one fewer gap in your information protection posture.
[06:36] Matthias: If you come expecting a boundary, you'll be frustrated. If you come expecting a discovery layer with governance hooks, it's solid. The mistake happens before anyone logs in — it's in the expectations. And usually the fix is realigning those expectations, not tearing anything out.
[06:55] Fabia: One risk for anyone running ALM — the domain-level default sensitivity label explicitly doesn't support deployment pipelines or Git integration. So the one genuinely governing behaviour a domain has doesn't follow content through your CI/CD lifecycle. What the documentation says is that it isn't supported, which is not the same as telling you what happens. So the label's behaviour is undefined while the artefact moves through stages.
[07:24] Matthias: Born in place, stays in place. Plenty of other things don't ship either — next week is eight minutes on that list.
[07:32] Matthias: The lesson transfers anywhere. A domain answers 'whose data is this'. It doesn't answer 'who may see it'. Those are different questions, they live at different layers, and every time someone collapses them, they end up with structure that looks like protection and delivers none. If you're designing governance for a Fabric tenant, start with the permissions model. The domain layer is valuable — for discoverability, for delegation — but it goes on top. Never instead.
[08:03] Fabia: There is, in somebody's tenant tonight, a domain named after something a dozen people weren't supposed to know about. And every user on the tenant can read it. Working exactly as designed.
[08:16] Matthias: If you've got a domain structure doing something you didn't plan for — or one you're proud of — DM me on LinkedIn. Find me as Matthias Falland.
[08:26] Fabia: Pattern dictates platform. See you next Friday.
---
End of episode. ~08:29 estimated.