Microsoft Fabric Architecture Podcast

Fabric domains look like governance boundaries but the documentation says otherwise. We unpack what a domain actually gives you, the default-domain mechanism that's still running in your tenant, and why the label on the cabinet is not the lock.

Show Notes

Your Domain Isn't a Wall

Episode 38 • 2026-10-09 Duration: 8:43

Fabric domains look like governance boundaries but the documentation says otherwise. We unpack what a domain actually gives you, the default-domain mechanism that's still running in your tenant, and why the label on the cabinet is not the lock.

What we discuss

  • How it actually works underneath the abstraction
  • The pattern we keep seeing in the field
  • A real Reddit/Microsoft Q&A question unpacked
  • Where the obvious answer breaks
  • F-SKU realism — what this actually costs
  • When the rejected approach is actually right
  • Risks of the recommended path
  • The architectural principle to take home

Key takeaways

  • There's a filing cabinet in every office with a label on the front.
  • Pattern dictates platform. If the pattern is "organize and find," a domain is the right tool. If the pattern is "restrict and protect," you're in the wrong layer.
  • So here's where I'd land. A domain answers "whose data is this." Use it for discovery and delegation. Build your actual boundaries with workspace roles and item permissions. And audit that default domain list quarterly, because it's still running.

Watch the episode

The Fabric Friday video on this topic: https://youtu.be/8wRSvnF_CtQ

From the video

  • 7:46 Demo: The Contributor Who Cannot Contribute
  • 3:15 Demo: The Filter That Is Not a Fence
  • 12:51 Demo: An Assignment Nobody Made
  • 14:42 The Sensitivity Label Override Ladder

Resources

About the show

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.

Submit your case

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.

What is Microsoft Fabric Architecture Podcast?

Architecture decisions for Microsoft Fabric. Anonymized real customer scenarios, cost realism, counter-arguments included. Weekly episodes aligned with Fabric Friday recordings.

Your Domain Isn't a Wall
Episode 38 | 2026-10-09
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia

---

[00:08] Fabia: "Domain assignment doesn't affect item visibility or accessibility for tenant users." That's Microsoft Learn. One sentence.

[00:16] Matthias: And yet I keep running into tenants where someone built domains as the security boundary.

[00:22] Fabia: Because the word "domain" implies one.

[00:24] Matthias: So what IS it actually doing?

[00:26] Fabia: That's what we're unpacking. What a domain gives you, what it quietly takes, and the one mechanism that's still running in your tenant right now.

[00:36] Matthias: After everyone walked away from the admin portal.

[00:39] Fabia: When you assign a workspace to a domain, every item in that workspace gets a domain attribute in its metadata. That attribute powers the domain filter in the OneLake catalog.

[00:51] Matthias: And tenant settings can be delegated to the domain level. Certification, for example — the domain admin enables it, names the certifiers.

[01:00] Fabia: All three are worth having. The catalog filter alone changes how a large tenant feels to navigate.

[01:07] Matthias: So far that sounds... genuinely useful.

[01:09] Fabia: It is. But the same documentation says: all users within a tenant can see all the domains, regardless of their role.

[01:17] Matthias: The names are public?

[01:18] Fabia: To everyone. Someone with no role in a domain called Finance still sees it in the catalog's domain filter.

[01:25] Matthias: So naming a domain after a confidential acquisition announces the acquisition.

[01:31] Fabia: And one hard constraint. A workspace can only belong to one domain. If it serves two business units, you choose one or you split the workspace.

[01:40] Matthias: And splitting a workspace creates its own problems.

[01:43] Fabia: Three roles, and the middle one is weaker than the title. A domain admin assigns workspaces, defines contributors, overrides delegated settings. But they can't rename or delete the domain, and they can't touch the admin list. Only a Fabric admin can.

[02:00] Matthias: And the contributor?

[02:01] Fabia: This is the one that catches teams. To assign a workspace to a domain, a contributor must already be a workspace admin.

[02:09] Matthias: So it's permission to use power you already—

[02:12] Fabia: —hold. Give someone contributor with no workspace admin role, and they can do exactly nothing.

[02:19] Matthias: I've seen that ticket. Stewards get domain contributor, nothing changes, and... the confusion lands about a week later.

[02:27] Fabia: The design is right, though. Assigning a workspace changes its metadata and can change how items get labeled. Fabric won't let someone do that to a workspace they don't administer.

[02:39] Matthias: In the video, the demo identity got contributor on demo-operations. Couldn't even find the Domains tab.

[02:45] Fabia: Contributors don't get one. The domain field only appeared after the identity became workspace admin.

[02:52] Matthias: What about subdomains? Can you push the admin structure deeper?

[02:56] Fabia: General settings only — a name and a description. No admins of their own; they inherit the parent's. Hierarchy can be two levels deep. Administration is one level deep.

[03:08] Matthias: Plan against the shallower number.

[03:10] Fabia: "We put the sensitive workspaces in their own domain. Are they protected now?"

[03:15] Matthias: That question keeps coming up because the interface makes it feel like the answer should be yes.

[03:22] Fabia: The answer is no. A domain attaches an attribute. Attributes describe. Permissions decide. Nothing in the assignment path evaluates who's asking.

[03:32] Matthias: And every user can see the domain name. So you've labeled where the sensitive stuff lives and protected nothing.

[03:39] Fabia: Workspace roles and item permissions are the boundary. That's the layer below.

[03:44] Matthias: The video demo made this concrete. Same identity, two lakehouses, different domains. One opened because the identity had a workspace role. One didn't. The domain decided neither outcome.

[03:57] Fabia: The domain filtered what appeared in the catalog. The workspace role decided what opened.

[04:03] Matthias: So the honest answer is: you organized them. That's it.

[04:06] Fabia: There's an assignment mechanism that teams configure once and then forget. The default domain.

[04:13] Matthias: How's it different from the normal assignment?

[04:16] Fabia: You name users or security groups. Fabric scans existing workspaces. If the workspace admin is on your list and the workspace has no domain, it's assigned. If it already has one, it's preserved — the default never overrides.

[04:31] Matthias: So far that's careful.

[04:32] Fabia: It is. But after that scan, whenever someone on the list creates a workspace, it lands in the default domain. Next month. Next year. Nobody has to be watching.

[04:43] Matthias: It's a standing rule.

[04:44] Fabia: With a side effect. Those users generally become domain contributors of the workspaces assigned this way. You configured a convenience and handed out a role.

[04:55] Matthias: And if a security group is on that list, its membership is now part of your domain topology. Someone joins the group, their next workspace lands in the default domain — nobody touched Fabric for it to happen.

[05:08] Fabia: In the video, the demo identity created a workspace with no domain selected. Closed the settings, reopened them. It read demo-sales. Nobody picked it.

[05:18] Matthias: The only assignment that keeps working after you stop looking. That's powerful if you meant it.

[05:25] Matthias: What about the sensitivity label delegation? That's the one place a domain actually governs.

[05:31] Fabia: A domain admin sets a default sensitivity label, a setting that's still in preview and has to be switched on first. Fabric applies it in two moments: when a new item's created and saved, and when an unlabeled existing item's updated and saved.

[05:47] Matthias: What if the item already has a label?

[05:50] Fabia: A label someone applied by hand is never overridden. Any priority. Everything else is a comparison against the label order in Purview.

[05:59] Matthias: A human decision always wins. That's clean.

[06:02] Fabia: Deployment pipelines and Git integration currently aren't supported. The one governing behavior a domain has doesn't follow content through CI/CD. The cost is entirely in the gap between what teams assume they built and what they actually have.

[06:18] Matthias: Build here, promote there, the label stays behind. In a team of eight under cost pressure, who notices?

[06:25] Matthias: I want to push back, though. We've spent the episode saying what domains aren't. When ARE they the right call?

[06:32] Fabia: A tenant with hundreds of workspaces where nobody can find anything. Domain structure with consistent naming gives you a catalog people actually use. Business units that need their own certification policies — delegated settings handle that without a Fabric admin in every meeting.

[06:51] Matthias: So the condition is... you've already built your actual security with workspace roles and item permissions. Domains go on top of that. They're the organization layer. Skip the layer below and you've got a false floor.

[07:06] Fabia: And if the existence of your business units isn't confidential, domain names are free organization. Name them like they're on a billboard and you're fine.

[07:16] Matthias: The risk I'd lose sleep over isn't a misconfigured default domain — you can fix that in an afternoon. It's the naming one. A domain name that leaked the existence of an acquisition to the wrong person, that's a disclosure problem, and it's not a Fabric fix.

[07:33] Fabia: And you can't walk it back. The name was visible the moment you saved it.

[07:38] Matthias: The other one to flag is the default domain handing out contributor roles quietly. Your role inventory isn't what you think it is, especially if a security group is the trigger.

[07:50] Fabia: Because the membership changes outside Fabric entirely.

[07:53] Matthias: So here's where I'd land. A domain answers "whose data is this." Use it for discovery and delegation. Build your actual boundaries with workspace roles and item permissions. And audit that default domain list quarterly, because it's still running.

[08:10] Fabia: Pattern dictates platform. If the pattern is "organize and find," a domain is the right tool. If the pattern is "restrict and protect," you're in the wrong layer.

[08:21] Matthias: There's a filing cabinet in every office with a label on the front. Everyone in the building can read it. Nobody confuses the label with the lock.

[08:31] Fabia: Except in Fabric, apparently.

[08:33] Matthias: If this changed how you think about your tenant, find me on LinkedIn — Matthias Falland.

[08:39] Fabia: See you next week.

---

End of episode. ~08:40 estimated.