Momentum One Academy · article
Fabric Administration, Capacity and Governance: The Production Operating Model
A Fabric proof of concept can run with one workspace, one capacity, and a handful of enthusiastic contributors. Production cannot. Once pipelines, lakehouses, semantic models, KQL databases, reports, and Data Agents share the same estate, the hard problem is no longer “where do I click?” It is deciding who owns each boundary, how compute is isolated, how access is proved, and how an operator finds the cause of a failure at 08:00 on a Monday.
At Momentum One, we treat Fabric administration as an operating model rather than an admin-portal tour. Microsoft describes administration as the work of governing, securing, operating, and optimizing the Fabric data estate.1 That framing is useful because it connects platform settings to production outcomes: predictable performance, recoverable workspaces, least-privilege access, and evidence that a trusted dataset is actually being used.
The Fabric boundaries that matter
There are five boundaries to make explicit in a production design.
The tenant is the broadest policy scope. Fabric administrators control which capabilities users can use, who can create workspaces, and which features may process data through connected services. Tenant settings are not a substitute for data security; they define which product behaviors are available in the first place.
A capacity is a compute and service boundary. Capacities provide the resources used by Fabric workloads and can be used for isolation and chargeback decisions.2 A capacity choice is therefore an architecture choice, not just a SKU purchase. It affects which teams compete for resources, where data is processed, who can administer the resource, and how performance is explained to stakeholders.
A workspace is a collaboration and item-management boundary. Workspace roles apply to that workspace; they do not automatically grant rights to another workspace, to the containing capacity, or to the tenant.5 A workspace is a useful place to align a team, environment, and data product, but it is not the only security layer.
An item and its compute endpoint are narrower boundaries. Reports, semantic models, warehouses, lakehouses, and KQL databases can each have their own sharing and data-access behavior. SQL permissions, semantic-model security, and OneLake security can restrict what an already-authorized user can query.5
A domain is an organizational and discovery boundary. Domains help a business group its data estate and delegate some governance responsibility without turning every department into a separate tenant.2 Use domains for ownership, discovery, and delegated governance. Use workspaces, items, and data-level controls for operational and access boundaries.
This layered view prevents a common mistake: assuming that a user who can see a report can automatically query the underlying OneLake data. Microsoft explicitly distinguishes item read permissions from underlying SQL or OneLake access.5
Capacity architecture: isolate deliberately, not emotionally
The default production question should not be “What is the largest capacity we can afford?” It should be “Which workloads must remain reliable when another workload spikes?” Start by classifying workload behavior: interactive reports, scheduled refresh, ingestion and transformation, Spark, real-time/KQL workloads, and AI-assisted experiences. Then map those behaviors to business criticality and operating hours.
A small estate may begin with one shared development capacity and one production capacity. This is simple and can make better use of available compute, but it creates a noisy-neighbor risk. A long Spark job or a burst of refreshes can compete with an executive report. In that design, the operator must accept a shared blast radius and compensate with scheduling, workload discipline, and regular capacity review.
Separating development, test, acceptance, and production improves isolation and chargeback, but costs more and can fragment utilization.2 It also increases assignment, delegated-setting, and monitoring overhead.
At Momentum One, record each capacity’s environment, regional or regulatory constraint, workload class, business owner, peak window, and escalation owner. Do not treat an F SKU as a guaranteed runtime. Measure actual usage, review the Capacity Metrics app, and resize from evidence. The app exposes consumption, compute behavior, throttling, query rejections, storage, and timepoint detail; usage data has processing latency rather than being an instantaneous meter.6
A capacity contributor can assign workspaces without being able to change capacity settings or delete the capacity. That is a useful delegation pattern when workspace owners need a controlled route into a managed capacity.3 Keep capacity administration with a small platform group, and grant assignment rights only where the operating model requires them.
Workspace design and lifecycle
Use workspaces to make ownership and deployment intent obvious. Names such as MOA-DEV-SALES, MOA-TEST-SALES, and MOA-PRD-SALES communicate more than Workspace 17. Add a description that names the business owner, technical owner, data classification, capacity, domain, and recovery contact. That metadata is operational data: it shortens incident triage and makes estate inventory more useful.
Do not use one giant workspace as an enterprise filing cabinet or a workspace per table. Propose a workspace when it needs a different owner, access boundary, lifecycle, environment, capacity, or retention decision.
Control who can create workspaces. Fabric tenant settings can allow everyone, no one, or only selected security groups to create them.4 A request-based model is usually more sustainable for production: a product team proposes purpose, owner, domain, environment, classification, capacity, and recovery expectations; a platform owner creates or approves the workspace; the team then administers its content within that boundary.
Lifecycle needs an explicit policy. Deleted collaborative workspaces are retained for seven days by default, with a configurable range of seven to 90 days. My workspaces have a fixed 30-day retention period.12 Treat that retention window as a recovery safety net, not as a substitute for source control, deployment history, or data backup. Before shortening the collaborative-workspace setting, review already-deleted workspaces: Microsoft documents that the current setting is used to recalculate remaining retention, so a reduction can make an older deleted workspace eligible for permanent deletion.12
Capacity deletion also deserves change control. Microsoft documents that deleting a Fabric capacity can soft-delete non-Power BI Fabric items in assigned workspaces; reassigning the workspace to an eligible capacity in the same region within seven days can restore those items.3 That is a narrow recovery path, not a reason to use capacity deletion as an ordinary cost-control technique.
Governance through OneLake and scoped roles
The OneLake catalog’s Govern section is the central administrative experience for governance insights, workspaces, capacities, tenant settings, domains, policies, and related controls. It is rolling out by region, so an estate may still need the Admin portal during the transition.1 Make the navigation path part of the runbook, but do not make the runbook depend on a single user interface. Platform scripts and documented APIs are valuable for repeatable inventory, access review, and lifecycle operations.
Separate responsibilities without creating an approval maze. A Fabric administrator handles tenant-wide configuration and oversight. A capacity administrator manages a particular compute boundary. A domain administrator stewards a business grouping. Workspace admins manage collaboration and item access inside a workspace. Microsoft documents these as scoped responsibilities that can be held by the same person or distributed across an organization.1
Use security groups rather than individual names for stable access. Assign Viewer, Contributor, Member, or Admin according to the job, then verify the data layer. A Viewer may open a report while lacking direct SQL or OneLake access. Document the intended access path and test it with a representative identity.
The governance question is not only “Who can access this?” It is also “Can a user find and trust it?” Use domains, descriptions, endorsements, sensitivity labels, and metadata practices to make the intended product discoverable. Governance insights can reveal inventory, labeling, curation, sharing, and activity gaps, but they are based on refreshed administrative data rather than a magical real-time view.3
Monitoring: distinguish triage from diagnosis
The Monitor hub is a first stop for job health, alerts, capacity, applications, and agents. It is documented as a preview experience, and visibility is permission-scoped.8 Use it for triage: find the failed or queued job, confirm the workspace and item, inspect history, and hand the incident to the right owner.
The Job runs page provides filters for status, item type, workspace, and time range, plus run details and history. A queued or not-started run is a reason to inspect resource availability; a failed run is a reason to open the error and activity details.9 Refresh the page deliberately. The documentation notes that the list is retrieved when the page loads and does not update continuously.9
For deeper capacity diagnosis, use the Microsoft Fabric Capacity Metrics app. Its health, compute, storage, timepoint, and item-level views help answer whether the problem is a single item, a recurring peak, a capacity-wide overload, or a storage trend.6 Do not promise stakeholders that the app is an alerting system: Microsoft notes that it does not support alerts or notifications. Use the documented capacity event paths for alerting and treat metrics latency as part of the evidence.
The admin monitoring workspace is another useful, but carefully bounded, instrument. It is installed when an administrator first accesses it, its reports refresh automatically, and its content is read-only. Microsoft also documents operational caveats: setup requires a directly assigned admin role, private links are not supported, and scheduled refresh can fail if the original admin loses the role or uses just-in-time access that is inactive at refresh time.11 Create an explicit ownership and continuity plan before relying on its reports in an executive operating rhythm.
Data Agent governance: make the data path explicit
A Data Agent is not a permission bypass. It is a conversational interface over selected Fabric data sources. Current Microsoft documentation lists a paid F2 or higher Fabric capacity, or a P1 or higher Power BI Premium capacity with Fabric enabled, plus a readable source such as a lakehouse, warehouse, semantic model, KQL database, mirrored database, or ontology.7
In production, keep the source list small and purposeful. Select only the tables needed for the questions the agent is meant to answer. Add instructions for business definitions and routing—for example, direct financial KPI questions to a certified semantic model and operational event questions to a KQL source. Use example questions to test ambiguity, but do not write instructions that conflict with tenant policy, role permissions, or read-only behavior.7
Sharing the agent and sharing its sources are separate actions. The sharing documentation states that the agent honors user permissions, including row-level and column-level security, and lists the minimum read/query permission for each supported source.10 A user who can open the agent but lacks permission on a connected source may receive an authorization error or empty result. Publish a read-only version before broad consumption; keep draft refinement isolated from what users are already using.10
Tenant settings deserve a recorded decision. Administrators must enable the relevant Copilot and Azure OpenAI controls, designate eligible capacities when required, and evaluate whether cross-region processing or storage settings are acceptable for the organization’s geography and compliance boundary.13 If a business cannot approve that data-processing posture, do not “solve” the problem by hiding the setting. Choose a different delivery pattern or defer the agent.
A simple KQL example illustrates the production discipline to teach users and encode in agent instructions. Assume a KQL table named ServiceEvents with Timestamp, Environment, Severity, and Service columns:
ServiceEvents
| where Timestamp between (startofday(ago(7d)) .. now())
| where Environment == "Production"
| summarize Events = count() by Service, Severity
| order by Events desc
The important governance behavior is not the syntax. It is the bounded time window, explicit environment filter, and aggregation before returning results. Validate the query against the actual schema and permissions in the target KQL database; never present this example as a universal Fabric system query.
Common failure modes and the operating response
A report is slow, so the team immediately resizes the capacity. First classify the issue as item-specific, workload contention, a capacity-wide peak, or a permissions-induced query path. Use Monitor hub for the run and Capacity Metrics for the pattern.
The Data Agent answers “nothing.” Check publication state, agent sharing, source permissions, table selection, and row/column security. Opening the agent does not prove that the user can query every connected source.
An orphaned workspace has no accountable owner. Review the Workspaces inventory and assign an admin before changing capacity or access. A workspace state of Orphaned means there is no admin user; it is an ownership defect, not a harmless label.4
The admin monitoring report stops refreshing. Check direct admin-role assignment, the identity that initialized the workspace, and PIM timing. Reinitialization is a recovery procedure, not a routine refresh button.
Governance data contradicts a recent change. Check refresh timing first. OneLake governance insights and Capacity Metrics have documented refresh or processing latency. Record the observation time and source view.
Momentum One production checklist
Before calling a Fabric estate production-ready, verify that:
- each workspace has a named business owner, technical owner, domain, environment, classification, capacity, and recovery contact;
- capacity boundaries have a written rationale, measured peak behavior, cost owner, and escalation path;
- workspace creation and capacity assignment are restricted to the intended groups;
- access is tested at workspace, item, compute, and OneLake/data levels;
- retention settings are documented and deletion changes receive review;
- Monitor hub triage, Capacity Metrics diagnosis, governance review, and audit escalation have named operators;
- the admin monitoring workspace has continuity coverage for role and refresh failures;
- every Data Agent has an approved purpose, source inventory, permission test, publication owner, and processing-region decision;
- failed pipeline, queued workload, revoked user, deleted workspace, and capacity-overload scenarios have been rehearsed.
Workshop connection
In Module 10 — Administration & Governance, use this checklist as the acceptance criteria for a small production simulation. Create separate development and production workspaces, map them to deliberate capacity boundaries, delegate only the rights the team needs, and document the reason for every exception. Then trigger a controlled pipeline failure, investigate it through Monitor hub, confirm the capacity view in Capacity Metrics, and reconcile the result with the workspace and governance inventory. Finish by publishing a narrowly scoped Data Agent over a governed model and testing both an allowed question and a denied data path.
That sequence turns administration from a collection of settings into an operating habit: define boundaries, measure behavior, grant least privilege, recover deliberately, and explain every production decision.
Ready to turn the operating model into a working Fabric estate? Continue with the Momentum One Academy Fabric Production Workshop.
References
Plan your workshop