Permission areas

Assign roles from Set up roles. This page is the catalogue behind those roles: every verb, every area, and which role receives which grant.

You do not hand out these strings in the Users form. Use them to compare two roles, to read an API 403, or to check that a group design matches least privilege.

When this page and the invite form disagree, trust the role list shown in the product for that organisation.

Verbs

Every grant in the current catalogue uses one of these verbs. There are no others.

Verb	Written as	What it means
All	*	Every permission in the organisation. Held only by Organisation Administrator and Administrator.
See	area.read	Open and use that area without changing its configuration. Lists, detail, search, and exports where the area has them.
Change	area.write	Create, edit, delete, assign, configure, or acknowledge in that area.

A role that lists engineering.write can also see engineering; write does not hide read. A role that lists only engineering.read can see and cannot change.

Some areas appear only as .write in the catalogue (devices, alerts, networks, status, delivery). Seeing the fleet for those jobs comes from tenant.read and the other .read grants on the same role. The .write name is the one that turns on the action.

Organisation-privileged work (SSO configuration, closing the subscription, SSO password break-glass) stays on Organisation Administrator / Administrator. It is not a separate verb you can attach to Developer or Support Engineer.

Areas

Area	Grant names	What it covers	See	Change
Tenant	tenant.read, tenant.write	Membership in the organisation and structural admin	Stay a member and use organisation context	Organisation settings, users, groups, SSO. In practice this sits on * roles.
Developer	developer.read, developer.write	Developer-portal assets	View developer assets	Manage developer-portal assets
Engineering	engineering.read, engineering.write	Device classes, software / firmware, engineering configuration	View classes and software state	Change classes, software, and related engineering settings
Operations	operations.read, operations.write	Monitors, automation, operational configuration	View monitors and ops status	Configure monitors, automation, and related ops settings
Incident	incident.read, incident.write	Incidents, on-call, response actions	View incidents and timelines	Acknowledge, update, or operate incident workflows
Security	security.read, security.write	Security activity and detections	View activity and detections	Change detection policy and security integrations
Customer	customer.read	Customer and site context	View customer-linked records	No .write in the catalogue; site roles change the site through devices, networks, and ops grants
Network	network.write	Networks and site structure	(with tenant / customer reads)	Create or change networks inside scope
Devices	devices.write	Device operation	(with tenant / engineering / customer reads)	Device actions such as reboot or capture
Alerts	alerts.write	Alerting	(with ops / support reads)	Acknowledge or tune alerts where the role allows
Logs	logs.read	Log search and inspection	Search and read logs	Log-source setup follows developer / engineering change, not a logs.write grant
Status	status.write	Status page updates	(with ops / support reads)	Publish or maintain status updates
Delivery	delivery.write	Delivery missions	(as granted by the role's reads)	Plan and operate delivery missions
Diagnostics	diagnostics.read	Diagnostic reads used by engineering-style roles	Run or view diagnostics	Covered by other change grants on the same role

Plan entitlements still apply. A role can include security.read and still see nothing if security detections are off for the organisation.

OEM roles

These roles appear in vendor / OEM organisations.

Role	Users, groups, SSO	Engineering	Ops config	Device actions	Incidents	Security	Logs
Organisation Administrator	Change, plus SSO break-glass and billing ownership	Change	Change	Change	Change	Change	See
Administrator	Change (not break-glass, not close/replace the subscription)	Change	Change	Change	Change	Change	See
Developer	No	Change	Change	Change	Change	No	See
Support Engineer	No	See	See	No	Change	No	No
Infrastructure Admin	No	See	Change	No	See	No	No
Infrastructure Operator	No	See	Change	No	See	No	No
Engineering Viewer	No	See	No	No	No	No	See
Operations Viewer	No	No	See	No	See	No	No
Incident Viewer	No	No	See	No	See	No	No
Security Admin	No	See	See	No	See	Change	No
Security Analyst	No	See	See	No	See	See	No
Security Viewer	No	No	No	No	No	See	No

Infrastructure Admin and Infrastructure Operator currently share the same permission list. Keep both so shift operators are not labelled as the people who own monitoring design.

Support Engineer can acknowledge incidents and alerts and can update status. It cannot search logs and cannot run device actions. Stack Engineering Viewer if that support pod must search logs.

Security Viewer is security activity only. It does not include fleet, engineering, or ops context. Use Security Analyst when the person must investigate with that context.

Customer portal roles

These roles appear in customer / site portal organisations.

Role	Site structure	Device actions	Ops config	Alerts	Incidents	Logs
Organisation Administrator	Change	Change	Change	Change	Change	See
Administrator	Change	Change	Change	Change	Change	See
Site Admin	Change	Change	Change	Change	See	No
Site Operator	No	Change	See	Change	See	No
Site Viewer	No	No	No	No	No	No
Viewer	No	No	See	No	See	See

Site Viewer is customer-context visibility. Viewer is the broader read-only role (dashboards, inventory, engineering state, ops, incidents, and logs) with no writes.

Legacy labels still resolve: Site Admin may appear historically as network admin, Site Operator as operator. Use the labels in the current invite form.

Grant list by role

Each role is listed with its grant names. * is every named grant in the catalogue. Organisation ownership is not a grant name; only Organisation Administrator has it.

Organisation Administrator (ORG_ADMIN)

*

Plus organisation ownership: billing, closing the account, and the SSO password break-glass path.

Administrator (ADMINISTRATOR)

*

Same named grants, without billing, closing the account, or the SSO password break-glass path.

Developer (DEVELOPER)

tenant.read, developer.read, engineering.read, engineering.write, operations.read, operations.write, incident.read, incident.write, customer.read, network.write, alerts.write, devices.write, diagnostics.read, status.write, delivery.write, logs.read

Support Engineer (OEM_SUPPORT)

tenant.read, engineering.read, operations.read, incident.read, incident.write, customer.read, alerts.write, status.write

Security Admin (SECURITY_ADMIN)

tenant.read, engineering.read, operations.read, incident.read, security.read, security.write, customer.read

Security Analyst (SECURITY_ANALYST)

tenant.read, engineering.read, operations.read, incident.read, customer.read, security.read

Security Viewer (SECURITY_VIEWER)

security.read

Infrastructure Admin (INFRA_ADMIN)

tenant.read, engineering.read, operations.read, operations.write, incident.read, customer.read, status.write

Infrastructure Operator (INFRA_OPERATOR)

Same grants as Infrastructure Admin.

Engineering Viewer (ENGINEERING_VIEWER)

developer.read, engineering.read, logs.read

Operations Viewer (OPS_VIEWER)

operations.read, incident.read

Incident Viewer (INCIDENT_VIEWER)

incident.read, operations.read

Site Admin (NETWORK_OPERATOR)

tenant.read, engineering.read, customer.read, network.write, devices.write, alerts.write, operations.read, operations.write, incident.read

Site Operator (SITE_OPERATOR)

tenant.read, engineering.read, customer.read, devices.write, alerts.write, operations.read, incident.read

Site Viewer (SITE_VIEWER)

customer.read

Viewer (VIEWER)

tenant.read, customer.read, developer.read, engineering.read, operations.read, incident.read, logs.read

Where grants show up

Place	What you see
Navigation	Sections missing when the person has no see grant (and the plan feature is on)
Page actions	Create, edit, assign, or delete hidden or rejected when they can see but not change
Users and SSO	Reserved for Organisation Administrator and Administrator as the primary role
API and automation	Same grants as the UI. A 403 is usually role, scope, or feature access
Audit	Actions are attributed to the signed-in user. Shared logins make this useless

Effective access is the union of the primary role and every group role. Scope tags then restrict which devices and networks that union applies to.

Related

• Set up roles
• Manage users
• Giving support teams safe device access
• SSO and SCIM
• Security model