Browse documentation
Permission groups and access control
Permission groups decide what a user with console access can reach. They're managed under Organization → Roles & Permissions (admin only).
Groups do two separate jobs: they grant access per module, and they can scope that access to particular items. Read Access levels first if you haven't — groups only matter once someone has console access.
Module permissions
A permission group grants an access level per module:
- None — no access to that module.
- View — read-only.
- Write — read and edit.
A user can belong to several groups, and their effective access is the highest grant across them. Write in one group and View in another means Write.
"None" no longer means "no access to anything". A user with no grants at all isn't locked out — they land on the self-service portal instead. See Access levels.
Scoping a group to particular items
By default a group's grants apply across the whole organisation. A group can instead be limited to specific items:
- Asset scope — particular sites, devices, servers, services, or endpoints.
- Diagram scope — particular diagrams.
Leave a scope empty and the group is org-wide for that kind. This is how you give a contractor Write on Devices for one site without handing them the estate.
Scope is exact membership — it does not cascade
This is the part that catches people out.
Adding a site to a scope does not grant access to the devices and servers at that site. Each item has to be in the scope in its own right. A group scoped to Site A alone lets someone see Site A and nothing inside it.
So to give someone a whole site's worth of access, add the site and its devices, servers, services, and endpoints to the scope. If a scoped user reports that a page lists nothing, or that a device "doesn't exist" when they follow a link, an item missing from the scope is the usual cause — out-of-scope items are hidden rather than refused.
Scopes combine across groups the same way grants do: a user gets the union of every scope they're in.
Administrators ignore scoping entirely. It's org-wide for them by definition, so you cannot use scoping to limit an admin.
Creating a group
- Select New Group and give it a name and optional description.
- Expand Module Permissions and set None / View / Write for each module.
- Optionally set an asset scope and diagram scope. Leave them empty for org-wide.
- Save.
Edit a group to adjust its name, matrix, or scopes; delete a group to remove the access it granted. The built-in Administrators group can't be edited or deleted.
Assigning users
Add users to groups from Organization → Users — a user's edit form has a Permission Groups section. A user picks up the union of all their groups' grants and scopes.
Selecting the Administrators group makes someone an administrator and switches console access on.
Notes & tips
- Model groups on job functions (Help desk, Network read-only) and assign people to them, rather than hand-tuning each user.
- Deleting a group removes the access it granted to its members — check who's affected first.
- When testing a scoped group, sign in as someone actually in it. Admins see everything, so an admin can't tell whether a scope is right.