A request for more Microsoft Fabric capacity often arrives with a familiar explanation: usage is growing, performance is slipping, and the platform team needs more room. Approving the request may be entirely reasonable. But a business leader should also be able to ask what is consuming the capacity, which services depend on it, and whether the proposed spending addresses growth or avoidable inefficiency.
Fabric Unified Admin Monitoring, or FUAM, helps assemble the evidence for that conversation. Its latest published updates make it more useful to leaders who need to connect platform operations with spending, ownership, and business priorities.
As of October 17, 2026, the newest dated entry in the FUAM changelog is release 2026.6.1, published June 2. The developments below support a more informed discussion about how the organization runs Fabric.
What FUAM gives the business
FUAM is an open-source solution accelerator in Microsoft’s Fabric Toolbox. It runs within Fabric, collecting administrative information, activity logs, inventory, and capacity metrics into lakehouse storage and presenting them through reports. Its architecture also lets teams extend the analysis with their own information. The project is maintained as an accelerator, rather than an officially supported Microsoft service. FUAM technical documentation
That combination matters because a platform’s operational records rarely contain the complete business explanation. A workspace name might tell an administrator where a workload lives. It may tell a finance leader very little about the service it supports, the person accountable for it, or the consequences of interrupting it.
My recommendation is to treat FUAM’s collected information as the operational foundation for a management view. Add a maintained mapping between workspaces, business services, owners, and cost centers. Then a capacity discussion can refer to the customer reporting service or the financial close process, with someone responsible for explaining the demand.
The native Capacity Metrics app remains an important operational tool. It provides detailed capacity analysis, including a 14-day compute view. FUAM complements that work by bringing multiple administrative sources into a reusable analytical foundation. A leader does not need to choose one dashboard for every question; the useful outcome is a consistent explanation across operational and business reviews.
The latest changes and why they matter
The recent release history has a clear progression: stronger collection, more organizational context, and deeper investigation of expensive workloads. The following changes are documented in the project’s release notes.
| Published update | What changed | Management use |
|---|---|---|
| June 2, 2026 | Beta semantic-model optimization module | Prioritize engineering investigations before a capacity decision |
| May 15, 2026 | Tag and workspace-tag extraction; packaged reporting still pending | Build analysis around agreed business classifications |
| May 15, 2026 | Domain extraction and tag-data fixes | Improve the dependability of organizational inventory |
| February 4, 2026 | Capacity Metrics v53 support, capacity-ID consistency repair, and historical audit-log storage fix | Maintain confidence in the monitoring evidence |
The last row will attract fewer headlines than the optimization module. It still deserves attention. If management is going to use monitoring information to justify investment or challenge spending, the organization needs confidence that records join correctly and collection continues to work. Maintenance of the measurement system belongs in the operating budget.
A better starting point for optimization
A semantic model supplies the relationships, calculations, and business definitions behind analytical reporting. When one consumes substantial resources, the responsible team needs enough detail to investigate its design.
The new module selects a configurable number of top-consuming items per capacity using the previous day’s capacity-unit (CU) consumption and gathers semantic-model diagnostics. It collects Best Practice Analyzer findings and table-level VertiPaq memory information, retaining results for comparison over time. It is a beta capability, disabled by default, and currently covers semantic models. Optimization module documentation
For a business audience, the significance is the improved starting point for engineering work. A list of high-consuming assets establishes where to look. Design and memory evidence gives the team something more concrete to investigate and a basis for explaining its proposed changes.
I would use this to build a short, owned improvement backlog. Each entry should identify the service involved, the suspected cause, the work proposed, and the evidence required to show improvement. Some investigations will justify a change. Others will establish that a busy model is doing valuable work efficiently and deserves additional capacity.
Consider an illustrative situation in which a sales model is among the largest consumers. The business owner confirms that it supports daily account planning. Engineers find an opportunity to simplify the model, implement the change, and compare representative periods before and after. The decision should consider consumption alongside data freshness, response time, and whether users still receive the information they need.
A high position on a consumption ranking is a reason to investigate. It is insufficient evidence to reduce a service. That distinction keeps an optimization program from penalizing successful adoption.
Tags can connect technical activity with business responsibility
The new tag data creates an opportunity for custom analysis while packaged reporting catches up. May release details
The practical opportunity is to make classification useful in decisions. An organization could agree labels for production services, experiments, or business initiatives and use them in a custom management report. Those are proposed uses of the collected data; their value depends on consistent application and maintenance.
I would start with a small number of classifications that answer an actual management question. For example, a leader reviewing the cost of experimentation needs a reliable way to identify experimental work and the person responsible for its next decision. A growing vocabulary of labels without ownership will create more reconciliation work.
Domains provide another useful organizational view. FUAM’s Core Report includes domain assignment information as well as usage, access, and sharing measures. That gives teams a place to begin identifying gaps between the organizational structure they intended and the environment they are operating. Core Report documentation
An unassigned workspace does not automatically represent waste or a policy violation. It is a reason to confirm the workspace’s organizational classification and owner. Establishing that context is a sensible first step before allocating costs, retiring assets, or changing access.
Governance becomes easier to act on
The governance improvements build on release 2026.1.1, published December 23, 2025, which added access and unused-workspace analysis. Release history
The current reports expose organization-wide sharing and reports published to the web, alongside activity and usage measures. Public-web publication allows anonymous access; organization-wide links have a different audience and should be reviewed accordingly. Core Report measures
For leaders, this supports a more specific review process. Ask the owner whether the audience is appropriate, record the decision, and assign any correction. Similarly, low activity should prompt a conversation about continued need. A quarterly process may be quiet for most of the quarter and still be essential.
I would measure completed decisions: ownership confirmed, inappropriate access corrected, or an unused service retired after checking dependencies. A growing inventory of findings is useful only if the organization can resolve them. The business owner supplies purpose; the platform and governance teams supply the evidence and the ability to act.
How this translates into financial value
FUAM helps explain resource consumption. Fabric Cost Analysis, or FCA, is the related accelerator focused on financial information, drawing on Azure Cost Management and optional reservation details. Used together, the two can support a discussion that connects workload behavior with the cost of running the platform. FCA documentation
My advice is to distinguish three outcomes in that discussion.
Lower spending means an actual reduction in the organization’s bill or committed expenditure. Finance should confirm the change against billing evidence, including relevant commitments and other costs.
More room for growth means the platform can accommodate additional useful work within its existing resources. That can defer a future purchase, but it should be recorded as avoided or deferred expenditure when there is a credible expansion plan to compare against.
Better service means users receive more reliable or timely results. The bill may remain unchanged while the organization gains a more dependable business process. That outcome deserves its own measure, such as meeting an agreed reporting deadline.
These are different benefits and should remain separate in the business case. A reduction in CU consumption is operational evidence. The financial result depends on what the organization can do with that improvement.
Fabric also smooths consumption over time, so a short-lived peak does not by itself establish a need for a larger capacity. Microsoft’s guidance distinguishes overload and throttling from performance problems caused by item design. Review demand, service impact, and engineering findings together. Capacity smoothing and throttling
For showback, which makes costs visible to the teams responsible, begin with an agreed allocation method. If the organization later wants chargeback, which transfers costs into those teams’ budgets, finance needs explicit rules for shared services, unused capacity, and exceptions. The monitoring data informs those rules; the organization must decide what is fair and useful.
Put the information into an operating routine
I would introduce FUAM through a recurring review involving the platform owner, a finance or FinOps partner, and the relevant service owners. Start with one capacity or business domain so the group can establish the quality of the evidence and complete a few decisions.
Before reviewing consumption, confirm that collection is current and the period is representative. Then consider a small set of material questions: which services are driving demand, which findings warrant engineering effort, and whether any access or ownership issues need attention. Give each agreed action an owner and a review date.
Track the resulting change against a baseline. For an optimization, compare similar workloads and preserve the service requirements. For cleanup, record the assets actually retired. For a spending decision, retain both the recommendation and the billing or demand evidence behind it. This makes the next review more informative than the previous one.
There is some operating work to budget. FUAM consumes capacity itself, and collection frequency affects that consumption. The deployment guidance recommends testing on non-production capacity first. Deployment guidance
The beta optimization module also has a specific permission model: it requires a service principal and Azure Key Vault, adds that principal to relevant workspaces, and requires a permanently assigned tenant administrator for execution. PIM-elevated roles are currently unsupported. Security and platform owners should review that design before enabling it. Optimization authorization
Existing users should plan upgrades as maintained software. The update process preserves collected lakehouse data but overwrites supplied items by name and resets pipeline parameters. Preserve customizations and restore the intended settings as part of the update. FUAM update instructions
Make the next capacity decision easier to explain
FUAM’s latest updates make it more useful as evidence for running Fabric as a business service.
The next step for a business leader is to choose an upcoming capacity or service decision and ask the team to support it with that evidence. Establish what the service delivers, what it consumes, and which improvement or investment would change the outcome. Then assign someone to verify the result. That is how a monitoring capability earns a place in the management of the platform.
