Roles and permissions
The role says what a person can do; the scope says where. The two are set separately, and their crossing makes the access.

The Verifline roles
Section titled “The Verifline roles”Verifline provides seven roles, the same in every organization. They can’t be changed or deleted: to adapt one, duplicate it, and the copy becomes one of your roles. In return, they improve for every organization at once: when Verifline refines a role, the people who hold it benefit without you having to do anything.
| Role | In a word |
|---|---|
| Administrator | everything — people, roles, settings and all the work |
| Quality manager | designs templates and who can use them, reviews and corrects work across the organization, tracks results |
| Site lead | conducts inspections and oversees their scope: corrects the inspections and actions of their sites |
| Inspector | conducts inspections within their scope, creates the resulting actions, records observations on assets |
| Fleet manager | looks after the asset fleet, conducts inspections within their scope |
| Management | reads all of the organization’s work, without changing anything |
| External contributor | responds to the actions assigned to them, nothing else |
The Roles screen sorts them into two blocks: Verifline roles, then Your roles. A Verifline role’s page reads without controls: for each domain, the level it holds and everything that level includes, then Configure, Granted or Not granted. Duplicate to customize opens a new role that starts from its permissions. When Verifline improves one of them, the screen tells whoever sets roles up — Verifline roles updated, role by role, what it gets and what it loses — and Got it silences it until the next change.
Analytics follows the same logic: the Inspector has their home dashboard, without the Analytics screen; the Fleet manager and Management view the organization’s dashboards, the Site lead builds their own, the Quality manager and the Administrator manage the whole organization’s — see analytics. Assets have their own permissions — see assets.
In templates, Create a template with AI and Edit with the AI assistant are permissions of their own: they come on top of creating and editing templates, without granting them. The Administrator and the Quality manager hold them; one of your roles gets them only if you tick them. They only matter once AI is switched on for your organization.
In actions, See the actions of the assets you see is a permission of its own: it shows the actions born from an asset, even those you neither created nor received, to whoever also sees the assets. Seeing the assets doesn’t grant it. Every Verifline role that sees assets holds it; your roles are offered it (see When the catalogue grows).
Permissions and their groupings
Section titled “Permissions and their groupings”A permission only does what its name says, and its reach is in its name: See their own, See those in their scope, See all inspections. Each screen has its own, Access … — it is what makes the menu entry appear. Picking from a list is one too: List the sites in their scope gives what it takes to start an inspection, without opening the Sites screen.
Permissions are sorted by domain (inspections, actions, templates, members…), into groupings whose meaning is the same everywhere:
- View — open and read, never write;
- Contribute — do one’s own work;
- Oversee their scope — other people’s work, on their sites (in inspections and actions, the two domains where work has a site);
- Manage — other people’s work, across the whole organization;
- Configure — set the domain up (action families, response sets, asset categories, site levels…).
A domain only has the groupings that make sense there: templates, a shared catalogue, have no Contribute; roles only have View and Configure. The first four form a scale: you pick one per domain. Configure sits next to it. Every permission, domain by domain, with its groupings: the Permissions reference.
This answers “why can’t Kevin see this inspection?”: an Inspector contributes — he sees his own inspections and those of his scope, not other people’s outside his sites. Here is the same Inspections screen as an inspector sees it:

Your roles
Section titled “Your roles”
New role starts from a blank page: each domain has its card, and each level in it lists what it adds to the one before. Pick one per domain — or None —, and Configure if the role sets that domain up: the line says what Configure covers. Duplicate starts from an existing role, a Verifline one or one of yours. On a role’s page, its name is the title and its sentence reads below: your roles can be renamed (Rename, the name and the sentence), adjusted and deleted. Every domain keeps its card and its place; those the role doesn’t touch sit on None. On a phone, a domain’s levels read one under the other.
Custom, at the top of a domain’s card, shows all its permissions, filed under the level that gives them: tick them one by one. Nothing is ticked for you: a permission that needs another says so under its domain — “Start an inspection in their scope” also needs: List the sites in their scope. — and the role can’t be saved while one is missing.
In the menu, under the role’s name, reads before you save: the screens the role brings up.
A role’s history
Section titled “A role’s history”At the bottom of a role’s page, the History says who created it, who changed it — with the permissions Added and Removed — and every time it was given to someone. When a member of the Verifline team acts from someone’s account, the line names them too.
When the catalogue grows
Section titled “When the catalogue grows”When Verifline adds a permission, Verifline roles get it on their own. Your roles, never without you. If one of them holds the level that takes it in, its page offers it in that domain’s card — New permission in Contribute: Remove their own observations —: Add adds it to the role, Not now leaves it aside, and it won’t be offered again; you can still tick it by hand, under Custom. Elsewhere, the permission shows up marked New until the role is next saved. The history keeps your choice.
Giving a role: three rules
Section titled “Giving a role: three rules”Giving a role means giving rights. Three rules apply everywhere: a member’s profile, the selection of several members, invitations, roles, sites and groups.
- You only give what you have. A role that grants rights you don’t have stays in the list, greyed out: Exceeds your rights, followed by the domains concerned. Creating, editing or deleting a role follows the same limit: in the grid, a grouping or a box you don’t have stays greyed out, and a copy leaves out the rights you don’t have.
- You only touch someone whose rights are included in yours. On the profile of someone with rights you don’t have, Change the role and Remove from organization are disabled, and a line says why. Their sites and groups can’t be changed either.
- You never grant yourself anything. You can rename your own role, but its permissions are changed by another member who manages roles, and you can’t delete it. You don’t assign yourself to a site or a group; removing yourself is still possible.
Inviting follows the same rules: promising sites to the invitee requires Assign members on sites, and groups, Add and remove members on groups. Last, while other members remain, the last person who can manage the organization doesn’t delete their account: they first give that role to someone else.