Most Fabric governance designs open with domains, at least on paper. It is the obvious place to start: domains are the headline governance feature, they map onto a data mesh diagram everyone has already seen, and creating one takes a minute in the admin portal.
The trouble is what people believe a domain does once it exists. Microsoft’s own documentation is explicit on the point: domain assignment does not affect item visibility or accessibility for tenant users. Every user in the tenant can see every domain. A Finance domain does not keep anyone out of finance data. Workspace roles and item permissions do that, exactly as they did before the domain was created.
So Fabric governance built around domains, without understanding that sentence, produces a tidy catalogue and no additional control at all. This article is about where the controls actually sit.
Four areas, and only some are included
Microsoft groups Fabric governance into four capability areas. The table is worth reading for its footnote as much as its contents.
| Manage the estate | Secure, protect, comply | Discovery and trust | Monitor |
| Admin portal | Privacy and data security | OneLake catalog | Monitoring hub |
| Tenant, domain and workspace settings | Purview Information Protection | Endorsement | Capacity metrics |
| Domains | Purview Data Loss Prevention | Tags | Admin monitoring |
| Workspaces and capacities | Item and data-level security | Lineage and impact analysis | |
| Metadata scanning | Auditing | Purview across the organisation |
Three of those, Purview Information Protection, Purview Data Loss Prevention and Purview governance across the organisation, require additional licensing. Many governance plans are written as though everything in the table comes with the Fabric capacity. It does not, and discovering that at the point of implementation is how a governance workstream loses its budget.
What a domain actually does
Strip away the diagrams and a domain does three things.
It labels. Workspaces are associated with a domain, and every item in them inherits a domain attribute. In the OneLake catalog, users can then filter to a domain to find relevant content. Microsoft says plainly that this association currently primarily enables a better consumption experience.
It delegates. Some tenant settings can be overridden at domain level. There are two: a domain-level default sensitivity label, and certification settings, meaning whether items in the domain can be certified, who the certifiers are, and where the certification documentation lives.
It assigns ownership of the grouping. Domain admins, ideally the business owners of the data, can describe the domain, add contributors and assign workspaces. They cannot delete the domain, rename it or appoint other domain admins.
What it does not do is enforce anything about who can open what. That is the workspace.
The workspace is the wall
Access in Fabric is decided by workspace roles, item permissions, and for some item types by data-level controls on tables, rows and columns. Microsoft currently provides those data-level controls for SQL analytics endpoints, warehouses, Direct Lake and KQL databases.
That changes where governance effort should go. The expensive mistakes in a Fabric estate are workspace mistakes: a workspace created for one team that quietly becomes shared, a workspace admin role handed out to make a deadline, a development workspace that ends up holding production data. None of those is visible at domain level, and none of them is fixed by reorganising domains.
In the estates we assess, though, the tidy-catalogue problem is the rarer one. A well-drawn domain structure is not a common sight. Most organisations start without one and still have none, and the reason is the sentence at the top of this article: because no part of a domain decides who can see data, domains read as optional, and optional loses to urgent every time.
That is the real starting position for most Fabric governance work. Not a map drawn in the wrong shape, but no map at all, and therefore no agreed answer to who owns which data before anyone argues about certifying it.
The assignment mechanics that catch people out
Domains have a set of assignment behaviours that are individually reasonable and collectively surprising.
| Mechanism | What it does | What it does not do |
| Assign by workspace admin | Assigns every existing workspace those admins own | Touch workspaces they create afterwards |
| Assign by capacity | Assigns every existing workspace on those capacities | Touch workspaces added to the capacity later |
| Default domain | Assigns unassigned workspaces of named users, and all new ones they create | Override a workspace already in another domain |
| Overriding an existing assignment | Possible for Fabric and domain admins | Works only if a preview tenant setting is enabled |
Two of those four are one-off operations dressed as rules. Assigning by capacity feels like a policy, and it is a snapshot. Six months later, workspaces created on that capacity sit outside the domain and nobody notices, because nothing warns you.
The default domain is the only mechanism that keeps working over time, and it is keyed to people rather than capacities. That is worth designing around deliberately.
Subdomains have their own quirks. They have no admins of their own, inheriting the parent domain’s, and they currently expose general settings only. So a subdomain can narrow the grouping, but it cannot carry a different certification policy or default label. If two parts of a business genuinely need different certifiers, they need to be separate domains.
Endorsement is the control that changes behaviour
If domains are the part of Fabric governance everyone starts with, endorsement is the part that actually changes what people use. There are three badges, and they are not equivalent.
| Badge | Who can apply it | What it signals |
| Promoted | Anyone with write permission on the item | The creator thinks it is ready to share |
| Certified | Only reviewers a Fabric admin has authorised | It meets the organisation’s quality standard |
| Master data | Only authorised users, and only on items containing data | The single authoritative source for that data |
Read the left column carefully. Promoted means only that someone with write access wanted it promoted. It carries no review. In an estate where every analyst can promote their own semantic model, the Promoted badge becomes background noise within weeks.
Certified is different, because it has a gate. And that gate is off by default: certification and master data are only available once a Fabric administrator enables them.
Why certification stalls, and how domains fix it
Microsoft’s guidance is specific: delegate certification enablement to domain admins, let them authorise the data owners and producers who certify their own tested items, and educate consumers to use only certified items in reports and downstream processing.
That sequence is where domains earn their keep. Not as a security boundary, but as the unit that decides who is qualified to vouch for data. Finance certifiers certify finance data. Operations certifiers certify operations data.
In practice we would draw that line more tightly than “let each domain certify its own”. Anything intended to be used across the organisation should be certified by the central IT team that owns the data, together with the functional owner for that area. Requests from individual teams tend to be either too broad or too specific to stand as an enterprise answer, and an enterprise reporting solution has to be the version a lot of people accept rather than the one somebody asked for. So certification is jointly held: IT for the standards and the data, the function for whether the numbers mean what the business thinks they mean.
Two routes lead to a certified item, and they cost very different amounts.
Artefacts IT builds itself. These already run through the delivery lifecycle, which includes functional approval from the business before release. Anything published that way is certifiable as a matter of course, because the approval certification asks for has already happened.
Artefacts a user asks to have certified. Here the work happens after the fact. IT has to validate the artefact against the standards, check its performance, and QA its numbers against already certified data. Then the functional owner has to approve it. That is real load on a team that did not plan for it, and it is where the pressure in a certification programme actually lands.
How long it takes is a business question rather than a technical one. In our engagements it runs from a couple of weeks to several weeks, depending on business priorities and how quickly functional approval comes back.
Departmental self-service is not excluded by any of this. A team can build and share artefacts inside its own department, with the usual caution about what those numbers represent. What it cannot do is present them as a global answer. Certification at that level goes through the IT path.
What a production estate should look like
The target we would set for a production environment is around 90% of artefacts certified, with no more than 10% sitting at Promoted. Promoted is a legitimate status for something still in flight, but it should be read as a caution rather than an endorsement, and anything sitting there should already be moving through certification rather than resting.
Our position: draw the domains first, then name certifiers by role
Our position is that the domain structure comes first, and identifying certifiers comes immediately after it.
Drawing the structure first is cheap and it gives the organisation something concrete to argue about. Every domain then has to answer one question, which is who signs off the data in it, and that question is the whole of certification.
Then name the certifier as a role rather than a person. Fabric pushes you that way whether you like it or not: the certification setting accepts security groups only and will not take named users. Treat that as the design rather than a limitation. A role survives the person leaving, and the same certifier can cover several domains where the same team owns the data.
That last point is worth protecting deliberately. Domains and certifiers do not have to move together. If two areas later need to separate, you change the membership of one security group rather than redrawing the domain structure, and a design that assumes one certifier per domain is the design that forces a reorganisation later.
The subdomain limitation above still applies. If part of the business needs its own certification policy, it needs its own domain rather than a subdomain.
The rest of the model, briefly
A few other pieces of Microsoft’s guidance matter for the design, even if they are less discussed.
Capacities are isolation boundaries. Split them by development, test, acceptance and production for workload isolation and chargeback. If capacity sizing is the live question, Fabric capacity planning and chargeback covers the readings that decide it.
Workspaces per developer. For development, Microsoft recommends isolated workspaces for each developer so work does not interfere with the shared workspace.
Metadata scanning exposes item names, sensitivity, endorsement status and more through admin scanner APIs, so an external catalogue can report on the estate.
The admin monitoring workspace gives administrators audit and usage views across the tenant. It is the place to check whether governance decisions are holding.
Naming conventions matter for lineage. Microsoft’s guidance on lineage is simply to use consistent names. It sounds trivial and is the thing that makes impact analysis readable.
Where this connects
Two related pieces are worth reading alongside this.
Governance design depends on answers that come earlier. A data platform assessment that starts with ownership is where the question of who is accountable for which data gets answered, and certification is the operational form of that answer.
And sensitivity labels and DLP in Fabric are Purview capabilities with their own licensing and design decisions. Purview as a governance platform covers that wider control set.
Where to start
Start with the structure, because most estates do not have one. Microsoft’s own planning guidance names who should be in that exercise: the centre of excellence, business and technical architects, leads and owners, and security and compliance. The questions to settle are who is responsible for the data, what structure fits the organisation, and whether a second level is needed.
Then name the certifiers, as security groups rather than individuals, accepting that one group may cover several domains.
Separately, review the workspace estate, because that is where access is actually decided. Who holds the Admin role on each workspace, which workspaces are shared beyond their original team, and which development workspaces hold production data. No domain design will tell you any of this.
Then write down the certification process itself and put its URL in the certification setting. Leave that blank and anyone who wants an item certified is told only to contact their Fabric administrator, which is how a certification programme stays a mystery to everyone outside the team running it.
Veratas designs and builds Microsoft Fabric estates, including the governance model that decides whether a catalogue is trusted or merely tidy.
If you have domains configured and nobody using certified data, talk to our team. The fix is usually smaller than a redesign.
Frequently asked questions
Do Fabric domains control who can access data? No. Microsoft states that domain assignment does not affect item visibility or accessibility for tenant users, and every user can see every domain. Access is decided by workspace roles, item permissions and, for some item types, data-level controls on tables, rows and columns.
What is Fabric governance built on? Microsoft groups it into four areas: managing the data estate, securing and protecting it, encouraging discovery and trust, and monitoring. Domains, workspaces and capacities sit in the first, endorsement and the OneLake catalog in the third. Purview Information Protection, Purview DLP and Purview governance across the organisation need additional licensing.
What is the difference between Promoted and Certified in Fabric? Anyone with write permission on an item can promote it, so Promoted carries no review. Only reviewers authorised by a Fabric administrator can certify an item, and certification must be enabled first. Master data is a third badge, limited to items that contain data and to authorised users.
Should certification be managed centrally? Partly. Microsoft allows certification enablement to be delegated to domain admins, so each domain can have its own reviewers. For anything used across the organisation we would keep certification with the central IT team that owns the data, working with the functional owner for that area, because an enterprise solution has to be a broadly accepted answer rather than one team’s. Departmental self-service can still be built and shared inside a department, but it cannot be certified as a global answer without going through that path.
How long does Fabric certification take? It is a business question more than a technical one. Where IT builds the artefact through its own delivery lifecycle, functional approval is already part of release, so certification follows it. Where a user asks for an existing artefact to be certified, IT has to validate it against the standards, check performance, QA its numbers against certified data, and then obtain functional approval. In our engagements that runs from a couple of weeks to several weeks, depending on business priorities.
What proportion of items should be certified? In a production environment we would aim for around 90% of artefacts certified and no more than 10% at Promoted. Promoted should be treated as a caution rather than an endorsement, and anything holding that status should already be moving through certification.
Can we name individual certifiers in Fabric? No. The certification setting accepts security groups only and will not take named users, so a certifier is always a role. That is useful rather than restrictive: the same group can cover several domains, and membership can change without redrawing the domain structure.
Why do new workspaces not appear in my domain? Assigning workspaces by admin or by capacity only affects workspaces that exist at the time. Workspaces created later are not added. The default domain mechanism does assign new workspaces, but it is keyed to specific users and groups rather than to capacities.
Can a subdomain have its own certifiers? No. Subdomains have no admins of their own, inherit the parent domain’s admins, and currently expose general settings only. If part of the business needs its own certification policy, it needs its own domain.
Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.