Can GitHub Copilot deploy FUAM from one prompt?

What happens if the prompt is only this?

Install https://aka.ms/fuam

It is enough to start discovery. It is not enough to authorize a tenant change, choose a capacity, create credentials, or define success.

Newer agentic models can inspect the repository, follow linked documentation, read notebooks, and prepare a deployment plan. That is useful. It does not remove the environment-specific decisions.

This article shows where I would let Copilot help with Fabric Unified Admin Monitoring, and where I would keep an explicit human approval.

What FUAM is

FUAM stands for Fabric Unified Admin Monitoring. It is a solution accelerator in the Microsoft Fabric Toolbox repository.

It combines administrative and operational data such as:

• tenant and delegated-tenant settings;
• activity events;
• workspace and item inventory;
• capacities and Capacity Metrics data;
• refreshable items;
• Git connections; and
• Scanner API metadata.

It uses Fabric pipelines, notebooks, a Lakehouse, semantic models, and Power BI reports. Raw and transformed data remains available for custom monitoring.

FUAM is not an official Microsoft product or service. It is an open-source solution accelerator without official Microsoft support. Use a non-production capacity first and use the repository issue tracker for template-specific problems.

Why the short prompt is underspecified

It does not say:

• which tenant or capacity to use;
• whether a workspace and service principal may be created;
• which tenant settings are enabled;
• whether a compatible Capacity Metrics app exists;
• where credentials belong;
• whether this is a test or production deployment;
• which history windows to load; or
• what “done” means.

There is also no single install command. The official route downloads and runs a notebook, configures two cloud connections, runs an orchestration pipeline, refreshes semantic models, opens the report, and schedules later loads.

A safer one-line prompt

Deploy FUAM from https://aka.ms/fuam into my Fabric tenant. Read the official repository and deployment guide first, create a preflight checklist, and stop for approval before changing tenant settings, creating identities, storing credentials, or deploying resources.

That tells Copilot to discover first and expose missing decisions.

The prompt I would use for a real deployment

I want to deploy Fabric Unified Admin Monitoring from https://aka.ms/fuam.

Goal:
- Deploy FUAM into a dedicated, non-production, capacity-backed Fabric workspace.
- Run the initial load successfully.
- Refresh and validate the supplied semantic models and report.
- Configure a daily incremental run only after the initial validation passes.

Source of truth:
- Use only the current Microsoft fabric-toolbox FUAM repository and its linked documentation.
- Read the README, How_to_deploy_FUAM.md, authorization guidance, and deployment notebook before making changes.
- If the documentation and code disagree, stop and show me the conflict.

Safety:
- Do not create or modify a service principal, tenant setting, cloud connection, Key Vault secret, workspace role, or schedule without my explicit approval.
- Never print or commit secrets.
- Prefer Key Vault for unattended authentication.
- Test on a non-production capacity.
- Do not assume that a successful notebook run means the solution works.

Process:
1. Produce a preflight checklist and identify the values you still need from me.
2. Verify capacity, permissions, tenant settings, Capacity Metrics prerequisites, and XMLA access.
3. Prepare the official Deploy_FUAM.ipynb notebook and explain every manual portal step.
4. Guide me through deployment.
5. Configure the required Power BI and Fabric API cloud connections.
6. Run Load_FUAM_Data_E2E with safe initial-load parameters.
7. Refresh FUAM_Core_SM and FUAM_Item_SM.
8. Validate FUAM_Core_Report and the Lakehouse tables.
9. Propose daily incremental parameters and a schedule.

Success criteria:
- The deployment notebook completes.
- The two API connections authenticate.
- The initial orchestration pipeline succeeds.
- FUAM Lakehouse tables contain current data.
- Both semantic models refresh.
- The core report opens without model-field errors.
- A second incremental run does not duplicate or unexpectedly remove data.

Keep a checklist with evidence for every completed step. Stop when an action
needs tenant-admin approval or a secret.

The important part is not prompt length. It is the operating contract: source, authority, safety boundaries, process, and acceptance tests.

1. Inspect the source

Set-Location D:\
git clone https://github.com/microsoft/fabric-toolbox.git
Set-Location D:\fabric-toolbox\monitoring\fabric-unified-admin-monitoring

Read:

• README.md;
• how-to/How_to_deploy_FUAM.md;
• scripts/Deploy_FUAM.ipynb;
• media/documentation/FUAM_Authorization.md;
• media/documentation/FUAM_Technical_Deep_Dive.md; and
• the configuration and source folders used by the notebook.

Ask Copilot to turn those files into a prerequisite matrix. Do not ask it to fill gaps from memory.

2. Complete the preflight

The deployment guidance requires:

1. a Power BI or Fabric capacity;
2. permission to create a Fabric workspace;
3. permission to create a service principal;
4. a permanent Fabric Administrator or the documented service-principal and Key Vault alternative;
5. the tenant setting that lets FUAM workspace administrators create items;
6. XMLA endpoints enabled;
7. a dedicated Capacity Metrics app workspace on P or F capacity with XMLA read access; and
8. a compatible Capacity Metrics app version.

The FUAM service principal should be in a group enabled for:

• Service principals can use Fabric APIs; and
• Service principals can access read-only admin APIs.

The repository says not to add Power BI API permissions “just in case.” Follow its current authorization guidance.

3. Create a dedicated workspace

Create a workspace such as FUAM on a test P or F capacity. Record its name, ID, capacity, administrators, deployment owner, environment, retention choice, and activity-anonymization choice.

Those are deployment inputs, not administrative trivia.

4. Import and run the notebook

Download Deploy_FUAM.ipynb and import it into the workspace. Run all cells.

The notebook creates or updates FUAM items. Existing system objects are matched by name and may be overwritten, so inspect customizations before rerunning it.

When a cell fails, preserve the first error and classify it as a prerequisite failure or code defect before changing the notebook.

5. Configure the API connections

Configure these Web v2 connections:

Do not paste a client secret into Copilot. Enter it through Fabric or retrieve it through the approved secret-management path.

6. Prepare Capacity Metrics

Use a separate Capacity Metrics app instance when possible. Move its workspace from the default Pro workspace to P or F capacity and record its workspace or model ID, app version, XMLA configuration, and deployment-owner access.

7. Run the first load

Open Load_FUAM_Data_E2E. For the first run, the guidance allows:

• metric_days_in_scope: up to 14;
• activity_days_in_scope: 28; and
• display_data: true for diagnostics.

The other parameters cover domains, inventory scope, Key Vault authentication, activity anonymization, raw-file retention, and the number of semantic models. Privacy and retention are governance decisions. Have the data owner approve them before running.

8. Refresh and inspect reports

After the load:

1. refresh FUAM_Core_SM;
2. refresh FUAM_Item_SM;
3. open FUAM_Core_Report;
4. inspect several pages;
5. confirm deployment metadata; and
6. verify expected workspaces, capacities, and activities.

If a visual cannot render, refresh model metadata. The repository describes a recovery path through Edit tables and Confirm when API fields were initially absent.

9. Validate the Lakehouse

Ask Copilot for queries covering:

• latest ingestion timestamps;
• row counts by major table;
• distinct capacities and workspaces;
• duplicate business keys;
• activity-date coverage;
• missing tenant identifiers; and
• differences between the first and second run.

“The query ran” is not the same as “FUAM is complete.”

10. Schedule the incremental load

After validating the initial load:

metric_days_in_scope = 2
activity_days_in_scope = 2

Schedule Load_FUAM_Data_E2E daily. The overlapping two-day window helps with delayed events, but validate how the implementation handles the overlap.

For unattended execution, use the documented Key Vault and service-principal route rather than depending on the notebook owner’s interactive identity.

So, is the tiny prompt enough?

It may be enough for Copilot to find the repository, locate the guide and notebook, build a plan, and ask better questions than older models.

It is not enough to authorize:

• tenant-wide setting changes;
• identity or secret creation;
• capacity selection;
• privacy and retention choices;
• production deployment; or
• acceptance of incomplete monitoring data.

The model is more capable. The tenant is still specific.

The real test is whether Copilot can preserve this chain:

official source
  -> prerequisites
  -> approvals
  -> deployment
  -> credentials
  -> initial load
  -> model refresh
  -> data validation
  -> incremental schedule

If one link is missing, the agent created some Fabric items. It did not install FUAM.

Sources

• FUAM short link
• FUAM in the Microsoft Fabric Toolbox
• Official FUAM deployment guide
• FUAM deployment notebook
• FUAM technical deep dive
• GitHub Copilot for the command line

If FUAM helps, star the Fabric Toolbox repository and report deployment findings through its issue tracker.