How permissions and widget visibility work

The short version

Four layers decide whether someone can reach a module or see a widget, resolved in this order — the last one that applies wins. This is exactly what the app itself enforces, not an approximation of it: the "What can they actually do" table on a worker's own Permissions tab (System Permissions) walks through these same four steps for every module, so if a row there says No access, it's for one of these four reasons.

1. Position — the default for their job (e.g. "Site Supervisor", "Safety Coordinator"). Changing it affects everyone with that position.
2. Admin tier — extra access granted company-wide to every worker with Admin Level set to "Admin". This only ever adds; it can never take access away from what the position already gives someone.
3. Individual override — one person set to something different from their position and admin tier, on their own profile. This is the final word for that one person and can raise or lower their access.
4. Company-wide visibility — a hard on/off switch, checked last and overriding everything above. If a module or widget is switched off here, nobody below Super Admin can see it, no matter what their position, admin tier or individual override say.

A Super Admin always sees everything the company's plan includes. No layer above can restrict a Super Admin — that's true at the position level, the admin-tier level, individually, and company-wide.

What View, Edit and Delete actually let someone do

The four layers above decide whether someone can reach a module at all. Once they can, there's a second question: what can they do there. Every module resolves to one of four levels — None, View, Edit or Delete — each one including everything before it.

This is a real, enforced distinction, not just what the screen happens to show — the same check runs on the server whichever way a record was reached, so a bookmarked link or a second click can't get further than what someone's actual level allows. Picking Edit for a position lets its workers add and change things in that module; picking Delete on top of that is what actually surfaces a Delete control and lets it work. A person sitting on the outside can't remove something in that module by finding another way in — that door was never open.

Where to change each layer

• Position: open a position under Org Structure → Positions, and use its General Permissions / Additional Permissions tabs.
• Admin tier: Org Structure → Admin Tier. This is the bluntest of the four controls — anything switched on here applies to every current and future Admin-tier worker in the company at once, without picking anyone. If only one or two people need something, prefer setting it on their position or as an individual override instead; both are easier to audit later than a company-wide grant nobody remembers making. The "Modules" list on this page is categorized the same way Operations, Compliance and Admin are grouped everywhere else in the app, and each row shows its own roster — who it actually reaches once any individual overrides are applied, and at what level — right next to the control that sets it.
• Individual: open a worker's profile → Permissions tab → Personal Permissions. Leave something on "Use default" and it will always follow whatever their position (and admin tier, if they have one) says, even if either changes later — that's the right choice almost always. Set it explicitly only when this one person genuinely needs to differ.
• Company-wide: Org Structure → Module Visibility. This is the "we don't use this feature at all" switch, or the "hide this from everyone until we're ready" switch.

"Log in as this user" — an admin-only grant, not a module

This one is governed the same way as everything above, with one difference: it isn't a real module. No position ever grants it, and there's nothing to hide via Module Visibility, so it doesn't appear in the position/module-visibility screens at all — only in the two places that actually govern it.

• Company-wide default: Org Structure → Admin Tier → the "Log in as workers" row, in the Admin category of the Modules list. Off by default.
• Individual override: on the worker's own profile, under Permissions → Admin — a tab that only appears at all when that person is actually Admin or Super Admin. A plain worker never has this, override or not.

Super Admin always has this regardless of anything set in either place, same as every other layer. Granting it lets an Admin open a worker's account exactly as that worker sees it — for troubleshooting, not for acting as them unnoticed: the impersonated worker gets a badge on their own profile while the session is open, a bell notification the moment it starts ("Someone logged in as you"), and a permanent record on their own Activity tab of who and when, both when it started and when it ended.

Two different things being gated: pages and widgets

Most permission keys gate a page — can this person open a module at all. A widgets.* key gates something narrower: a card on an Overview or Dashboard screen. These are independent. A company can leave a page reachable but turn off its Overview card, so people still reach the feature from the menu while the homepage stays less cluttered.

Dashboard widgets vs. worker widgets — opposite defaults, on purpose

The company Dashboard's own widgets (Weather, Key Stats, Recent Incidents, and so on) default hidden. Nobody sees a new dashboard widget until an admin turns it on for a position or a person — a company-wide dashboard is curated, and a new widget appearing on everyone's screen unasked is the wrong default for something that visible.

The worker Overview's own cards (My Certificates, My Action Items, Inspections, Daily Hazard Assessment, Report an Observation, and so on) default visible. These are personal — "did I file my paperwork" — and withholding them by default would mean a newly created position sees an empty Overview until someone remembers to turn cards on. An admin can still turn any one of them off, per position or per person; they just start on.

Worked example: turning off one widget for one position

Say Supervisors shouldn't see the Report an Observation card on their Overview, but everyone else should keep it.

1. Org Structure → Positions → Supervisor → Additional Permissions.
2. Find "Worker widget: Report an Observation" and set it to Hidden.
3. Every worker in the Supervisor position loses the card immediately. Anyone in a different position keeps it. A Supervisor whose own profile has an explicit override for that widget keeps whatever their override says — the override still beats the position.

Worked example: the company-wide switch overriding everything

Say a company decides it isn't using a program at all, temporarily.

1. Org Structure → Module Visibility → the relevant section → switch the widget off.
2. From this moment, nobody but a Super Admin can see that card — including anyone whose position or individual profile explicitly grants it. Those settings aren't deleted; they're just overruled. Switching the company-wide toggle back on immediately restores whatever each position and individual already had configured, with nothing to redo.
3. The Access Overrides screen says so directly next to the setting, rather than letting an admin set an override that silently does nothing: "Switched off for the whole company — anything set here has no effect until it is turned back on in Account."

Why an override can't "win" over the company switch

This trips people up, so it's worth stating plainly: an individual override is the strongest of the three layers among position, admin tier and individual — it's meant to be the final word for one specific person. But the company-wide switch isn't a layer in that same competition; it's the gate the other three layers sit behind. Turning a module off company-wide is closer to unplugging it than to out-voting somebody's permission — there's nothing left underneath for a position, an admin-tier grant or an override to grant access to.

Quick reference