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 August 2026

How permissions work here

  • Every capability is a fine-grained key — view inspections, manage permits, record fire checks — 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. 1

    Open Settings → Permissions and create a set — say, “Site supervisor”.

  2. 2

    Tick the keys the role needs, module by module: everything in observations and actions, view-only on risk assessments, nothing in settings.

  3. 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.

  • 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.

About this moduleSites & teamsYour estate as a hierarchy, your people in groups, permissions that say who can do what — the backbone everything scopes to.