Skip to main content
A role is a named bundle of permissions — what somebody may do — plus optional limits on how much of the organisation it reaches; this page explains how to compose one and lists every permission there is. The Roles tab of the Access screen, with the Technician role selected The Roles tab of the Access screen, with the Technician role selected Roles live on the Roles tab of Administration → Access. Give somebody more than one role and they get the union of everything those roles grant.

The role a new organisation starts with

A new organisation is created with one role: System Administrator, held by the person who signed up. It holds every permission there is, reaches every site, and receives any permission a later release adds without anybody having to grant it. It is marked holds everything in the role list and is maintained by the product: you cannot edit or delete it, so there is always a way back to full control. Every other role is yours to compose. Until you have made one, the invitation form warns you that the only role on offer is the administrator, so nobody is invited with full control by accident. Create a narrower role first — Copy this role on an existing one is the quickest start — and invite people into that.
Organisations that have been running for a while may also have eleven more roles — Maintenance Administrator, Maintenance Manager, Maintenance Planner, Maintenance Supervisor, Technician, Storekeeper, Procurement User, Vendor, Requester, Auditor and Executive. These used to be installed in every organisation. They are now ordinary roles of yours: edit them, rename them or delete them as you would any role you made yourself. A future release never changes what they hold.
Your organisation may also show a role the product’s support team signs in with when you let them in. It reads everything and changes nothing, is maintained by the product, and cannot be edited here; to stop them signing in, end their access.

Starting-point roles

The eleven roles below are a sensible way to divide maintenance work, and the demonstration organisation is built from them. Use them as patterns when you compose your own. The Holds column is the number of permissions each grants out of everything available. The permission reference at the foot of this page shows, permission by permission, which of these hold it.

Where the boundaries sit

A supervisor moves a maintenance round; only a planner decides it stops happening. The supervisor owns today; the planner owns the schedule.
A technician may add a photograph or a comment to a job; they may not remove one. A supervisor may. The photograph of the thing you were sent to fix is evidence, and evidence should not be removable by the person it concerns.
Technicians can create and edit meter readings. Taking a reading is the most ordinary thing a technician does.
A maintenance manager reads inventory but does not move stock; a storekeeper moves stock but does not plan maintenance. A manager approves a requisition.
Deliberately narrow. A vendor sees the jobs given to their company and the assets those concern — not your asset register, not your other vendors, not your costs. See the vendor portal.
A technician may ask the copilot and read what comes back. They may not accept a suggestion, because accepting writes to a record, and that stays with the roles that already edit one. Switching the copilot on at all is a configuration decision.
Both read everything and change nothing. An auditor additionally gets the audit trail — field-level history of who changed what. An executive gets analytics instead. Neither gets User activity, which counts what each person did: only the System Administrator holds it until you grant it to a role.

The Roles tab

The left column lists every role, with the number of permissions it grants and, after a dot, how many people hold it (49 · 1u is 49 permissions held by one user). Two markers may follow a name: holds everything for the System Administrator, and outside for a role marked for people outside the company. Choose a role to see it on the right. Add a role above the list opens the new-role form.

Creating a role

The New role dialog The New role dialog Create saves the role with no permissions. Choose it in the list and grant what it needs on the grid. Places and report modules are set on the role after it exists.

Editing a role

The Edit role dialog The Edit role dialog Save changes applies at once to everybody holding the role, on their next request.

Copying a role

The Copy a role dialog The Copy a role dialog The copy gets the original’s permissions, the sites, departments, categories and statuses it covers, which fields it may edit or not see, and its settings. Nobody holds the copy until you assign it, and it is not added to status moves, approval steps, workflows or work order types that name the original — add it there yourself if it needs them.

Deleting a role

Delete this role asks first, and says how many people hold it. Those people lose everything the role granted them — check they hold another role, or they will be able to sign in and do nothing. The people themselves are not removed. The System Administrator cannot be deleted.

Narrowing a role

A role’s scope panels sit above its permission grid. Each starts empty, and empty means everything: a role with no site grants reaches every site.
Adding the first grant to a panel narrows the role from everything to that one entry, and removing the last widens it back to everything. Removing a role’s last site, place, business unit, department or category asks you to confirm for exactly that reason. Sites, places and business units count together here: removing the last site while a business unit is still granted does not widen the role, because the business unit still decides which sites it reaches.
A person’s own site and place grants, set on the People tab, narrow them further. See how scope combines.

The permission grid

The permission grid, with the Work area expanded The permission grid, with the Work area expanded The grid is arranged the way the navigation is: an area for each menu group (Work, Assets, Sites, Inventory, Property, Gatehouse, Workforce, Procurement, Finance, Commercial, Knowledge base, Analytics, Messages, Setup), plus On any record for things that apply everywhere — attachments, comments, notes, label printing, custom fields and saved views. Under each area is a screen, with a sentence saying what it covers and a link to open it, and under each screen the objects it governs, each followed by its verbs. Only modules your organisation has appear. A screen with no permissions of its own says which screen’s permissions open it. How a chip looks:

Saving changes

Nothing changes until you save. While the grid has unsaved changes the tab reads Roles · unsaved and a bar at the foot shows how many permissions you are granting and revoking, with Discard changes and Review and save. Review and save lists every permission being granted and revoked and how many people the change affects (“Nobody holds this role yet, so this changes nobody’s access today” where that is so). If the save fails, nothing is saved and your changes stay on the grid. Moving to another role or tab with unsaved changes asks whether to stay.

Report modules

Under the Reports screen’s row, Report modules narrows the five report permissions — view, create, edit, export, share — by the category a report is filed under (Assets, Energy, Finance, Inventory and so on). A role starts with every module ticked. Unticking one restricts the role to the rest; ticking everything back returns it to every module, including categories added later. A module chip only works where the role holds the report permission it narrows, and the last module of an action cannot be unticked — take the permission away instead. Module changes save as you click them.

External roles

Mark a role For people outside the company when it is for contractors or suppliers. It changes what the account is: an external account gets a narrowed navigation wherever it signs in, sees only the work given to its own company and never sees internal notes. See the vendor portal for what that view shows.
An external account works only when it is linked to a vendor. Invite a contractor or supplier from Commercial → Vendors → their Contacts tab → Invite, which creates the same account with the link. Inviting them from the Access screen against an external role creates an account linked to no vendor, so their screens come back empty. See people and access.

Field-level access

Roles can also decide who sees or answers individual fields on a form — for example, letting only planners answer a cost field, or hiding a field from contractors. That is set field by field in the form studio, under Who may answer it and Hidden from, and a copied role takes those settings with it.

Roles are not scope

A role says what somebody may do. Where they may do it is the role’s scope panels together with the person’s own site and place grants. See people and access.

Permission reference

Every permission in the product, grouped as the grid groups it. What it grants is the description the grid shows when you hover a chip. The last column shows which starting-point roles hold it in their default composition — the System Administrator holds all of them: Your own roles may hold different permissions — these are defaults to compare against, not a description of your organisation. Areas for modules your organisation does not have do not appear on your grid.
Permissions a future release adds arrive ungranted in every role except the System Administrator — nobody else has one until an administrator grants it.