Fabric Governance and Workspace Design for Multi-Site Estates

Verified as of 1 August 2026. Fabric SKUs, domain behaviour, sensitivity labels and endorsement all move quickly. Treat the specifics below as current thinking and recheck the vendor documentation each quarter.

Most Fabric problems I get called into are not modelling problems. They are topology problems. Someone spun up workspaces per report, per person, or per whim, and now nobody can say which dataset is the real one. This guide gives a concrete workspace layout for an operator with several sites and one central function, the roles that own each layer, the governance mechanics that actually matter, and a 90-day plan for the common case where the sprawl already happened.

The workspace topology I actually deploy

Picture a maintenance and facilities operator running four or five sites, with a central finance and asset function sitting above them. The instinct is to give every site its own workspace and let them get on with it. That instinct is wrong. It scatters shared logic and guarantees that the day someone asks "how much did reactive work cost across the estate?" nobody can answer without a reconciliation meeting.

The layout that holds up is domain-aligned, not site-aligned. You group workspaces by business domain, give each domain a dev, test and prod triple, carve out one shared workspace that owns the conformed dimensions everyone joins to, and keep a sandbox that is explicitly disposable. Sites become a column in the dimension tables, not separate workspaces.

Why domain and not site? Because a report almost always spans sites and almost never spans domains. A finance leader wants asset spend across the whole estate, not one building at a time. A maintenance manager wants PM compliance for every site in one view. When you align to domain, those cross-site questions are a filter on a dimension. When you align to site, they are a manual union of five workspaces that nobody keeps in sync. The domain cut also matches how accountability actually runs in the organisation, which is what makes the RACI in the next section fall out cleanly.

Reading the diagram:

• One capacity, admin-owned, hosts everything. You buy compute once, not per team.
• Each business domain gets three workspaces: dev, test, prod. Nobody edits prod by hand.
• A single shared workspace owns the conformed dimensions (site, asset, date, vendor, account). Every domain model joins to those, so a site means the same thing in maintenance as it does in finance.
• The sandbox is a labelled write-off. Analysts prototype there and know it will be wiped. Nothing certified ever lives in it.

Who owns what: the RACI

Fabric ships five levels of control: capacity admin, domain admin, workspace admin, member, and viewer. Left as abstractions they mean nothing, and everyone quietly assumes someone else is watching prod. Map them to real job titles in a maintenance and finance organisation and the accountability becomes obvious. Here is the mapping I use.

R = Responsible, A = Accountable, C = Consulted, I = Informed.

Two things fall out of this table. First, the domain admin is a business role, not an IT role. The CMMS manager owns the maintenance domain because they own the meaning of a work order, not because they write DAX. Second, the capacity admin never touches a report. Their job is the SKU, the capacity headroom, and who gets a domain, and nothing else. If your platform lead is publishing dashboards, the model has already broken. Role design like this is the same discipline as system access control, which I cover in RBAC design for CAFM systems.

The governance mechanics that matter

Four mechanics do most of the work. Skip them and the topology above degrades back into sprawl within two quarters, because a good diagram with no enforcement is just a wish. Each of these turns an intention into something the platform enforces on your behalf.

1. Deployment pipelines

This is what makes the dev, test, prod triple real rather than three folders named hopefully. A Fabric deployment pipeline binds the three workspaces so content promotes in one direction, with rules that swap connection strings and parameters between stages. Nobody edits prod. They edit dev, promote to test, validate, then promote to prod. The moment you allow a hand-edit in prod, you have lost the audit trail and the rollback. Set deployment rules so that prod always points at prod data sources automatically, otherwise the first promotion will quietly point a live report at a dev lakehouse and you will spend an afternoon working out why the numbers halved.

2. Sensitivity labels and endorsement

Sensitivity labels carry classification and protection from the source through every downstream report, so a "Finance Confidential" dataset keeps that label even when an analyst exports it. Endorsement is the trust signal layered on top: an item is either promoted, certified, or nothing. Wire labels to your Microsoft Purview policy and treat endorsement as an editorial decision, not a self-service button.

3. Item certification

Certification is the single most valuable governance signal you have, and the most abused. A certified dataset means the domain admin has vouched for it. Restrict who can certify to the domain admin role in the RACI above. If members can self-certify, the badge means nothing within a month. In practice I let anyone mark an item "promoted" and reserve "certified" for the domain admin after a short review. The Microsoft Fabric governance and compliance overview is the canonical reference for how labels, endorsement and the admin surfaces fit together.

4. A naming standard that survives the third site

Names are governance you can see at a glance. The test of a naming standard is not whether it looks tidy on day one, it is whether it still parses when a third site joins and a fourth domain appears. Encode domain, stage, and item type, and leave site out of the workspace name entirely because site lives in the data.

Notice there is no site in any workspace name. When site five arrives it changes zero workspace names and adds zero workspaces. That is the whole point.

Self-service and governance are not opposites

The tired framing says you either lock Fabric down or you let a thousand analysts bloom, and you must pick. That framing is wrong, and it leads teams to the wrong fix. The failure mode of a sprawling estate is almost never too many analysts. It is that nobody owns the shared dimensions. Twelve analysts each building their own site table is not a self-service problem, it is a missing owner problem. Give the conformed workspace a named owner and most of the chaos evaporates while the analysts keep their freedom.

Three artefacts fix the ownership gap. They are cheap to maintain and they are the difference between governed self-service and anarchy.

The capacity review is the one people skip and the one that matters most. Name the attendees in the invite so accountability has a face. The platform lead brings capacity metrics, the domain admins bring proposed certifications and retirements, the lead analyst brings what is being built next. Without it, capacity throttling shows up as a surprise outage instead of a planned upgrade.

A 90-day rollout for an estate that already sprawled

Most teams reading this did not start clean. They have thirty workspaces, four datasets that all claim to be the real one, and a capacity that throttles every month-end. You cannot fix that in a weekend, and a big-bang migration will fail. Here is the 90-day sequence I run.

Days 1 to 30: inventory and freeze

• List every workspace, dataset and report, and tag each with a domain and an owner. Anything with no owner is a candidate for deletion.
• Announce a freeze on new workspaces. New work goes into the sandbox until the target domains exist.
• Stand up the domain structure and the shared conformed workspace. Nothing moves yet, the containers just exist.
• Pick the one dataset that will become the certified conformed model and assign it a named owner.

Days 31 to 60: consolidate the dimensions

• Build the conformed dimensions once in the shared workspace and certify them.
• Migrate one domain, ideally maintenance, onto the dev, test, prod triple with a deployment pipeline.
• Repoint that domain's reports at the shared dimensions and retire the duplicate site and asset tables.
• Publish the first version of the certified dataset register and the change log.

Days 61 to 90: extend and lock in

• Migrate the finance domain the same way. By now the pattern is boring, which is the goal.
• Apply sensitivity labels across certified items and turn on endorsement rules.
• Delete the orphaned workspaces from the day-one inventory. Wipe the sandbox.
• Run the first monthly capacity review with the named attendees and set the recurring invite.

At day 90 you will not be finished, but you will be governed. The topology exists, two domains are on pipelines, the dimensions are certified and owned, and the three artefacts are live. Everything after that is repetition, and repetition is exactly what you want. The temptation at this point is to declare victory and stop running the capacity review. Resist it. The review is the heartbeat that stops the estate drifting back to where it started, and the month you skip it is the month a new orphan workspace appears. Governance is not a project you finish, it is a cadence you keep. If you are earlier in the journey and still deciding what to stand up first, my Microsoft Fabric adoption roadmap covers the phase before this one.

A note on independence

I am not affiliated with Microsoft and receive nothing for recommending Fabric or any SKU. The links here point to canonical vendor documentation so you can verify the specifics yourself, because they change often. Everything else is my own practice from delivering this on real estates, and you should pressure-test it against your own constraints before committing budget.