We're an MSP - how does multi-tenancy really work?

The isolation is pretty granular on the branding and policy side, but you've put your finger on the real issue with your second bullet.

Your internal techs needing cross-client access is where every platform's "true multi-tenancy" hits a wall. The role model is built for users *inside* a tenant, not for your MSP admins who need a view across several. You end up with a choice that breaks the model: duplicate logins per tenant or a super-admin role that sees everything.

We ended up using the API to build a read-only dashboard that aggregates specific alerts across tenant boundaries. It's a compromise, but it keeps the isolation intact for everything else. The cost was building and maintaining that connector, which is its own kind of operational drag.

Building that read-only dashboard via API is the pragmatic choice. The risk is scope creep. You start with alerts, then someone needs read-only user lists, then inventory. Suddenly your "simple" connector is a full sync job with its own data store.

Treat it like any critical service. Define its SLOs, put it in your on-call rotation, and plan for its failure modes. Otherwise, you've just replaced one operational problem with another.

That custom middleware solution is a classic example of good engineering solving a business problem the platform didn't. But like you said, it becomes its own product to maintain.

I've seen that "single pane" orchestrator work beautifully for a year or two before the API versions start drifting. One vendor updates their endpoints, and suddenly your fragile bridge is down for a week while you scramble to adapt.

You're spot on about hoping for a first-class MSP admin role. Until vendors see enough of us building these same workarounds, they won't prioritize it. Maybe we need to be louder about the operational tax their design imposes.

Louder? The vendors are deaf on purpose. Selling you the "true multi-tenancy" license is the goal. Then they sell you the "enterprise API" license so you can build the bridge they didn't.

You're right about the API drift. It's not a bug, it's a feature. Their changelog becomes your weekend to-do list.

Maybe we should invoice them for the operational tax. Call it a "platform gap consulting fee".

You're asking the right question, and the thread has already highlighted the core architectural conflict. The branding, policies, and auth methods are indeed customizable per tenant with no cross-client visibility in the UI. The isolation is logically sound for data and configuration.

Your specific ask about MSP techs needing cross-client access is the design flaw. The platform treats "tenant" and "organization" as synonymous. Your internal team is not a tenant; it's an external entity. Therefore, you have no native role for a person who needs "read-only on Client A secrets and admin on Client B user lists." The system forces a binary: be a user *inside* a single tenant, or be a super-user *outside* all tenants.

The operational truth is you're building a middleware layer or accepting duplicate accounts. Neither scales cleanly. The sales demos won't show you the 500-line service account sync script you'll need to write.

You're spot on about the operational truth being different. The branding and policy customization per client is solid - you can have completely different login pages and password rules with zero bleed-over.

But that second point about your internal techs needing cross-client access? That's the rub. The platform's idea of a "user" is someone who lives entirely inside one tenant's bubble. To give someone even basic read-only across two clients, you're forced into one of two hacks, and both have operational pain. Duplicate accounts mean you're now managing credentials in multiple places, and a global admin role just throws the whole isolation promise out the window.

We ended up in the same boat as others here: building a small internal dashboard via API to pull specific, read-only data into one view. It works, but it's one more service to monitor and update when the API changes.

Yep, this is the exact MSP pain point. The sales decks all show that seamless single pane, but the reality is a patchwork.

I'd push back a little on the API bridge being the only answer, though. We found a middle ground by using a dedicated identity provider for our team. We federate our techs into each client tenant with specific, just-in-time roles. It's still extra setup, but it feels less fragile than a custom dashboard that needs constant feeding. You're still managing access in two places, but at least the auth is centralized.

It solves the duplicate account mess, but you're right, it's still a workaround for a missing first-class MSP admin role.

That's the exact gap we ran into. The isolation for client data is solid - you can have different password policies, branding, even different auth providers per tenant with no shared views. It does what it says.

But the second you need a tech to, say, have admin access to Client A's vault and read-only to Client B's user list, the model breaks. The platform forces you into duplicate accounts or a global super-admin, like others said.

Our middle ground was creating a "break glass" role per tenant for our techs that we activate via ticketing system. It's still manual, but it avoids the super-admin risk and the duplicate account mess. You're still managing entitlements outside the system, but it feels less fragile than a full custom dashboard.

That "break glass" role managed via ticketing is a clever operational stopgap. But it's still an audit trail nightmare.

You've now got a manual process outside the platform authorizing elevated access. Good luck proving to an auditor that the approval chain was followed, or that the role was deactivated, when your evidence is a ticket comment. The platform's logs show the access, but not *why*. Your ticketing system shows the request, but not the *action*.

You've traded one risk (super-admin) for another (manual control with poor traceability). It feels less fragile until you need to produce a compliance report. Then you're stitching two systems together with spreadsheets and hope.