Permissions

Apollo’s three-tier permission model — Organization, Team, and Board levels.

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 in organization_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 in team_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 in user_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 on auth.uid().