Configure Fabric access in your own tenant fabric
At onboarding you choose whose Fabric capacity your reports run on. The default is yours: we deploy the modeled cost tables, the semantic model and the CloudMonitor app into a Fabric workspace in your own tenant, and your people open them with the accounts they already sign in with. Choose CloudMonitor-hosted and we run that workspace on our own capacity, with your people invited into our tenant as guests. Ingest and cleansing run in CloudMonitor’s tenancy in both arrangements.
| In your own Fabric tenant (default) | CloudMonitor-hosted | |
|---|---|---|
| Fabric capacity your reports run on | Yours, in your own tenant | Ours |
| Who pays for that capacity | You, on your own Fabric bill | CloudMonitor, inside your license price |
| How your people sign in | Their own accounts, in your Entra directory | Invited into our tenant as B2B guests |
| What governs access and sharing | Your workspace permissions | The workspace permissions we hold |
| What your data team can query | The semantic model, in a workspace they already reach | The reports we publish to your users |
| Where ingest and cleansing run | CloudMonitor’s tenancy, in the region you choose | CloudMonitor’s tenancy, in the region you choose |
Your license price is set by your annual Azure Consumption Revenue. In your own Fabric tenant, the capacity your reports, semantic model and CloudMonitor app run on sits on your own Fabric bill. Under CloudMonitor-hosted we run that capacity for you. CloudMonitor’s ingest, cleansing and modeling run on Fabric capacity in our own tenancy in both arrangements.
This page covers the default arrangement, in your own Fabric tenant. Your side of it is a workspace on Fabric capacity in a supported region, five tenant settings in your Fabric admin portal, and Admin access on that workspace for the CloudMonitor application. Below is what each involves, and what you get once they are done. Architecture and data flow sets out where each layer runs in both arrangements.
You also need administrator rights in your own Microsoft Fabric and Microsoft Entra tenants. In most organizations that is a different person, so plan for two people rather than one.
What you are agreeing to
Section titled “What you are agreeing to”CloudMonitor is deployed by an automated job that authenticates as the CloudMonitor application and writes into the workspace you nominate. Once you send us the details in Step 4, that job:
- Creates a lakehouse in your workspace to hold your finished cost tables, and creates the tables themselves. They start out empty; your data lands on the next processing run.
- Deploys the CloudMonitor semantic model into the same workspace and points it at that lakehouse. It is the same model every customer gets rather than a variant built for you, so it keeps pace with each release.
- Creates a connection the semantic model reads your data through, authenticating as the CloudMonitor application. A model deployed through the Fabric APIs otherwise defaults to single sign-on, which an application cannot use. The job then takes ownership of the model so it can refresh it on schedule.
- Publishes the CloudMonitor app your people sign in to, and the data store it saves your settings, cost groups and budgets into.
All of that is write activity, which is why read-only access is not enough.
Reading your raw export, joining it and cleaning it up run in CloudMonitor’s tenancy in both arrangements. In your own Fabric tenant, only the finished cost tables are written across into your lakehouse, so what your reports read is the same modeled data we build for every customer.
CloudMonitor holds a scoped workspace role in both arrangements so we can deploy, update and support the app. In your own Fabric tenant that role covers only the workspace you granted it on. It carries no visibility of any other workspace in your tenant and no rights over your Entra directory.
Step 1 — Create the workspace on Fabric capacity
Section titled “Step 1 — Create the workspace on Fabric capacity”Create an empty workspace in your own Fabric tenant and assign it to a capacity that can run Fabric items: an F SKU, a Fabric trial, or a Power BI Premium P SKU with Fabric enabled. A Power BI Pro license, Premium Per User and Power BI Embedded capacities will not do — the reports read your data directly from storage, and that only works on Fabric capacity. Keep the capacity running rather than paused.
Starting a Fabric trial does not move an existing workspace onto it, and a workspace can sit on a capacity nobody remembers assigning. Once the workspace exists, open Workspace settings ▸ Workspace type and confirm it shows Fabric or Fabric Trial, with the capacity you meant to use named under it. Checking takes a few seconds and is the difference between the deployment finishing and stopping part-way.
Check the region before you create the capacity. The CloudMonitor app is a Microsoft Fabric App item, and Fabric Apps are still in preview and not offered in every region. We confirm which regions are available with you at onboarding. Australia East is supported; Australia Southeast, New Zealand North, UK South and North Europe are among those that are not. In the United States, North Central US and East US are supported; East US 2, South Central US and West US 3 are not. The current list is in Microsoft’s Fabric region availability. Capacity in an unsupported region still takes your cost data and the semantic model, but the app cannot be deployed onto it. Settle this before you work through the rest of this page.
Your own capacity’s region is yours to set and does not have to match the region your cost processing runs in. We recommend matching them, so the modeled cost tables are not written across regions.
Query costs land on that capacity, so size it with your own data team rather than treating it as an afterthought. As a starting point: F8 for a pilot, F16 for production when your CloudMonitor users already have Power BI Pro (it is included in Microsoft 365 E5), and F64 when many of them do not. The CloudMonitor app reads your data as the signed-in user, and on capacities smaller than F64 Microsoft requires a Power BI Pro license for everyone viewing it. A Fabric trial behaves like F64, so it hides this. A trial also lasts 60 days, and Fabric items are deleted seven days after it ends unless the workspace moves to a paid capacity, so choose your F SKU, in the same region, before the trial ends.
Give the workspace a name your people will recognize in the Fabric portal; it becomes the home of the CloudMonitor app they sign in to.
Nothing needs to be in the workspace. Everything CloudMonitor reads and writes is created for you in Step 4.
Step 2 — Turn on five tenant settings
Section titled “Step 2 — Turn on five tenant settings”All five sit in the Fabric admin portal under Tenant settings, in the sections named below, and all five have to be on before Step 4 can finish.
| Setting | Section | What it covers |
|---|---|---|
| Service principals can call Fabric public APIs | Developer settings | Every call the deployment makes |
| Service principals can create workspaces, connections, and deployment pipelines | Developer settings | The connection the semantic model reads your data through |
| Users can create Fabric items | Microsoft Fabric | Creating the lakehouse and the app’s database |
| Enable Fabric App Items (preview) | Microsoft Fabric | Publishing the CloudMonitor app |
| Users can access data stored in OneLake with apps external to Fabric | OneLake settings | Writing your cost tables into your lakehouse from our tenant |
Service principals can call Fabric public APIs. Nothing in the deployment can call Fabric while this is off. New tenants get it on by default, so it is usually already there.
Service principals can create workspaces, connections, and deployment pipelines. The deployment needs this to create the connection described above, the one that lets the semantic model reach your data as the CloudMonitor application instead of as whoever opens a report. Without it the model deploys and then fails every refresh. It is off by default, so this is the one you are most likely to have to turn on.
Users can create Fabric items. The lakehouse that holds your cost tables and the database behind the CloudMonitor app are both Fabric items, so the deployment stops at the first one it tries to create if this is off.
Enable Fabric App Items (preview). A Fabric administrator has to enable the Fabric Apps workload before anything in your tenant can create an app item, ours included — see Microsoft’s Fabric Apps overview. Without it your cost data and reports arrive and the app does not.
Users can access data stored in OneLake with apps external to Fabric. We write your finished cost tables into your lakehouse from our tenant, which is the access this setting controls. It is on by default, so the thing to do here is confirm nobody has switched it off.
The middle three are the ones that catch people out. They are off far more often than the first, and none of them announces itself: the deployment authenticates, starts work, and is then refused.
Four of the five do not have to be opened up tenant-wide, and we recommend that you don’t. They accept a security group, which keeps the permissions as narrow as the deployment needs.
Make the group first. The tenant settings only offer groups that already exist, so there is nothing
to select until one does. In Microsoft Entra, create a security group — the name is yours to choose,
nothing depends on it — and add the CloudMonitor application (app ID
ef7bf83e-23c6-4d84-962b-a3b0f14695a5) as a member. Then set each of the four to Specific
security groups and add that group, as below. Enabling them for your whole organization works too,
if that suits how you already run tenant settings.
How much else belongs in the group differs by setting. The two Developer settings apply only to service principals, so the CloudMonitor group can be the only entry on them. Users can create Fabric items and Enable Fabric App Items (preview) also govern your own people, so add the group alongside whatever those settings already cover. Replacing an organization-wide setting with a group that holds only CloudMonitor switches it off for everyone else.
Whichever way you scope them, our application has to be inside the group. A setting scoped to a group it is not in behaves exactly as if it were switched off, and fails in the same way.
The OneLake setting is the exception: Fabric offers no group scoping on it, so it is on or off for your whole organization and there is nothing to scope.
Users can create Fabric items can also be turned off for a single capacity, under Capacity settings ▸ Delegate tenant settings, which leaves the tenant-wide setting looking correct. If your capacity admin is a different person, check there too.
Step 3 — Give CloudMonitor access to the workspace
Section titled “Step 3 — Give CloudMonitor access to the workspace”Open the workspace, go to its access list, and add the CloudMonitor application — app ID
ef7bf83e-23c6-4d84-962b-a3b0f14695a5 — as an Admin. Search for it by name; the picker lists
applications with their App ID beside the name, so you can confirm you have the right one before you
add it. Contributor is not enough: the deployment creates a Fabric SQL database for the app, and
creating one needs Admin or Member. Admin is also what lets the deployment take ownership of the
data model in order to refresh it.
This is the step people most often expect to be unnecessary, so it is worth being explicit: the authorization your organization already gave CloudMonitor to read your Azure cost data grants no rights inside Fabric. Fabric access is granted per workspace, in the workspace, and nowhere else.
The flip side is the good news — because it is the same CloudMonitor application you already authorized, there is no new consent screen and no new application to approve. You are granting a role to an application your organization has already accepted.
If a tenant setting or the workspace role is missing, the deployment stops rather than doing anything partial. It is worth knowing what that looks like: the application signs in successfully and is then refused, so what you see is a permission error, not a failed login.
Not every refusal reads as one, though. If the run stops while creating the lakehouse with
FeatureNotAvailable, it means one of two things: the workspace is not on a capacity that can run
Fabric items, or Users can create Fabric items does not cover the CloudMonitor application. Check
Workspace settings ▸ Workspace type first, then the tenant setting and its capacity-level override.
The Fabric App Items setting is the one that fails late rather than early. Your data model and reports deploy first, and the run stops when it reaches the app.
Step 4 — Send us the workspace details
Section titled “Step 4 — Send us the workspace details”Three things, and then we run the deployment:
- Your Microsoft Entra tenant ID.
- The workspace ID, which is in the workspace URL.
- The email address of your Organization Owner — the first CloudMonitor account in your workspace, and the one that invites everybody else.
Choose the owner deliberately rather than picking whoever is handy. Re-running the deployment cannot hand ownership to somebody else afterwards, so moving it is a manual job for us. It also sets the domain that invitations are held to, which is covered in How to invite users and assign roles.
The deployment runs as a single job and finishes in minutes. When it does, the workspace holds your cost data model and the CloudMonitor app, and your people sign in with their own accounts in your own Fabric tenant. Your data team can build their own reports on the same data alongside it.
Two things about opening it for the first time, neither of which means something went wrong. Your Organization Owner lands on a short setup wizard rather than a dashboard, because CloudMonitor asks how you want costs grouped before it builds anything. And your reports stay empty until the next processing run writes your cost data across.
We re-run the same job when a release adds tables or measures. It creates whatever is missing and writes into your existing tables in place, so nothing already in your lakehouse is dropped and rebuilt.
Next steps: Wait 24 to 48 hours for your analytics to be onboarded and for health checks to complete.