Roles & Permissions
NestFleet uses role-based access control (RBAC) with six built-in roles. Each role is designed for a specific function within the product operations workflow. Users can hold multiple roles simultaneously.
Built-in roles
| Role | Purpose |
|---|---|
| Admin | Full system access. Manages users, roles, products, and system settings. The only role that can assign or remove roles for other users. |
| Operator | Day-to-day case management. Can triage, assign, close, and add notes to cases. Can create change requests from cases. |
| Support Lead | Everything an Operator can do, plus: approve or reject auto-replies, escalate cases, and receive escalation notifications. |
| Change Lead | Approves or rejects change requests. Reviews AI-generated PR drafts and risk assessments. Cannot manage users or system settings. |
| Product Lead | Read access to all cases, change requests, and knowledge base for their product. Can view analytics. Cannot modify cases or approve CRs. |
| Knowledge Lead | Manages the knowledge base. Can create, edit, and delete articles and known issues. Reviews and accepts or rejects auto-update proposals. |
Permission matrix
The table below shows which roles can perform each action. A checkmark means the role has permission; a dash means it does not.
| Action | Admin | Operator | Support Lead | Change Lead | Product Lead | Knowledge Lead |
|---|---|---|---|---|---|---|
| Manage users & roles | ✓ | — | — | — | — | — |
| Manage products | ✓ | — | — | — | — | — |
| Manage system settings | ✓ | — | — | — | — | — |
| View all cases | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Triage & assign cases | ✓ | ✓ | ✓ | — | — | — |
| Close cases | ✓ | ✓ | ✓ | — | — | — |
| Add case notes | ✓ | ✓ | ✓ | — | — | — |
| Escalate cases | ✓ | ✓ | ✓ | — | — | — |
| Approve / reject auto-replies | ✓ | — | ✓ | — | — | — |
| Create change requests | ✓ | ✓ | ✓ | — | — | — |
| Approve / reject change requests | ✓ | — | — | ✓ | — | — |
| Manage knowledge base articles | ✓ | — | — | — | — | ✓ |
| Review KB update proposals | ✓ | — | — | — | — | ✓ |
| View analytics | ✓ | — | ✓ | — | ✓ | — |
| View audit log | ✓ | — | — | — | — | — |
Role assignment
Only users with the Admin role can assign or remove roles. To manage a user's roles:
- Navigate to Settings → Team Members
- Click on the user you want to modify
- Select or deselect roles from the role picker
- Click Save — changes take effect immediately on the user's next API request
Multiple roles
A user can hold multiple roles simultaneously, and their permissions are the union of all their assigned roles. For example, a user with both Support Lead and Knowledge Lead can both approve auto-replies and manage the knowledge base.
Common combinations in small teams:
- Operator + Knowledge Lead — a support engineer who also manages documentation
- Support Lead + Change Lead — a senior engineer handling both approvals
- Admin + Operator — the system owner who also handles day-to-day cases
Self-lockout protection
An admin cannot remove their own Admin role. If you attempt to do so, the API returns a validation error. This prevents accidentally locking yourself (and your team) out of the system. To transfer admin access, first grant the Admin role to another user, then ask them to remove it from your account.
The system also enforces that at least one active user with the Admin role always exists. Attempting to delete the last admin account is blocked at the API level.
Inviting new users
Admins can invite new team members from Settings → Team Members → Invite. An invitation email is sent with a one-time signup link. When REGISTRATION_ENABLED=false (the default for self-hosted), this invitation mechanism is the only way new users can join. The invited user's role is assigned at invitation time.