Members, teams and access
Access in the MSP Portal is layered. A person's role at the partner sets the most they can ever do inside a client. Teams decide which clients they can reach at all. Per-client module access can narrow a team further. And none of it takes effect inside a client until the person opens a delegated session, which is where all three layers are applied.
Members
Members (under Settings) lists everyone at your partner with their role, status and join date. Administrators invite people, change roles and deactivate accounts.
Invite Member sends an email invitation with a role and, optionally, a team to join on acceptance (as a member or a lead). The invitation grants nothing until the person accepts it. Pending invitations are listed with their expiry; an administrator can resend one, copy a fresh link to hand over directly (which retires the emailed link), or revoke it.
This is for people at your firm. To give someone access to a single client organization instead, open that client under Clients and invite them there; they become a member of that organization, not of your partner.
A role is changed inline in the members table. You cannot change your own role, and you cannot deactivate yourself. Deactivate removes a person's portal access and ends any delegated session they have open.
Roles
| Role | What it allows inside a client |
|---|---|
| MSP Admin, Operations Admin | Everything: read, create, update, delete. Administrators also manage the partner itself (members, teams, packages, templates, branding, SLA policies) and can open any client without a team assignment. |
| Compliance Manager, vCISO | Read, create and update. |
| Compliance Analyst, Billing Manager, Integration Admin | Read, create and update. |
| Auditor, Executive (Read-Only) | Read only. |
Two rules apply on top of the role. A session opened as read-only is read-only whatever the role. And every role except the two administrator roles must be assigned to a client through a team before it can open a session there; an unassigned operator is refused with the reason stated.
Teams
Teams (Settings, administrators only) groups staff and scopes them to clients. Create a team with a name, then Manage it:
- Members: add staff from the partner's active members; remove them again. Leads are set when someone is invited to the team, not here.
- Clients and module access: assign a client to the team, which is what lets the team's non-administrator members open sessions in that client. Unassign to take it away.
A team is archived rather than deleted; its history stays.
Module access per client
For each client a team is assigned to, Module access sets what that team may touch in that client, module by module: no access, read, write, or admin. Write covers read, create and update; admin adds delete.
The rule is stated on the dialog itself: leave every module at No access and the team's session scope governs, with no narrowing. Set any grant at all and the team is restricted to the granted modules in that client. A person on several teams gets the highest level any of their teams holds for each module. Changes apply immediately, including to sessions already open.
The same dialog is reachable from a client's Teams tab, which lists the teams assigned to that client.
The partner itself
Profile shows the partner's display name, slug, status, legal name, billing entity, currency, your role, and member and client counts. Administrators can edit the names; the currency is fixed once the partner is created.
Partners are created by SolveGRC, not self-served: Designate MSP Partner is a platform action, and the person who runs it becomes the partner's first MSP Admin. If you work for more than one partner (a contract vCISO, say), the partner name at the top of the sidebar becomes a switcher, and switching re-resolves every page against the partner you picked.