Microsoft Fabric sets access per workspace and per item, and the portal shows it one workspace or item at a time. Fabric Control reads entitlements and presents the estate-wide view: every principal's access, at what level, and how it has changed over time. It reads who-can-access-what, never your data. The governance tier costs nothing.
An access review sounds like it should take minutes. In Fabric it takes an afternoon, because there's no one place to look. Access is granted workspace by workspace and item by item; it accumulates over time; grants get forgotten. When someone asks "who has access to this?" the honest answer is usually "let me check each workspace and get back to you."
Why is access so hard to see across a Fabric estate?
Fabric is several products under one roof, workspaces, capacities, lakehouses, warehouses, pipelines, semantic models, and access is assigned at each level independently. A workspace role here, an item-level share there, a group added to one workspace and a service principal to another. The portal shows each grant where it was made, rather than as one list of who can see what. So an access review means opening each workspace in turn, or building your own reporting on the Fabric admin APIs and then owning that forever. And because the portal shows access as it stands right now, the history of who granted what, and when, has to be pieced together from the audit log, event by event.
What a good access view shows
Listing permissions isn't the same as reviewing them. A view worth having answers three questions the native screens don't:
- Everyone's access, everywhere. Every principal, user, group, or service principal, across every workspace and item, at what level, in one list rather than one screen at a time.
- How it changed. Access drift over time: what was granted, to whom, and when, so a change is something you can see rather than something you reconstruct after the fact.
- What shouldn't be there. Orphaned access nobody owns and over-broad grants that give more than the work needs: the two findings an auditor is actually looking for.
None of that requires touching your data. It's all entitlements and operational metadata: who can reach what, not what is inside.
What Fabric admins run into, and where this helps
"Who has access to this?" takes an afternoon. Access is set per workspace and per item, so answering the question means opening each one and reading its roles by hand. Fabric Control lists every principal's access across the estate in one view, so the answer takes a moment instead of an afternoon.
Access was granted for a one-off task and never removed. A share made months ago for a single request sits there indefinitely, because nothing surfaces it again. An estate-wide entitlement view lists every grant in one place, so access that outlived its reason is visible instead of buried.
An auditor asks for an access review you can't produce quickly. Proving who can reach what, across the estate, means scrambling workspace by workspace. The entitlement data Fabric Control already collects is that review, on demand.
Permissions change and nobody is tracking it. A role added, a group's access widened, a service principal granted more than it needs, usually noticed only after it matters. Drift detection records the change to access when it happens, not a week later.
An employee leaves and their access is nobody's job to remove. Departures are handled account by account, and item-level shares are easy to miss. An estate-wide view shows everything a principal can still reach, so nothing is left behind by accident.
Getting that view
Fabric Control's governance tier provides it. You register a service principal you create and control; it reads entitlements and operational metadata, and presents the estate-wide access view alongside health, capacity, refresh, and drift. It never reads your rows or tables. The governance tier is free for one Azure tenant, for as long as you use it.
You can also build this yourself on the Fabric admin APIs, which expose workspace roles and item permissions. That is the right call if you have an engineer to own a reporting project and keep it current through Fabric's monthly changes. The governance tier is there so you don't have to.
Fabric Control is my product, so this isn't a neutral comparison. The governance tier is genuinely free for one tenant. Backup and operations are separate paid tiers; nothing on this page depends on them.
Does this give a vendor access to my data?
No. Only operational metadata crosses the boundary, including who can access what. Your rows, records, and table contents stay in your tenant. Access is through a service principal you create, scoped to least privilege, and revocable at any time; when you revoke it, the access ends. The boundary is enforced by the architecture rather than a promise, which narrows what a regulated environment has to review.
Frequently asked questions
Can I see who has access to my whole Microsoft Fabric estate in one place?
Through the admin APIs, yes. In the portal, access is shown per workspace and per item, so an audit done in the portal means checking each one. A governance layer that reads entitlements gives you that estate-wide view directly.
What should an access review for Fabric actually show?
Every principal's access across every workspace and item, at what level; how that access has changed over time, so you can see drift; and access that is orphaned or over-broad: a service principal nobody owns, a group with more than it needs. That is the difference between listing permissions and reviewing them.
How do I find access that was granted and then forgotten?
Native Fabric shows current access one workspace at a time; how it got there, and when, is recorded event by event in the audit log rather than on that screen. An estate-wide entitlement view lists every grant in one place and tracks changes over time, so a grant made months ago for a one-off task, and never removed, is visible instead of buried.
Does Fabric Control's governance tier cost anything?
No. The governance tier is free for your own Azure tenant, up to 30 workspaces, 300 items and one capacity, with one year of operational history. It reads entitlements and presents the estate-wide access view, alongside health, capacity, refresh, and drift. Backup and operations are separate paid tiers you only add if and when you want them.
Does reading entitlements give a vendor access to my data?
No. It reads who can access what, and other operational metadata, never your rows, records, or table contents. Access is through a service principal you create, scoped to least privilege, and revocable at any time. The metadata-only boundary is enforced by the architecture, which narrows what a regulated environment has to review.