From Local scripts to Cloud Governance: Our Journey Deploying FUAM in Microsoft Fabric

For any organisation operating at scale, governance isn’t just a nice-to-have, it is the backbone of a healthy data environment.
​For the past two years, our team relied on a Power Shell Rest API based scripts, scheduled to run locally, to extract our Power BI tenant logs. It worked, but it wasn’t efficient. We often miss logs when the laptop was not awake on a scheduled time.
At the end of 2025, we took a major leap forward. We deployed Fabric Unified Admin Monitoring (FUAM), a comprehensive solution designed to centralise admin governance and monitoring within Microsoft Fabric.
Here is a look at our deployment experience, the technical “gotchas” we faced, and how we customised the solution to build a truly robust monitoring capability.
​
What is FUAM?
For those unaware, FUAM (Fabric Unified Admin Monitoring) is a community-driven solution accelerator. It isn’t just a report; it’s a data application built natively on Fabric components – Pipelines, Notebooks, and Lakehouses.
​
It extracts granular data on tenant settings, user activities, and capacity usage, solving the common “30-day retention limit” problem by building a permanent historical log. We appended our old historic data of last 2 years to get the insights for even longer periods.
The Deployment Experience
The initial deployment was surprisingly smooth. The solution is designed to be deployed via a single notebook: Deploy_FUAM.
We executed this notebook, and it automatically provisioned the necessary artifacts (Lakehouses, Pipelines, Semantic Models) directly in our workspace.
​
​To ensure secure and automated access, we authenticated our connections using a Service Principal. This allows the extraction pipelines to run reliably in the background without tying them to an individual user’s credentials.The “Gotcha”: The Domain Unit Error
While the setup was 90% smooth, we hit one specific snag that is worth sharing for anyone else attempting this.
During the execution of the pipelines in FUAM version 2026.1.1 , the process failed on the data pipeline. Specifically, the notebook responsible for 01_Transfer_Domains_Unit failed to execute.
The Root Cause: After investigating the logs, we discovered the code was strictly expecting subdomains. Our tenant setup initially didn’t match this pattern perfectly, causing the script to error out.The Fix: We resolved this by creating a “dummy” sample domain that included a subdomain in our Fabric environment.
​Once this structure existed, the notebook logic was satisfied, the script executed successfully, and the pipeline completed.
Customisation and Scheduling
We have now scheduled the extraction pipeline to run daily.
This creates an incremental load strategy that retains all historic capacity usage and log data, giving us a trend line that extends far beyond the default retention periods.
​
However, we didn’t stop at the default offering. To match the specific needs of our use, we customised the FUAM_Core_Report:
​

  • Report Views: We added detailed breakdowns of report consumption.
  • View Per User: We built a “User 360” page to audit activity at the individual level, which is critical for report adoption tracking.
  • Merged Historic Logs: We integrated over 10 million rows of legacy Power BI Logs into the FUAM activities table.
    ​After converting Id columns to uppercase and filtering out unnecessary fields, we successfully consolidated all our log data into a single, comprehensive source of truth for all our log data of past few years.
The Result: A Comprehensive Governance Hub
The outcome has been a game-changer. We moved from local exports to a fully automated, “set-it-and-forget-it” backend with a beautiful front end.
​
If you are still manually exporting audit logs, I highly recommend looking into FUAM. It has transformed our governance from a reactive chore into a proactive strategy.

Haider Shah

Power BI Developer

Haider is a Power BI Developer at Blue Sky ERP