MSP Multi-Tenancy and Co-Management
Two or more MSPs servicing the same client at once, and a client that can change or drop any of them without moving a single ticket.
The problem
The client has an incumbent MSP for the helpdesk and has just hired a second firm for cloud and security. Both need to see the same tickets, the same asset inventory, the same maintenance windows. What actually happens is that the new firm gets a login to the incumbent’s PSA — so it can see every other client the incumbent has — or it gets nothing and works from a spreadsheet and a shared mailbox.
Then the client decides to move. The incumbent owns the PSA tenant, so the client’s ticket history, asset records, contracts and invoices are inside someone else’s system. Leaving means an export, a migration project, and a year of history that quietly does not come across. Everybody knows this, which is why the conversation about changing providers keeps not happening.
What Solidlio does about it
Each client is its own tenant, with its own account, users and data. An MSP does not contain its clients; it holds a servicing relationship with each one. One relationship is primary — that MSP bills the client, brands its email, and carries its plan. Any number of others are collaborators, with the same reach over the client’s work and none of its revenue.
Every relationship is opened by one side and accepted by the other, and grants nothing until it is. Ending one is a single button on either side, and it moves no data — because the data was never in the MSP’s tenant. A client that leaves every MSP keeps its account exactly as it stands: every organization, ticket, asset, invoice and contract, with the same ids.
Capabilities
| Capability | What it does |
|---|---|
| Multiple servicing MSPs | Any number of MSPs work the same client’s tickets, assets, projects and calendars at the same time. |
| Primary versus collaborator | One MSP bills and brands the client; the rest service it without seeing its revenue or being able to rename it. |
| Two-way engagement | An MSP invites a client by organization id, or a client engages an MSP by partner code. Either way the other side answers. |
| Consent before access | A proposed relationship grants nothing. Only an accepted one appears in any visibility check. |
| Partner codes, no directory | A client can only approach an MSP whose code it was given — there is no list of partners to browse or enumerate. |
| Change your primary | The client promotes any active MSP to primary in one action. The outgoing primary is demoted to collaborator, not cut off. |
| Leave in one action | An MSP leaves a client, or a client removes an MSP, from a single button. Access stops immediately. |
| Go independent | A client ends every relationship at once and keeps its account, its data and its ids. Nothing is exported or migrated. |
| Release a client | The primary MSP hands a client back to independence with its data intact — an exit that does not require a project. |
| Two-sided audit trail | Every invitation, acceptance, refusal, promotion and departure is recorded under both accounts. |
| Notified decisions | The side that has to answer is told, in-app, and taken to the screen where it can. |
Built for MSPs and their clients
The client owns its tenant. The MSP holds a relationship with it. Everything else follows from that.
| Organization | MSP | |
|---|---|---|
| Who owns the data | The account, always — including after every MSP is gone | Nothing; it services accounts it does not own |
| Starting a relationship | Enters an MSP’s partner code, or accepts an invitation | Sends an invitation, or accepts a request |
| Number of MSPs | As many as it wants | As many clients as it wants, primary or collaborating |
| Who bills | Chooses which MSP is primary | Only the primary bills, brands and carries the client’s plan |
| Ending it | Removes one MSP, or leaves all of them, at any time | Leaves a client; if primary, can release it to independence |
| Client identity (name, domain) | Its own | Editable by the primary only |
| Ticket, asset, calendar work | Sees its own | Every servicing MSP sees it, primary or not |
| Revenue figures | Its own | Each MSP sees only what it bills — a collaborator sees none |
How it works
- The MSP shares its partner code. It is shown on the MSP’s Clients page, with a copy button. There is no directory, so the code is the introduction.
- The client sends a request from Settings → Managing MSPs, or the MSP sends an invitation to a client whose organization id it holds. Either way, the relationship is now pending and grants nothing.
- The other side is notified and sees the pending item with accept and decline next to it. The side that opened it can only withdraw.
- On acceptance the relationship goes live. The client appears in the MSP’s client list, marked Co-managed if it is not the primary, and its tickets, assets and schedules are reachable that instant.
- The client decides who is primary. Promoting an active MSP moves billing, email branding and plan fallback to it. The outgoing primary stays on as a collaborator until somebody ends that separately.
- Either side can leave. The MSP leaves the client; the client removes the MSP, or leaves all of them at once. Access stops immediately and no record moves.
Compliance and audit
Every change to who can read a tenant’s data is recorded as an AuditLog entry against AccountManagementLink, and written under both accounts — the client’s and the MSP’s. Neither party depends on the other’s log retention to evidence when access began or ended.
Nine actions are recorded: invitation sent, request sent, accepted, declined, withdrawn, revoked, primary changed, client offboarded, went independent. Each carries the acting person, IP address, user agent, both account ids, and the role in effect.
Reconstructable after the fact: which MSPs could read this account on any given date, who granted each one, who ended it, and when the billing relationship moved.
Editions
Co-management carries no plan gate. Every capability above works on every tier, including Free, and there is no limit on the number of collaborating MSPs.
| Capability | Free | Starter | Growth | Scale | Enterprise |
|---|---|---|---|---|---|
| Multiple servicing MSPs per client | ● | ● | ● | ● | ● |
| Invitations and partner-code requests | ● | ● | ● | ● | ● |
| Primary / collaborator separation | ● | ● | ● | ● | ● |
| Change primary MSP | ● | ● | ● | ● | ● |
| Go independent / release a client | ● | ● | ● | ● | ● |
| Two-sided audit trail | ● | ● | ● | ● | ● |
MSP tiers shown; customer tiers are identical. The only tier interaction is indirect — a managed client’s entitlements can fall back to its primary MSP’s plan, so changing primary changes which plan that is, and going independent removes the fallback.
Changing IT providers should cost a decision, not a migration.