---
title: Configure Fabric access in your own tenant
canonical: "https://cloudmonitor.ai/docs/cloudmonitor-on-fabric/how-to-host-cloudmonitor-in-your-own-fabric/"
description: "What your Fabric administrator sets up for the default arrangement: CloudMonitor deployed into a Fabric workspace on capacity you own, in your own tenant."
---
import DocsScreenshot from '~/components/docs/DocsScreenshot.astro';
import workspaceType from '~/assets/docs/cloudmonitor-on-fabric/fabric-workspace-01-workspace-type.png';
import workspaceAddAdmin from '~/assets/docs/cloudmonitor-on-fabric/fabric-workspace-02-add-admin.png';
import tenantSettingCallPublicApis from '~/assets/docs/cloudmonitor-on-fabric/fabric-tenant-setting-01-call-public-apis.png';
import tenantSettingCreateWorkspaces from '~/assets/docs/cloudmonitor-on-fabric/fabric-tenant-setting-02-create-workspaces.png';
import tenantSettingCreateFabricItems from '~/assets/docs/cloudmonitor-on-fabric/fabric-tenant-setting-03-create-fabric-items.png';
import tenantSettingFabricAppItems from '~/assets/docs/cloudmonitor-on-fabric/fabric-tenant-setting-04-fabric-app-items.png';
import tenantSettingOneLakeExternalApps from '~/assets/docs/cloudmonitor-on-fabric/fabric-tenant-setting-05-onelake-external-apps.png';
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](/docs/cloudmonitor-on-fabric/architecture-and-data-flow/) sets out
where each layer runs in both arrangements.
:::note[Admins only]
You need the **Admin** role to do this. Admins are set in Settings ▸ Users & Access. If you don't
see the screens below, ask an admin in your organization.
:::
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
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:
1. 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.
2. 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.
3. 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.
4. 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
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](https://learn.microsoft.com/fabric/admin/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
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](https://learn.microsoft.com/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
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
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](/docs/how-to/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.
## Related
- [Security and data isolation](/docs/reference/security-and-data-isolation/)
- [How to invite users and assign roles](/docs/how-to/how-to-invite-users-and-assign-roles/)