Roles and permissions (concept)
Every member of an organisation has one of three roles: Owner, Admin, or Member. There’s also a separate Guest membership type for cross-org access. For the precise permissions matrix, see User roles and permissions.
This page explains the philosophy.
Three roles, not thirty
Section titled “Three roles, not thirty”Many enterprise H&S applications have dozens of granular permissions (“can edit hazards but not delete”, “can view actions but not verify”, “can only see Department X”). They sound flexible. In practice they cause more problems than they solve:
- Misconfigurations. With 30 permissions and 5 roles, that’s 150 settings per role. Almost every customer ends up with a role that’s accidentally locked down too much (or too little).
- Onboarding friction. “I can’t do X — can I have permission Y?” becomes a daily IT request.
- Audit confusion. Who can do what? Nobody knows without reading the matrix.
SteadyOn’s three roles are the smallest set that covers real work without those problems.
The intent of each role
Section titled “The intent of each role”The buck stops here. Owners can do everything an admin can plus:
- Delete the organisation.
- Manage billing.
- Transfer ownership to someone else.
There’s typically one owner — the business owner or director. You can have more than one (a sensible practice if your org has co- founders or a deputy who needs full access).
Senior managers, the H&S officer, anyone with substantive authority over the safety programme. Admins can:
- Manage members (invite, remove, change roles up to admin).
- Edit organisation settings (lookups, BRAG thresholds, risk matrix).
- Verify completed actions.
Admins can’t delete the org or transfer ownership.
Member
Section titled “Member”Day-to-day staff. Members can:
- Use Operations: create, edit, and (for their own work) delete hazards, incidents, actions, inspections.
- Manage Capabilities: roles, people, training, enrollments.
- Upload documents.
- Run inspections, complete actions.
Members can’t:
- Verify actions (admin/owner only — see The CAPA workflow).
- Manage members.
- Edit organisation settings.
A separate type of membership rather than a role per se. A guest is a member of an org other than their home org, typically invited in as an external consultant. Guests can use Operations and Capabilities but cannot manage members, billing, or the org itself.
A guest’s role in their home org doesn’t carry over.
Why members can edit
Section titled “Why members can edit”A common surprise: members can edit hazards, incidents, and actions, not just view them. This is intentional.
The premise of SteadyOn is that frontline workers and first-line supervisors should be the primary users. They’re the ones who actually identify hazards in real workplaces; they’re the ones who witness incidents; they should be able to capture both quickly without asking a manager to type their report for them.
Restricting members to view-only would mean either (a) every entry goes through an admin, which doesn’t scale, or (b) most workers become admins, which defeats the purpose of having a member tier.
The control point isn’t on creation; it’s on verification. Anyone can mark an action Completed; only an admin or owner can mark it Verified. That’s where the gatekeeping belongs.
Why we don’t have project-level roles
Section titled “Why we don’t have project-level roles”Some apps let you scope permissions per “project”. SteadyOn doesn’t have projects — there’s nothing between the org and the data. A user is or isn’t a member of an org; if they are, they see all sites, all hazards, all incidents.
If your business needs strict separation of data by site, run two organisations. They’re free; users can belong to multiple. (See Multi-organisation membership.)