Permission sets and access rules
Who can see and do what: named permission sets from a fine-grained catalogue, plus rules that gate features.
5 min read · Last reviewed 18 Aug 2026
How permissions work here
Every capability is a fine-grained key (view inspections, manage assets, record readings), bundled into named permission sets.
A person holds one set. Administrator, Manager and Standard exist out of the box; build your own beside them.
The server enforces every check. The interface hides what you cannot do as a courtesy; the refusal happens where it cannot be skipped.
Build a custom set
- 1
Open Settings → Permissions and create a set, say “Site supervisor”. Assign them to their site and the set’s rights apply there only.
- 2
Tick the keys the role needs, module by module: everything in observations and actions, view-only on assets, nothing in settings.
- 3
Assign it to people from their user pages. Changing the set later changes it for everyone holding it.
Tip: Name sets after roles, not people. “Sarah’s permissions” stops making sense the day Sarah changes jobs.
Access rules and the safety rails
Access rules gate specific features: an inspection template only for one group, one site, or people matching a user-field condition.
Someone with no sites assigned sees every site, as do administrators and anyone whose permission set includes “See every site’s records” (Managers have it by default).
The last-administrator guard refuses any change that would leave the workspace without an administrator.
Deactivation is immediate: a deactivated person’s access ends now, not at their next sign-in.