Overview
Apollo uses a three-tier permission model that provides granular access control from the organization level down to individual project boards.Permission Tiers
Tier 1: Organization
Managed inorganization_members. Controls organization-wide access.
| Role | Permissions |
|---|---|
| Owner | Full control — billing, settings, member management, all features |
| Admin | Manage members, teams, and most settings. Cannot delete org or manage billing |
| Member | Access features based on team and board roles. Cannot manage org settings |
| External Collaborator | Limited access to specifically assigned projects only |
Tier 2: Team
Managed inteam_members. Controls team-scoped resources.
| Role | Permissions |
|---|---|
| Lead | Manage team settings, members, feature config, and project assignments |
| Member | Access team projects, tasks, releases, and knowledge base |
Tier 3: Board (Project)
Managed inuser_project_access.board_role. Controls per-project access.
| Role | Permissions |
|---|---|
| Owner | Full project control — settings, members, delete |
| Editor | Create and modify tasks, releases, and KB pages |
| Viewer | Read-only access to project resources |
User Types
Derived from organization role:| User Type | Derived From | Sees |
|---|---|---|
| Internal | Owner, Admin, or Member org role | Full platform based on feature access |
| Customer | Customer user type | Simplified dashboard, assigned projects |
| External Collaborator | External Collaborator org role | Only specifically assigned projects |
Route Guards
Apollo enforces permissions at multiple levels:<ProtectedRoute>— requires authentication (any logged-in user)<FeatureRoute feature="...">— requires the named feature to be enabled for the user<InternalRoute>— requires internal user type<AdminRoute>— requires admin or owner org role
Row-Level Security (RLS)
All database tables have Row-Level Security policies enforced at the PostgreSQL level. Even if the frontend were bypassed, the database enforces access rules based onauth.uid().