Skip to main content
Settings → Team / Roles Access is granted along three axes — role, module permissions, and branch scope. All three must line up. This guide covers administering them; see Roles and permissions for how they combine.

​
Adding a user

1

Invite the person

Settings → Team → Add. Use their work email — it is their identity and where password resets go.
2

Assign a role

Administrator, manager, or operator. Start at the least privileged role that lets them do their job.
3

Assign branches

Only the branches they work in. Branch scope is a data boundary, not a convenience filter — data outside their branches is never returned to them.
4

Set module permissions

The verbs they need: view, create, edit, delete, and module-specific rights such as approve, allocate, reverse or assign.
5

Confirm what they can see

Have them sign in and check that the modules they need are present and the ones they should not have are absent.

​
Roles

Administrator is not a seniority marker. It grants control over the chart of accounts, service types, settings, feature flags and approval policy — configuration that silently changes what every number on the platform means. Keep the count low.

​
Separation of duties

Some combinations should not sit with one person: Where the team is too small to separate them fully, use approvals so at least the decision is recorded and visible.

​
Changing access

Deactivate rather than delete. A deleted user breaks the attribution on everything they ever did, which undermines the audit trail exactly when you most need it.

​
Sessions

Super Admin → User Sessions → /user-sessions shows active sessions across the platform. Use it to confirm a departed user is no longer signed in anywhere, and to investigate unexpected access.

​
Reviewing access

1

Quarterly: review the user list

Anyone who has not signed in for a quarter probably does not need access.
2

Review administrators specifically

The list should be short and every name should be justifiable.
3

Review branch assignments

Accumulated branches from old roles are the most common over-permission.
4

Review approval delegates

Delegates set for a holiday two years ago are still delegates.

​
Residents and owners

Portal users are not operator accounts. Resident access comes from their resident record and the units they are associated with; owner access from the owner record. Granting a resident an operator role gives them visibility of other people’s data.

​
Common problems