Roles and permissions
Roles
| Role | Scope | Can |
|---|---|---|
| Resident | The communities they belong to | Everything in the resident guide their community has switched on |
| Community admin | The communities they administer | Everything in the admin guide for those communities |
| Super admin | The platform | Everything, plus platform administration |
| Supervisor | A work group | Receive and manage assigned work |
| Employee | A work group | Receive assigned work |
| Contractor | A work group, or the RFP Portal | Receive assigned work, or bid on RFPs |
Delegated permissions
An ordinary member can be granted one specific power without becoming an admin:
| Permission | Grants |
|---|---|
| RFP Creator | Create and manage RFPs |
| Announcement Poster | Post and manage announcements |
Granted in Community Settings > Permissions.
Scoping
Everything is scoped to the community selected in the header. An account can belong to several communities, and administer some of those and not others.
A super admin passes every role check, which is why the role is held by as few people as possible.
Resident-admins
Most community admins also live in the community they administer. Promoting a resident adds admin rights without removing their membership, so they keep real dues, real tickets and real ballots.
They see both navigation sets. View as resident hides the admin side, and stays
usable while it is on so they can get back.
An admin who is not a resident of the community sees only the admin side, plus the community board, since the board is for them too.
What admins cannot do
- Change their community's entity type.
- Switch their own entitlements on.
- Raise their own member limit.
- Set or clear a family member's sharing opt-out.
- Tick a derived checklist item on a resident's behalf.
- Read a masked identity field without it being logged.
- Delete a payment audit entry or a screening audit entry. The backend has no permission to, by design.