Multi-Organisation

Overview

A Partner licence ships with its own dedicated Cirrova instance, available in two deployment shapes:

• Cirrova-hosted. Cirrova Systems provisions and manages the instance on dedicated infrastructure for the partner — same product, same release cadence, but isolated from every other Cirrova customer's data and from the shared SaaS.
• Self-hosted. The partner runs Cirrova in their own Azure subscription. Useful where data residency, regulatory, or operational policies require the platform to live inside the partner's own environment.

Either way the Partner licence enables the Multi-org capability on that instance, which unlocks two things:

• Platform admins can create as many organisations under the instance as they like (subject to any caps the licence sets).
• A user account can belong to more than one organisation. When they sign in they're shown a Choose organisation screen and can switch context at any time without signing out.

Each organisation is its own world. From inside an organisation, the experience is identical whether the platform hosts one organisation or one hundred — the multi-organisation nature is invisible until you cross between organisations or step up into the Platform section.

What's isolated per organisation

Each organisation has its own:

• Members and roles. Adding a user to one organisation doesn't add them to another. Tenant access roles (Viewer / Editor / Admin) are scoped to that organisation's tenants — see Access Control.
• Azure tenant connections. Each organisation connects to its own Azure tenants via its own service-principal, certificate, or managed-identity credentials. Cost and resource data collected from those tenants is only visible inside that organisation.
• Cost data, anomalies, recommendations, budgets, reports. Everything Cirrova collects or computes is partitioned by organisation. There's no cross-organisation aggregation in the user-facing UI.
• Settings. Default display currency, MFA enforcement, SSO configuration, anomaly sensitivity (per tenant), and the alerting channels and rules that route platform events to email, chat, or webhook destinations — all scoped to the organisation.
• Branding. Logo uploaded under Organisation Settings → General appears on the org switcher, in report headers, and in invitation emails for that organisation only.
• API keys. Each organisation issues its own keys. A key authenticates against the organisation it was created in — there's no platform-wide key.
• Activity log. Each organisation has its own audit log under Organisation Settings → Activity log; the platform-level activity log under Platform → Activity log spans every organisation.

What's shared across organisations is the underlying platform infrastructure: the database, Key Vault, Azure Data Explorer cluster, blob storage account, the email sender, and the snapshot collection runner. Organisation members never see those pieces — only platform admins do.

Switching between organisations

A user account that's a member of more than one organisation sees a Switch organisation link in their sidebar account menu. Clicking it opens the Choose organisation page (also shown immediately after sign-in for multi-org accounts) listing every organisation they belong to, with the organisation logo or initials and an Owner badge where applicable. Selecting one issues a fresh org-scoped session token and lands you on that organisation's Dashboard.

Single-org users never see the switcher — the link is hidden, sign-in goes straight to the Dashboard, and the experience is identical to a non-multi-org licence.

MSP staff: one identity across clients

The multi-organisation model works particularly cleanly for managed service providers. The pattern is:

• The MSP runs its own Cirrova organisation against its own Entra tenant (e.g. msp.example) for internal use.
• It creates a separate Cirrova organisation for each client, each one configured against the client's own Entra tenant (client-a.com, client-b.com, and so on).
• MSP staff who manage a client's environment are invited as members of that client's Cirrova organisation using their MSP email address — e.g. jane@msp.example — even though that email belongs to a different Entra tenant from the client organisation's configured one.

When Jane signs in:

1. She clicks Sign in with Microsoft and authenticates against her msp.example Entra tenant — the MSP's identity provider, which she uses every day.
2. Cirrova matches her token to her user account and sees that she's a member of more than one Cirrova organisation — her MSP organisation, plus every client organisation she's been invited to.
3. She lands on the Choose organisation switcher and picks the client she wants to work in. Cirrova drops her on that organisation's Dashboard with whatever per-tenant access she's been granted inside it.

The result is one Cirrova identity per MSP employee, regardless of how many client organisations they manage. There's no per-client password to rotate, no per-client MFA enrolment to chase, and no cross-tenant guest accounts to provision in each client's Entra tenant.

The platform admin role

A platform admin is a user account flagged at the platform level rather than the organisation level. They can manage every organisation on the instance, see cross-organisation data, and access the Platform section in the sidebar (which is hidden from everyone else).

Platform admin status is independent of organisation membership — a platform admin doesn't automatically gain access to data inside an organisation; they need to be invited as a regular member to do that. The two roles separate "I run the instance" from "I work in this organisation".

The Platform section

Platform admins see an additional Platform group in the left sidebar with the following pages.

Overview

Top-level health and statistics. Counts of organisations and Azure tenants attached across the whole instance, with quick links into the more detailed pages.

Organisations

The list of every organisation on the instance — name, slug, member count, created date. Click New organisation to spin up another. The dialog asks for:

• Organisation name — the display name members will see.
• Owner email address and Owner display name (both optional) — if supplied, an initial owner account is created and invited; leave blank to create the organisation empty and invite members later from inside it.
• SSO-only account — tick to mark the initial owner as SSO-only, so they can never sign in with a password.

Snapshots

The collection-run history across every organisation: status, started time, duration, the organisation and Azure tenant that ran, the run type, and what triggered it. A useful first stop when an organisation reports stale numbers — you can confirm whether the most recent run completed and how long it took.

Snapshot schedules

One row per organisation showing the collection interval (e.g. Every 6h), an offset in minutes, and the resulting daily run times in UTC. The Rebalance action redistributes offsets so that organisations don't all run at the same minute, smoothing the load on shared infrastructure. Rebalance is non-destructive — it only changes when each org runs, not how often.

Infrastructure

A read-only health summary of every external service the platform depends on, with a Test button on each:

• SQL Database — server and database name, plus row counts for cost and metric data points.
• Key Vault — vault URI used for storing customer credentials and platform secrets.
• Azure Data Explorer — cluster URL and database, used for high-volume cost and metric data.
• Blob Storage — account, blob endpoint, and container used for report exports.
• Managed Identity — the platform's own client ID, if it runs as a managed identity in Azure.
• Email (Microsoft Graph) — tenant and client ID for the app registration that sends platform emails.

The build version of the running platform is shown at the top of the page.

Email

Outbound email sender configuration for the whole instance. Sets the Sender address and Sender display name that appear in the From field of every email Cirrova sends — invitations, password resets, budget alerts, report notifications. The sender address must be a licensed Exchange Online mailbox the Cirrova app registration has Mail.Send access to. A Send test email action verifies the configuration end to end.

Licence

The platform's licence details — file path, validity status, who it's licensed to, ID, issue and expiry dates, and the feature flags it enables. The two flags that matter most are:

• Multi-org — when Enabled, platform admins can create more than one organisation.
• White-label — when Enabled, the partner can rebrand the platform.

Resource and tenant caps are also shown here (often Unlimited on a partner licence).

Activity log

A platform-wide audit log spanning every organisation, with date-range, level (Information / Warning / Error), and event-type filters. The event taxonomy includes authentication events (logins, MFA enrolments, API key auth), organisation lifecycle (created, renamed, deleted), membership and role changes, tenant changes, snapshot runs, budgets, and reports — useful for incident reviews that span the whole instance.

Branding & white-label

Two layers of branding are available.

Per-organisation branding is part of every licence. An organisation owner can upload a logo under Organisation Settings → General → Branding (PNG, JPEG, GIF, WebP, or SVG, up to 512 KB). The logo appears on the org switcher card, in report headers, and on invitation emails for that organisation. Default display currency is set on the same page and used as a fallback wherever a resource's own currency isn't available.

Platform-level white-labelling is gated by the White-label licence flag. Where enabled, the partner can rebrand the platform itself — sign-in pages, default email templates, and the like — so end customers see the partner's identity rather than Cirrova's.

Cirrova organisations vs Azure tenants

Two different concepts use the word "tenant" in this domain, and the distinction is worth being explicit about:

• An organisation in Cirrova is a tenant of the Cirrova platform — a discrete customer with its own users, settings, branding, data, and audit log. The "multi" in multi-organisation on this page refers to running more than one of these.
• An Azure tenant (or Microsoft Entra tenant) is a directory in Azure. Each Cirrova organisation can connect to one or many Azure tenants as data sources for cost and resource collection. That's a separate feature — see Connecting Azure.

So a single platform instance might host ten organisations, each connecting to several Azure tenants, with hundreds of subscriptions in total. The platform admin sees the whole landscape; an organisation member sees only their own organisation's slice.