Roles and Permissions

The problem

The person who set up your PSA is not the person still administering it. The technician who left in March is still in a directory group that grants ticket access. A client asked for “just read-only” and got an admin account because that was the only role that let them see invoices. Nobody can say, without opening the database, which of your clients’ users can currently deactivate their own colleagues.

Multi-tenant makes it worse, because there are two organizations in every decision. Your technician outranks the client’s administrator inside the client’s own workspace — which is correct, and which almost every access model gets wrong the first time, because “administrators only” quietly includes every technician you employ.

What Solidlio does about it

The role floor answers “what rank”, the account scope answers “whose data”, and neither is allowed to stand in for the other.

The six-level hierarchy — platform admin, MSP admin, MSP technician, organization admin, power user, customer — is an ordered rank, so most routes express a threshold. Where the honest answer is a list rather than a threshold — “only administrators may rewrite role definitions” — Solidlio uses an explicit role set instead, which is the only way to exclude a technician who outranks the client’s own admin.

Capabilities

Built for MSPs and their clients

Two administrators exist in every managed relationship, and they are not peers. Solidlio makes that explicit rather than approximating it with a shared login.

The structural guarantee: a client organization’s roles are its own — another tenant cannot read them, clone them, rename them, or inherit from them — while the MSP that operates the workspace always outranks the administrator inside it.

How it works

2. Pick a portal. Roles determine the ceiling; the person works at that level or below. Switching re-reads current memberships rather than trusting the old token.
3. Hit a route. The route’s guard is either a rank (“this level and above”) or a named set (“exactly these roles”), and it fails closed on an unrecognised role.
4. Read or write data. The account scope is spread into the query, so a cross-tenant identifier returns nothing rather than another tenant’s row.
5. Administer roles. Administrators create, clone, assign and time-limit named roles from Administration → Roles, and see exactly who holds each one and whether their assignment is active, revoked or expired.

Compliance and audit

• Every assignment is attributable. A role assignment records who assigned it, when, whether it is primary, whether it is active, and when it expires.
• Lifetime is enforced, not decorative. An expired or suspended assignment stops counting immediately, in effective permissions, spend-approval routing and workflow role conditions alike.
• Escalation is bounded in three places. Organization roles, account roles and platform staff ranks each refuse a grant above the granter’s own tier, and an unrecognised caller role grants nothing at all.
• Platform-owned objects are separated from tenant-owned ones. The permission catalogue and the shared system roles can only be changed by Tridacom; a tenant administrator’s reach stops at their own account.

Editions

Role administration is not metered. Every tier includes the full model; tiers differ in how many people you can put in an organization and whether roles can be driven from your directory.

Integrations

• Microsoft Entra ID and Google Workspace — just-in-time provisioning at first SSO login, with an administrator-chosen default organization role.
• SCIM — inbound user and group provisioning. A synced directory group can be mapped to one organization-owned role, and membership reconciles on every directory change.
• Microsoft 365 directory sync — role assignments maintained from the connected tenant.