

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.
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
Supervisor against Planner
Supervisor against Planner
A supervisor moves a maintenance round; only a planner decides it stops happening. The
supervisor owns today; the planner owns the schedule.
Technician against Supervisor
Technician against Supervisor
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 and meter readings
Technicians and meter readings
Technicians can create and edit meter readings. Taking a reading is the most ordinary thing a
technician does.
Manager against Storekeeper
Manager against Storekeeper
A maintenance manager reads inventory but does not move stock; a storekeeper moves stock but
does not plan maintenance. A manager approves a requisition.
Vendor
Vendor
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.
Asking the copilot against accepting its suggestions
Asking the copilot against accepting its suggestions
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.
Auditor against Executive
Auditor against Executive
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


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


Save changes applies at once to everybody holding the role, on their next request.
Copying a role


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.
A person’s own site and place grants, set on the People tab, narrow them further. See
how scope combines.
The permission grid


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.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.
Work
Work
Assets
Assets
Sites
Sites
Inventory
Inventory
Property
Property
Gatehouse
Gatehouse
Workforce
Workforce
Procurement
Procurement
Finance
Finance
Commercial
Commercial
Knowledge base
Knowledge base
Analytics
Analytics
Messages
Messages
Setup
Setup
On any record
On any record

