Roles and portals
Who sees what, and why the boundaries are where they are.
There are separate places to sign in, and within the staff dashboard there are separate roles. The two do different jobs and are worth telling apart.
Portals: different doors
Each audience has its own portal, showing only what that audience needs — see who uses it for the map.
Portals are separated for privacy, not convenience. Three boundaries generate most of the questions people ask:
- Owners see occupancy and money for their own buildings — never resident contact details.
- Residents see their own tenancy only — never the building's other residents, and never anyone else's charges.
- Contractors get one job through one link, and no account at all. See The maintenance model for what that link exposes, because it is more than the job.
Roles: narrowing one door
A role does not send an account somewhere else. It narrows what that account can reach inside the dashboard, and sends it home when it tries to go further.
| Role | Reaches |
|---|---|
| Admin | The dashboard. |
| Housekeeper | Their own cleaning events, timesheets and paid holiday, and the resident list. Every other page sends them home, and every other action — money, settings, other people's records — is refused, not just hidden. |
| Platform | Everything, across workspaces. |
Each role has its own home, so being redirected is not an error page — a housekeeper who follows a link to a money screen lands back on housekeeping.
The platform role bypasses every role gate, by design. It is not "admin plus a bit"; it is an account no ordinary restriction applies to. Any restriction that must hold even for platform staff has to be written as its own explicit check — relying on the normal role gate will not stop it.
Workspace scope
Every account belongs to a workspace, and that is the boundary that matters most: what an account can see is scoped to its workspace before any role is considered. An account with no workspace is platform-level.
This is not a filter applied to queries after the fact. It is applied underneath them, which is why there is no combination of role and URL that shows one workspace another workspace's data.
Signing in as someone else
Staff with the right permission can act as another account to reproduce what a user is seeing. Sessions started this way are marked as impersonation throughout — the dashboard says so while it is happening, and actions taken are attributable.
Use it to diagnose, and be aware that anything you do lands as that user's action on their records.
The practical version
If someone reports "I cannot see X":
- Which portal are they in? A resident asking about another resident is working as designed.
- Which role? A housekeeper cannot reach or use money pages; a link to one sends them back to housekeeping rather than showing an error.
- Which workspace? Scope is checked before role.
See also Getting started and the Settings chapter, where accounts and roles are managed.