Managed service providers · 19 August 2026 · 4 min
A tenant switcher is not multi-tenant architecture
Plenty of tools let you switch between tenants. Very few are built for a world where a hundred tenants is the normal state. The difference shows up in configuration, reporting and risk — and it cannot be bolted on afterwards.
The tooling market around Entra ID is, in practice, built for one customer: one organisation, one directory, one IT team. When such tools meet an MSP, they typically get a tenant switcher bolted on — a dropdown that changes context. It looks like multi-tenant. It is not.
True multi-tenant architecture comes down to three things a dropdown does not solve.
First, configuration. Your clients are not alike. One wants group changes approved by the nearest manager, another wants everything routed through its own IT lead, a third has field names and roles that follow a line-of-business system. If the tool has one global configuration, every client difference becomes a manual routine alongside the tool — and routines alongside the tool are where the mistakes live. In Entra Logic, every module is configured per tenant: approval flows, enabled modules, access rules and field names can be set differently for each client, in the same system.
Second, economics. An MSP must be able to answer what each client actually costs and consumes: licenses, Azure consumption, change volume. If cost reporting lives in a different system from identity management, someone has to reconcile them — every month, for every client. Entra Logic allocates cost and license reporting to company and client in the same system that manages the identities behind the cost. That is the basis for chargeback that adds up, with no spreadsheet in the middle.
Third, risk and separation. When a hundred tenants are administered through one surface, the question is not whether someone will one day make a change in the wrong tenant — it is what happens then. In a direct-editing model, the answer is: the change happens. In an order model, the answer is: the request is routed into that tenant's approval flow, and an approver at the wrong client sees an order that makes no sense. The approval step is not just governance — it is a context barrier.
These are architectural decisions, not features. Per-tenant configuration in every module, cost allocation across companies, and approval flows that follow the tenant have to sit in the foundation from the first line of code. Entra Logic is built that way because its first large users were precisely environments with many companies — Amesto runs a group of 58 companies with three people in IT on this model. [Assumes the client's approval of name usage is in place.]
Here is a test you can run against any tool, ours included: ask to see how two clients with different approval flows look side by side, and where the per-client cost report comes from. If the answer involves the word "export," you know what you are looking at.
Norwegian version: Les artikkelen på norsk
Related reading
- The audit trail is no longer internal — it is something your clients buy
Managed service providers · 4 min
- Copilot credits turn group hygiene into a budget question
Managed service providers · 4 min
- One console, many tenants: what MSPs actually need from Entra ID tooling
Practice · 6 min