Understand user roles and permissions

Almost every "why can't I see this?" question resolves to this table. MassComs has seven roles, each mapped to a fixed set of permissions, plus per-user custom permissions where a role is not quite right.

1. 01

   The seven roles

   Roles are named for the job, not for the access level, which is why the mapping is worth reading rather than guessing.

   Field or control	What it does
   Super Admin	Everything: user management, triggering, resolving, scenario creation and approval, sites, people, devices, reports, admin access, organisation settings and compliance.
   Safety Officer	Full emergency authority: trigger, resolve, create and approve scenarios, sites, people, devices, reports, admin access and compliance. Not user management.
   Security Manager	Security incidents: trigger, resolve, people, devices, reports, admin access and compliance. Cannot create or approve scenarios.
   Fire Warden	Fire and evacuation: trigger and people only. Cannot resolve an incident.
   Senior Leadership Team	Strategic: approve scenarios, generate reports, admin access and compliance. Cannot trigger or resolve.
   Reception Staff	Trigger only — the reception panic path.
   Teacher	Trigger only, with class-scoped roll call authorised separately through class assignments.

   

2. 02

   The twelve permissions

   Roles are built from these. When something is unavailable, it is one of these that is missing.

   • users.manage — create, invite and modify users.
   • incidents.trigger — activate an incident.
   • incidents.resolve — send the all-clear.
   • scenarios.create — author response plans.
   • scenarios.approve — make a scenario usable.
   • sites.manage — sites, zones, floorplans.
   • people.manage — the people register and roll call.
   • devices.manage — enrollment, locations, integrations.
   • reports.generate — reports and evidence exports.
   • admin.access — the administration area.
   • admin.orgSettings — organisation-level settings and integrations.
   • compliance.manage — compliance records and risk assessment.
3. 03

   The asymmetries worth knowing

   Three gaps in the matrix cause most operational surprises.

   • Fire Warden and Reception Staff can trigger but cannot resolve. Somebody who can resolve must always be reachable.
   • Senior Leadership can approve scenarios but cannot trigger them. Approval authority and activation authority are deliberately separate.
   • Security Manager can trigger and resolve but cannot create or approve scenarios.

   !

   Check that at least one person with incidents.resolve is available whenever people with incidents.trigger are on site. An incident nobody present can end is a real operational risk.

4. 04

   Assign roles and site scope

   In user management, set the role and the site scope. They are separate: role decides what a person can do, site scope decides where.

   Most users should be scoped to their own site. Organisation-wide visibility should be a short, deliberate list.

5. 05

   Use custom permissions sparingly

   Users can hold custom permissions beyond their role. This is useful for genuine exceptions and corrosive if it becomes the norm — a permission model everybody has exceptions to is not a model.

6. 06

   Review on a schedule

   Review roles when people change jobs, and audit the whole list termly or quarterly. The list of people who can activate an emergency response across your site is worth looking at deliberately.

   ✓

   Confirm it worked

   You can name, from the list, every person who can trigger and every person who can resolve.