Roles & Permissions
The system uses a two-tier permission model (V1 tenant permission system): base authorization (tenant roles, recognized automatically at login) + project-level authorization (project roles, granted per project; see L4 Delivery Center · Project-level Authorization).
Base Authorization — Three Tenant Roles
| Role | Type | Visibility | Core permissions |
|---|---|---|---|
| Owner | Tenant user | All tenant features | Ownership-level: member role change/removal, subscription orders and upgrades; cannot be removed or have role changed |
| Admin | Tenant user | All tenant features (incl. Platform Management menu) | Management-level: invite members (admin/member), approve decisions, view member emails in plain text; cannot change roles/remove members/place orders |
| Member | Tenant user | Standard features (no Platform Management menu) | Standard operations: self-managed personal message channels, tiered survey answering, masked member emails |
| Platform Admin | Platform user | Admin-only menu | Manage all tenants/users/LLM/branding/invite codes/plans/payments |
Project-level Authorization — Six Project Roles
Operations inside a project are authorized by project roles, independent of tenant roles (granted per project):
| Project role | Description |
|---|---|
| owner | Project owner (member management; only this role can manage project members) |
| pm | Project manager (project-level write operations) |
| contributor / reviewer / approver / viewer | Contributor / Reviewer / Approver / Read-only |
Post-login Redirection
The system detects the account type automatically after login:
- Platform admin →
/admin/dashboard - Tenant user →
/workspace
Three Lines of Defense
🔒 Menu/button hiding (first) → route guards intercept direct URLs (second, unauthorized access shows the "No Access" page) → backend require_role/require_permission 403 final ruling (third).
Frontend hiding is not authorization — all permissions are enforced by the backend.
ON THIS PAGE