Roles and Permissions

Last verified against the codebase: 2026-07-27. Where a capability exists but is not enforced, this guide says so rather than implying it is.

What it is

Every request into Solidlio is decided by three things: which portal the caller is in, what organization role they hold, and which tenant the data belongs to.

On top of that, each organization keeps a directory of named roles — Technician, Dispatcher, Accountant, and any you create — which decide who gets routed work, who is asked to approve spend, and who gets notified.

The three role vocabularies

Solidlio has three separate sets of role names. They are not interchangeable, and knowing which one you are looking at removes most of the confusion in this area.

Platform staff carry a fourth, narrower set — see section 12.

The single most useful thing to remember: the organization role is the one that grants or refuses access. A person with the job-function role “Administrator” and the organization role CUSTOMER is a customer.

The organization-role hierarchy is ordered, and the order surprises people

platform administrator > MSP administrator > MSP technician > organization administrator > power user > CUSTOMER

MSP technician outranks organization administrator. That is correct — a technician at the managed service provider is operating above the client’s own administrator — but it means “administrators only” cannot be written as “organization administrator and above”, because that phrase includes every technician. Solidlio therefore has two guard shapes:

Role administration uses the set (platform administrator, MSP administrator, organization administrator). Everything else in this area uses the rank.

How an authorization decision is made

Four checks run, in this order. All four must pass.

1. A downstream service never re-reads the token.
2. Portal. requirePortal(...) refuses a caller whose active portal is not one of the named ones. Which portals a person may activate is derived from their roles, not chosen freely — see section 5.
3. Role floor. requireMinRole (rank) or requireAnyRole (set) on the route. There are 662 role-floor call sites across the services: 531 at organization administrator, 58 at MSP administrator, 39 at MSP technician, 24 at platform administrator, and one each at power user and CUSTOMER.
4. Tenant scope. accountScope(req) is spread into the database query so the row set is confined to the caller’s account. Platform admins are unscoped; customer-portal callers are pinned to their single organization; everyone else sees any organization inside their account. A caller with no trusted account context matches nothing.

Steps 3 and 4 answer different questions and neither substitutes for the other. The role floor answers what rank is the caller; the tenant scope answers whose data is this. A route with only a tenant check will happily let a customer edit their own organization’s administrators.

Permission matrix

Notes on specific cells:

• MSP technician can read roles but not write them. The read floor is a rank (a technician servicing a client needs to see who is who); the write floor is a set that names the three administrator roles. This matches what the web portals show — the MSP role screen offers create/edit/clone/delete only to MSP administrator, the org role screen only to organization administrator.
• “List people in the tenant” is open to every authenticated role because the people-picker on a ticket needs it. The result is still bounded by accountScope, and a customer-portal caller sees only their own organization.
• The last row applies to everyone including platform admins: a caller may assign a membership role at or below their own tier and no higher. An unknown or missing caller role ranks below CUSTOMER and can assign nothing at all.

Portals

A person’s organization roles determine the highest portal they may activate; they may then work at that level or any level below it.

Switching portals re-mints the token from the person’s current memberships rather than trusting the presented token’s claim, so a role that was removed cannot be carried forward through a portal switch.

Walkthrough — giving someone administrator rights

Administrator rights are the organization role, not a job-function role.

1. Go to Users in the sidebar (/org/users).
2. Open the person and select the Permissions tab.
3. Under Access level, pick the new role and click Change.

The dropdown offers only roles you may actually grant. The change takes effect the next time that person’s access token is minted — at their next refresh or portal switch — because the role travels in the token. Revoke their sessions if it must apply immediately.

Four refusals apply, and the control hides or disables itself for the first three rather than letting you hit them:

To set the role at creation time instead, use Users → New user, which carries the same ceiling. The creation form does not accept platform administrator at all.

Change an MSP staff member’s access level from the organization portal, or through the API below.

Walkthrough — creating a custom role

A custom role is a named job function owned by one organization.

1. Go to Administration → Roles in the sidebar (/org/settings/roles, or /msp/settings/roles).
2. Click Create Role.
3. Enter a display name (“Field Engineer”). The machine name is derived automatically and must be uppercase letters and underscores only — A–Z and _, nothing else.
4. Optionally add a description.
5. Click Create.

The role is created against your current organization, is never a system role, and cannot itself be cloned.

To see who holds a role, click View Users on its card. The list shows each holder, whether the assignment is their primary one, and whether it is active, revoked, or time-limited.

Walkthrough — cloning a system role

Cloning copies a shipped role and its permission set into your organization so you can adjust it without touching the shared original.

1. Go to Administration → Roles.
2. Find a role marked System — those with a Clone button are cloneable.
3. Click Clone, give the copy a display name and machine name, and confirm.

The copy is independent. It records where it came from, but it does not inherit from it: later edits to the original do not reach the copy, and you can remove a permission from the copy that the original grants. (Until this release the clone was wired as a live subclass of its source, which meant a permission could never actually be removed from the copy — it fell back to the inherited one every time.)

You can only clone a role your account owns or a platform-wide system role. Another tenant’s role returns “Role not found”.

Job-function roles and what they drive

Thirteen system roles ship with the platform. They are shared by every tenant, carry a permission set, and are read by real product behaviour.

TECHNICIAN is the default role applied to new people.

What holding one of these actually does today:

What it does not do: the individual permission rows attached to a role (ticket:update, invoice:void, and 721 others) are not evaluated when a request is authorized. See Limits — this is the single most important caveat in this document.

Time-limiting and revoking an assignment

Every job-function assignment carries two lifetime controls:

Both are honoured everywhere an assignment is resolved: effective permissions, spend-approval routing, ticket-workflow role conditions, asset-expiry and contract-renewal notification targeting, the RBAC resolver’s user context, and organization-membership resolution. An expired assignment is still listed on the role’s View Users panel, marked Expired, so you can see and clean up what lapsed.

Directory-driven roles (SSO and SCIM)

A directory group may only be mapped to a role the organization owns — never a system or platform staff role.

Platform staff roles

Tridacom’s own staff carry a fifth vocabulary, separate from tenants entirely, managed at /platform/staff.

A staff member cannot invite or promote anyone to a rank above their own. The caller’s own rank is resolved from their real assignment rows, not from their token — the token only carries the coarse platform administrator organization role needed for login. A caller with no staff assignment row is treated as platform administrator, the least-privileged rank the platform portal admits.

Account roles

The billing account has its own three-level role, used only for account administration.

An ADMIN cannot mint an OWNER. The last remaining OWNER cannot be demoted.

Plan tiers

Roles and permissions are not plan-gated. Every tier gets the full role administration surface, custom roles, cloning and assignment. What each tier limits is the number of people you can have.

Single sign-on, which is how most organizations drive roles from a directory, is Enterprise-only on both tracks.

Troubleshooting

Limits and known behaviour

Attached permissions are descriptive, not enforced. This is the important one. The catalogue holds 723 permissions across 55 resources, and the 13 system roles carry 635 grants between them — but no service consults those rows when deciding a request. Authorization is the four-step check in section 3: portal, organization role, route floor, tenant scope. Adding invoice:void to a custom role does not let its holders void invoices, and removing it does not stop them. Treat a role’s permission set as documentation of the job function, and use the organization role to control access. The API now refuses to let a non-platform-admin attach platform-administration permissions, so the catalogue cannot become an escalation path if enforcement is later wired up.

Custom roles are created with no permissions. Nothing in the web UI sets permissionIds, so a role created through the portal starts empty. Cloning is the only way to get a populated permission set. Given the point above, this affects the role’s description, not what its holders can do.

Per-assignment restrictions cannot be saved. TICKET_PRIORITY, TICKET_CATEGORY, ASSET_TYPE and REQUIRES_APPROVAL restrictions are modelled and were once persistable, but no service reads them. The API rejects a non-empty restriction list rather than confirm a control it would not apply. Clearing to [] is still accepted so old rows can be removed.

Role changes do not invalidate a live token. The organization role is a token claim, so a demotion takes effect at the next token mint (refresh, portal switch, or re-login). Revoke the person’s sessions if the change must be immediate.

A route that acts on a different organization taken from the URL or body must also constrain its query with accountScope — the role floor alone would let someone privileged in their own organization act on another.

The resolver caches for five minutes, per process. A role’s resolved permission set is memoised in-process for 5 minutes. Editing a role or its permissions clears that cache in the service that handled the edit; other service instances pick the change up when their entry lapses.

The membership role they may set is still capped at their own tier.

Global roles need a platform admin. Only platform administrator can edit or delete a role with no owning organization, including renaming the shared system roles.