Skip to content

Roles

Define the permission sets that users are assigned to — the seven built-in roles and any custom roles your company creates.

Required role

Admin.

Overview

A role is a named bundle of permissions. Users don't hold permissions directly; they hold roles, and each role grants a set of permissions. This keeps access decisions consistent — change the role's permissions, and every user with that role updates on their next token refresh.

Open Configuration → User Setting → Roles to see the list.

The seven built-in roles

Pre-seeded on every installation and used by most organisations as-is:

  • Technician — executes tasks in the field.
  • Mapper — builds and maintains asset hierarchy, tasks, and safety.
  • Supervisor — assigns and approves work.
  • Manager — read-only consumption of reports.
  • Admin — company-level administration.
  • Viewer — read-only for audit and compliance.
  • PegotecUser — cross-tenant, Pegotec staff only.

See Permissions matrix for the full permission breakdown.

View a role

Roles → (row). The detail page shows:

  • Role name and description.
  • Assigned users (link through to each).
  • Permission matrix (ticked permissions are granted).
  • Creation / last-modified info.

Create a custom role

Built-in roles cover most cases. Create a custom role only when you need a combination the built-ins don't offer.

  1. New role.
  2. Fill in:

    Field Notes
    Name Descriptive — "Safety Officer", "Night Shift Supervisor", "Contractor Auditor". Avoid clashing with built-in names.
    Description Optional. Document the role's intent so future admins know what it's for.
    Permissions Tick from the 40+ available. Group by domain: task., mapping., report.*, etc.
  3. Save.

Duplicate from a built-in starting point

Instead of building from scratch, duplicate a close match (e.g. Manager → add task.assign) and trim / add from there. Faster and more consistent.

Edit a role

Roles → (row) → Edit. Change name, description, or permission set. Changes propagate to existing users on their next token cycle.

You can edit custom roles freely. Built-in roles may be editable but don't edit them unless you have a strong reason — future platform updates assume their default permission sets.

Delete a role

Roles → (row) → Delete. Blocked if any users are still assigned. Reassign or deactivate those users first.

Permission categories

Permissions group by domain. A custom role typically picks from these:

Domain What it gates
dashboard.* Dashboard access.
task.* View / assign / approve / execute tasks.
mapping.* Asset hierarchy CRUD.
component.* Components catalogue.
schedule.* Scheduling setup.
safety.* Safety procedures.
report.* Reports view / export.
settings.* Company-wide settings.
user.* / role.* User and role management.
mobile.* Mobile-app-specific features (NFC, execute, report shutdown, etc.).

See Permissions matrix for the full list.

Assigning roles to users

Done on the user's detail page, not here. See User List.

Things to watch for

Don't delete a role that users still depend on

The system blocks it, but the better workflow is: reassign users to a replacement role, verify they still work, then delete.

Name custom roles unambiguously

Don't create a role called "Supervisor Plus" that's actually a variant of Manager — people will misread. Name for the job, not the starting point.

Permissions apply per-user, not per-session

A user who's mid-session when you change their role sees the new permissions on their next action (or within a minute). No sign-out required on their side.

Troubleshooting

Problem Fix
New role doesn't show in user-edit dropdown Confirm it's active and saved; refresh
User with role still can't access expected page Check the page's permission against the role's ticked boxes in the matrix
Can't find a permission Some are conditional on installation config; check Feature flags