Appearance
Roles & Permissions
Purpose: Who can do what across the platform. Access is role-based and, in places, scoped to individual buildings, so this page explains the model rather than listing every single permission.
Primary users: Administrators managing access; anyone working out why a user can or can't see something.
The role model
Roles come in a fixed, system-defined set. The same role can mean slightly different things in different apps, and each app only allows a subset of roles.
| Role | Roughly who |
|---|---|
| Super Admin | Full access to everything |
| Admin | Broad administrative access |
| System User | Central/back-office access |
| Property Manager | Manages properties and their lettings |
| Lease Officer | Works deal sheets and lettings for their building(s) |
| Concierge | On-site access, e.g. smart-lock and visitor management |
| API Admin / API User | Machine access for integrations (Everest API) |
Which roles apply where
| App | Roles it uses |
|---|---|
| Olympus (central / backend) | Super Admin, Admin, System User |
| Portal | Super Admin, Admin, Property Manager, Lease Officer, Concierge |
| Everest | Super Admin, Admin, Property Manager, API Admin, API User |
Building-scoped roles & permissions
Access can be narrowed to specific buildings. Rather than one flat "Lease Officer" role, Portal seeds building-specific variants (for example "Lease Officer The Wullcomb"), and permissions can be scoped per building (an internal properties.property.<building> permission). A user's effective abilities are their role's permissions plus their per-building permissions, so two people with the same role can see different buildings.
Key rules worth knowing
- Super Admin is all-access. It's granted every permission and is also short-circuited in the access checks, so it bypasses the per-feature rules.
- You can't act on your own account in Portal (you can't delete yourself, and only a Super Admin can change another Super Admin). This self-action rule is stricter in Portal than in the other apps.
- "Has Admin Access" is granted to every role, so any signed-in staff user reaches the admin area; what they can do there is then gated by their specific permissions.
- API roles (Everest) are for integrations only, gated on API-access permissions and rate-limited.
- Permissions are per operator. Roles and permissions are scoped to the operator (tenant), so they're evaluated within that building's data, not across operators.
Per-app permission themes
The full permission catalogue lives in code (Everest defines its own in config; Portal and the backend seed theirs). Broadly:
- Everest (~33 permissions): manage users/roles and the reference data (owners, agents, furniture packs, perks, unit/property types), a full create/edit/delete/restore set for properties and units, "synchronise units to platforms", bulk upload, and the API-access permissions.
- Portal: manage deal sheets, the Qube actions (submit, view/raise charges, raise transactions, notes), media, Inventory Hive access, smart-lock actions (access, create/revoke/freeze/extend key), tenant references, and per-building
Manage <building>/Concierge (<building>)permissions. - Backend: the per-building manage/concierge permissions that back the above, plus the platform-wide user/role/company/integration/report permissions.