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.