If you’re running Microsoft Fabric at any real scale, you’ve probably felt the tension: the platform makes it easy to build, share, and iterate—but it also makes it easy to spend, sprawl, and accidentally ship the wrong answer.
The good news is you already have most of the raw ingredients to fix that. What’s missing is an operating model that converts “platform signals” into business outcomes: predictable costs, cleaner estates, and faster response when data is wrong.
In this post I’ll walk through three practical patterns:
- using FUAM as a telemetry backbone for FinOps that people will actually use
- using the same signals for stale workspace detection (without manual audits)
- combining Microsoft Purview lineage with usage signals to identify incorrect datasets that are actively being consumed—and contain the blast radius
Along the way, I’ll stay grounded in business value: what these ideas buy you in dollars, time, and trust.
Why FUAM matters: it turns “admin data” into an analytic asset
FUAM (Fabric Unified Admin Monitoring) is a community-driven solution accelerator that consolidates monitoring data across Fabric and Power BI into a single view—tenant settings, activities, workspaces, capacities, and more.
The key detail is where it lands: FUAM is built using Fabric-native components (pipelines, notebooks, lakehouses, semantic models, reports) and stores the extracted data in ways that are naturally queryable and reportable in Fabric (including Delta/Parquet patterns that support DirectLake-style analysis).
That changes the conversation from “monitoring dashboards” to “a governed dataset about the estate.”
And once you have a dataset about the estate, you can run it like a product.
Using FUAM to build usable FinOps (not just cost reporting)
FinOps fails when it stays abstract. The minute a cost dashboard can’t answer “what changed, who owns it, and what should we do next,” it becomes another report people ignore.
The business opportunity with FUAM is that it captures the operational signals that explain why Fabric spend moves—activity, refresh behavior, inventory growth, and capacity pressure.
Here are a few ways to turn that into an operating rhythm.
Make “showback” legible to non-platform leaders
A usable showback model doesn’t start with CUs and throttling. It starts with business objects leaders recognize:
- workspace / domain / product area
- the handful of high-value reports and semantic models
- refreshables (what runs, how often, and when)
FUAM already extracts workspace and activity-oriented data (including workspaces, capacities, activities, refreshables, and scanner-style metadata).
That means you can attribute platform consumption to the unit that can actually change behavior.
Business value:
- fewer “shared services” arguments about who caused the spike
- faster approvals for capacity changes because leaders see what they’re buying
- a real path to internal chargeback when you’re ready (#FinOps)
Tie spend to unit economics people can improve
Once the cost conversation is anchored to ownership, you can introduce metrics that change decisions:
- cost per refresh (or per refreshable)
- cost per report view (for high-traffic assets)
- cost per pipeline run / notebook execution window (for engineering workloads)
You don’t need perfect allocation to get value. You need directional truth and the ability to compare one team’s footprint over time against itself.
Business value:
- reduces “always-on” behavior (over-refreshing, over-retaining, over-duplicating)
- creates incentives to consolidate datasets and reuse endorsed assets
- reveals where performance tuning yields real dollar impact
Use FinOps Toolkit data as the “financial spine,” and FUAM as the “behavior spine”
If you’re already using Microsoft’s FinOps Toolkit, it’s explicitly designed as an open-source set of resources and tools to accelerate FinOps capabilities across the Microsoft Cloud—including solutions like FinOps hubs and starter reporting assets.
On the Fabric side, Microsoft has patterns for creating a Fabric workspace for FinOps, including exporting cost data using the FOCUS specification (FinOps Open Cost and Usage Specification), a provider-agnostic format for cost details.
What this enables in practice:
- FinOps Toolkit / FOCUS gives you “what did we spend?”
- FUAM gives you “what drove it?” (refreshes, usage, growth, hotspots)
Business value:
- materially shorter time from “cost anomaly” → “root cause” → “fix”
- fewer blanket governance policies, more targeted optimization
- the ability to defend ROI on Fabric with evidence instead of anecdotes (#DataGovernance)
One caution that’s actually a benefit: FUAM consumes Fabric compute units itself, because it runs pipelines and notebooks as part of ingestion and transformation. That’s not a reason to avoid it—it’s a reminder to treat monitoring like a real workload with its own budget and optimization.
Stale workspace detection that reduces risk and cost
Stale workspaces aren’t just clutter. They’re where risk hides:
- orphaned permissions
- uncertified datasets being reused because they “worked last year”
- refresh jobs chewing capacity for no business purpose
- duplicated models that confuse analysts and fracture trust
Fabric provides an admin monitoring workspace designed to help administrators monitor workloads, usage, and governance—and it exposes reports and semantic models you can use to build your own reporting solutions.
FUAM builds on the idea of central monitoring by consolidating more signals into a single, analyzable dataset.
Define “stale” as a business rule, not a vibe
The simplest (and most effective) definition isn’t “nobody opened it.” It’s a combination of signals:
- no report views in X days
- no dataset queries / semantic model activity in X days
- no refreshes or pipeline runs in X days
- no edits or deployments in X days
- no ownership confirmation in X days
With FUAM’s activity + inventory extraction, you can implement these definitions consistently across the tenant instead of relying on manual owner outreach.
Business value:
- reclaimed capacity headroom without asking every team to “do more with less”
- reduced audit exposure from long-forgotten artifacts
- fewer support tickets caused by accidental reuse of abandoned assets
Move from detection to action: “nudges” before enforcement
A mature stale-workspace program doesn’t start with deletion. It starts with a tight feedback loop:
- flag potential stale workspaces
- route to owners (or last active editors)
- require a simple decision: keep / archive / retire
- apply policy outcomes (license mode, capacity assignment, access tightening, retention)
The outcome isn’t just savings—it’s estate clarity. People build faster in an environment where the “official” assets are easy to find and the dead ones are clearly out of the way.
Business value:
- faster onboarding for new analysts and engineers
- fewer duplicated datasets because people can find the right one
- a cleaner foundation for #Purview cataloging and lineage
Purview lineage + usage: finding “bad data in motion,” not just “bad data in theory”
This is the one that hits hardest in the business: when data is wrong, the real cost isn’t the wrong table—it’s the decisions made downstream.
Microsoft Purview and Fabric are explicitly positioned to work together to provide governance and end-to-end lineage from source down to Power BI consumption.
Use Purview to identify the blast radius
Purview can bring Fabric metadata and lineage into the Purview Unified Catalog once you register and scan your Fabric tenant.
The Fabric-to-Purview lineage capability includes many Fabric items (lakehouses, warehouses, pipelines, notebooks, semantic models, reports, etc.).
When you discover a dataset is incorrect (bad logic, late-arriving data, broken join, upstream change), lineage is how you answer:
- What semantic models depend on it?
- Which reports depend on those semantic models?
- Where else was it copied, mirrored, or re-materialized?
That’s the technical value. The business value is time: you compress “days of investigation” into “minutes of scoped impact analysis.”
Use FUAM (or audit signals) to prove it’s being used right now
Lineage tells you dependency. It doesn’t automatically tell you whether anyone is actively consuming the downstream assets today.
This is where the combination becomes powerful:
- Purview lineage: what is connected
- FUAM usage/activity: what is actually happening
With FUAM’s activity signals, you can distinguish between:
- downstream reports that exist but haven’t been viewed in months (low urgency)
- downstream reports used daily by finance or operations (high urgency)
Business value:
- targeted communications instead of “everyone stop using the dashboard” chaos
- fewer unnecessary war rooms
- less reputational damage because you respond quickly and precisely
Turn lineage into a “data incident workflow”
A practical pattern looks like this:
- A data quality check fails or a defect is reported.
- The owning team marks the asset as “suspect” in your governance process (often implemented through catalog metadata conventions).
- Purview lineage identifies downstream dependencies.
- FUAM identifies recent usage and likely impacted consumers.
- You notify exactly the owners and consumer groups who need to know, with a clear “what changed / what’s impacted / what to do.”
If you’ve ever tried to run an incident process without lineage, you know the alternative: broad messages, wasted time, and lingering mistrust.
Be honest about lineage limitations (and design around them)
Fabric’s built-in lineage view is explicitly noted as preview, and some connections may be incomplete or incorrectly shown.
Purview’s Fabric lineage also has some limitations (for example, non-Power BI item lineage is item-level; sub-item lineage isn’t supported for lakehouse tables/files; and certain cross-workspace or external-source scenarios may not be represented yet).
This doesn’t reduce the value—it just means you should treat lineage as decision support, not absolute truth. The strongest implementations pair lineage with:
- data product ownership
- certification/endorsement practices
- automated data quality checks
- usage telemetry
Which brings us right back to the main point: telemetry + lineage is how you move from governance theory to governance outcomes.
Closing: three patterns that turn governance into outcomes
Here’s what we covered:
- FUAM gives you a Fabric-native monitoring dataset that consolidates activities, inventory, capacities, refreshables, and tenant metadata—so you can analyze the estate like any other data product.
- That dataset can power FinOps that’s actionable, because you can attribute spend-driving behavior to owners and track improvements over time—especially when paired with broader FinOps tooling and cost exports.
- The same signals can identify stale workspaces early, reducing risk and freeing capacity without resorting to manual audits.
- Purview lineage helps you find downstream impact when data is wrong, and FUAM usage helps you focus on what’s actually being consumed—making incident response faster, narrower, and more credible.
If you want Fabric to scale without becoming a cost and trust problem, the move is straightforward: start treating monitoring and lineage as first-class data assets. Build the smallest set of signals that answer executive questions (“what are we spending, what are we using, what’s risky”) and let that drive the next governance decision.
