← Back to insights

Practice · 20 August 2026 · 6 min

One console, many tenants: what MSPs actually need from Entra ID tooling

Tenant switching, delegation per client, an order queue that knows whose change it is, and cost allocated per client. Everything else is secondary.

Tooling built for one organization and extended with a tenant picker behaves differently from tooling that assumed many tenants from the start. The difference shows up in three places: delegation, the queue and the invoice.

Delegation is per client, not per person

An agent may reset passwords in every client tenant but order new hires in one. Expressed as admin roles handed out by hand, that is unmanageable at twenty clients. Expressed as access rules — who may request what, in which tenant, with which approver — it is a table you can review in a meeting.

The queue has to know whose change it is

Requests from every client should land in one place, tagged with the client, the requester and the approval state. The alternative is a mailbox per client and an agent who keeps five browser profiles open, which is where retyping errors come from.

The invoice and the tooling should agree

License spend allocated per client, per period, from the same source as your own billing, removes the monthly reconciliation exercise nobody enjoys. It also surfaces unused licenses with a cost attached, which is the easiest margin an MSP can hand back to a client.

And the language nobody asks about

If your clients are Nordic and your admins are not, per-user language matters more than a feature list suggests. The client's employees see Norwegian, Swedish, Danish or Finnish; your team sees English; it is the same tenant and the same data.

RELEVANT SOLUTION

See how this is handled in practice: