admin, hr, employee, …), which routes each role can open, and how that ties to require_admin and simulation APIs, read Roles and product surfaces first.
Roles at a glance (product language)
| Role | What they usually do |
|---|---|
Learner (employee, executive, …) | Chat, tasks, personal dashboard—inside their org. |
HR (hr) | Org people workflows (for example user provisioning); not the simulation admin API behind require_admin. |
Org admin (admin) | Simulation settings, /org-admin org view, /api/v1/admin/simulation/*. |
Super admin (super_admin) | Cross-org platform tools and elevated endpoints. |
How enforcement works
The backend authorizes every sensitive call: FastAPI dependencies (require_admin, require_roles, require_super_admin, and so on). The UI may hide controls for clarity, but authorization must succeed on the server.
Example matrix (simplified)
| Area | Learner | HR | Org admin (admin) | Super admin |
|---|---|---|---|---|
| Read simulation settings (own org) | ✓ | Where API allows | ✓ | ✓ |
| Write simulation settings / simulation admin API | — | — | ✓ | ✓ (scoped by policy) |
| Cross-org analytics | — | — | — | ✓ |