MSP Multi-Tenancy and Co-Management

What it is

Co-management lets more than one MSP service the same client account at the same time, and lets that client change or drop its MSPs without moving any data. One MSP is the primary — it bills and brands the client — and any number of others can be collaborators, who service the same tickets, assets and schedules without taking the revenue.

Every relationship is opened by one side and accepted by the other. Nothing grants access until both have agreed.

Concepts

Only ACTIVE links grant anything. PENDING and REVOKED grant nothing anywhere in the product.

Primary versus collaborator

The distinction is not a permission level — it is a different relationship.

Roles and permissions

power user and CUSTOMER cannot reach any of the client-side routes. This is deliberate — every one of them changes who can read the tenant’s data.

Walkthrough — a client engages an MSP

Use this when the account already exists (it signed up on its own, or a previous MSP released it) and wants an IT partner.

1. The MSP reads its partner code. MSP portal → Clients. The code is shown at the top of the Client co-management requests panel, with a Copy button. It is the MSP account’s slug.
2. The MSP gives the code to the client — email, onboarding pack, whatever. There is no directory to look it up in, which is what stops anyone opening a relationship with an account they were not invited to approach.
3. The client sends the request. Org portal → Settings → Managing MSPs → Invite an MSP. Paste the code and press Send request. Case and surrounding whitespace do not matter.
4. The request is now pending. It appears under Requests you sent with a Withdraw button. The MSP has no access to anything yet.
5. The MSP’s admins get a notification and the request appears in MSP portal → Clients → Client co-management requests.
6. The MSP accepts. The client becomes an ACTIVE collaborator relationship: it appears in the MSP’s client list, and its tickets, assets and schedules are reachable immediately.

Accepting does not make the MSP primary. Billing and branding are the client’s separate decision — see §7.

Walkthrough — an MSP invites an existing client

Use this when the MSP has the client’s organization id (for example, the client gave it, or an outgoing MSP handed it over).

2. The invitation is created PENDING and appears under Clients → Pending co-management invitations, with a Withdraw button.
3. The client’s admins are notified, and see it at Settings → Managing MSPs → Pending invitations, with Accept and Decline.
4. On accept, the MSP becomes an ACTIVE collaborator.

An MSP cannot accept its own invitation, and a client cannot accept its own request. Each PENDING link is answerable only by the other side.

A client an MSP provisions (MSP portal → Clients → Onboard Client) skips all of this: the MSP created the account, so it gets a PRIMARY, ACTIVE link immediately with no consent step.

Walkthrough — adding a second MSP

There is nothing extra to do. A client that already has a primary MSP follows §4 or §5 with the second MSP’s partner code. Both relationships are then ACTIVE:

• the primary keeps billing, branding and identity control;
• the new MSP is a collaborator and sees the client in its own portal;
• the client’s Managing MSPs page lists both, labelled Primary and Collaborator.

The primary can see the collaborator on the client detail page’s MSPs tab, but cannot remove it — only the collaborator itself, or the client, can end that relationship.

Walkthrough — changing your primary MSP

Org portal → Settings → Managing MSPs.

1. The MSP you want to promote must already be Active. Press Make primary on its row.
2. Its link becomes PRIMARY, and your account’s primary manager changes to it. Billing, email branding and entitlement fallback move with it.
3. The outgoing primary is demoted, not evicted. It keeps servicing you as a collaborator until you remove it or it leaves. Remove it separately if that is what you want.

The target must be an MSP partner account. Promoting an account that is not one is refused with “That account is not an MSP partner and cannot be your primary”.

Walkthrough — leaving, and being released

Three separate actions, from three different places.

A client removes one MSP. Org portal → Settings → Managing MSPs → Remove on that row. If it was the primary, your account is left with no primary.

A client leaves every MSP. Same page → Become independent. Confirms, then revokes every link and clears the primary. Your account keeps every organization, ticket, asset, invoice and contract — nothing moves, because the account was always yours.

An MSP leaves a client. MSP portal → Clients → the client → MSPs tab → Leave client on your own row. Only your own link ends.

A primary MSP releases a client. Same tab → Release to independent. This ends every MSP relationship on that client, not just yours, and the client becomes independent with its data intact. Only the primary can do this; a collaborator gets “Only the primary MSP can offboard a client”.

Going independent leaves the account with no MSP tier to fall back on. If its entitlements were being carried by its primary MSP’s plan, they revert to its own.

What a collaborator can and cannot do

A collaborator has the same servicing reach as the primary:

• the client appears in Clients, and the client detail page opens;
• the client is counted in the MSP dashboard’s client tiles;
• its tickets are listable, readable, creatable, assignable and commentable;
• its assets appear in the asset list and in the asset summary tiles;
• its calendar events appear in the MSP calendar;
• its people are selectable as requesters and assignees;
• its queues, SLA policies and routing rules apply as the primary’s do.

It does not get:

• MRR. The client’s recurring revenue reads 0 for a collaborator, in the client list, the client detail page and the dashboard revenue tile. That figure belongs to whoever bills the client.
• The Edit Client button is not rendered for a collaborator.
• Portal invitations. Inviting a client contact into the client’s own organization is primary-only and answers 403.
• Offboarding. Primary-only, 403.

The client detail page shows “Co-managed — another MSP bills and brands this client” in its header, and the client list marks the row Co-managed.

Notifications

Sent in-app to the administrators who can actually act on them — a client-side event goes to the client’s organization administrators (and any MSP/platform admins on that account), an MSP-side event to the MSP’s MSP administrators.

Withdrawing your own pending item notifies nobody — there was no decision for anyone else to make.

Delivery is fire-and-forget.

Audit trail

Every transition writes an AuditLog row with entityType = "AccountManagementLink", visible at Settings → Audit.

Both sides get a row. The client’s trail and the MSP’s trail each record the event under their own accountId, so neither party depends on the other’s log retention to evidence when access started or ended.

An audit write that fails is logged and swallowed — it never rolls back a consent decision the user has already been shown as complete.

Plan tiers

Co-management carries no plan gate. Every capability in this guide works on every tier, including Free, for MSP and customer plans alike. There is no limit on the number of collaborating MSPs on an account.

The one tier interaction is indirect: a managed client’s entitlements can fall back to its primary MSP’s tier. Changing primary changes which tier that is; going independent removes the fallback.

Troubleshooting

Limits and known behaviour

• A collaborator’s reach is not scoped. An ACTIVE link grants the same servicing visibility across the whole client as the primary has. There is no way to limit a collaborator to specific organizations, queues or asset types.
• Exactly one primary. Account.managedByAccountId is a single FK. An account has one primary or none.
• Removing your primary leaves you with none. Revoking the primary’s link clears the FK; it does not promote a collaborator. Promote one explicitly.
• No partner directory. A client can only reach an MSP whose partner code it has been given, and an MSP can only invite a client whose organization id it has. This is what keeps either side from approaching accounts it was never introduced to.
• The history survives in the link rows and in the audit trail, but no UI renders it.
• invitedByPersonId is recorded but not displayed. It is stored on every invite and request for audit; no screen shows who sent it.
• Escalations with several MSPs and no primary go to the platform. A client’s “get MSP help” escalation is addressed to its primary, or to a single active link if that is the only one. With several collaborators and no primary there is no basis for choosing, so the platform triages it rather than the wrong MSP receiving it.
• Client-side billing surfaces are per-MSP. Credit accounts and similar are scoped to the MSP that created them, so each servicing MSP sees its own, not the primary’s.
• Notifications are in-app only. There is no email for co-management events.
• Independence does not archive anything. Going independent revokes links and clears the primary. Data, users, tickets and invoices are untouched.