Roles and permissions

Every action in the console is allowed or refused by a permission, and a role is a named set of permissions. Each person holds one or more roles. This page lists the roles every Outpost comes with and summarizes what each can do, so you can choose a role when you invite someone. The table shows each built-in role as it ships. You can change any built-in role except Owner, and create your own. See Manage roles.

Permissions are checked by the server on every request, not only hidden in the browser. A section of the navigation you lack the permission for is not shown, and the API refuses the same action if it is called directly.

Note

Home Lab has one console user, who is the owner, and roles cannot be assigned. A request to grant or remove a role on Home Lab is refused with Plan limit reached. See Plans and limits.

How permissions are named

A permission is a noun and a verb, written noun:verb. The noun is the area of the console and the verb is what the holder can do there.

Example	Allows
endpoint:read	Viewing endpoints and their inventory
endpoint:write	Changing endpoints
remote:initiate	Starting a remote session
script:approve	Approving a script so it can run
user:manage	Inviting, disabling, and enabling console users
role:manage	Granting and removing roles

Common verbs are read, write, manage, and approve. Some areas have verbs of their own, such as remote:unattended, vault:reveal, and ticket:assign.

Permission families

The permissions fall into these areas.

Area	Nouns
Endpoints and fleet	endpoint, enroll, enrollment, tag, identity, discovery, bitlocker, policy, profile, catalog, compliance
Remote access and commands	remote, command, terminal
Software and patching	software, patch, vuln
Scripts and automation	script, automation
Alerts and reports	alert, report, search
Backup and Outpost Sync	backup, sync
Service desk	ticket, incident, statuspage, sla, kb, chat, mailbox
Documentation and credentials	docs, vault
Procurement and assets	procurement, inventory, assets, integrations
MSP business	crm, project, psa
Organization and access	client, user, role, audit, storage, billing
Other	ai, feedback, console

The full list of permissions, with what each one allows, is on Permissions.

Built-in roles

Role	Code	For	Can	Cannot
Owner	owner	Whoever is accountable for the Outpost account	Everything. The owner holds every permission, including users and roles, organization settings, outgoing email, storage, and billing.	Nothing is withheld.
Support Manager	support_manager	A service desk lead	Everything a Field Technician can do, plus invite and disable console users, manage ticket queues, SLAs, ticket automation, alert rules, incidents, the knowledge base, documentation settings, compliance, and network discovery, approve patches, scripts, and software, review session recordings, and on the MSP plan approve timesheets.	Change outgoing email or mailboxes, change storage, change mandatory profile settings, or change organization settings.
Field Technician	technician	Hands-on technicians	Read and change endpoints, run commands, open remote sessions, manage and schedule scripts, deploy software, enroll endpoints, browse and restore backups, work tickets, read and use stored credentials, log project time, and read the audit log.	Manage console users or grant roles.
Support Rep	support_rep	First-line support	Work the ticket queue and live chat, view endpoints, and open remote sessions.	Run commands, change endpoints, review colleagues’ recordings, reveal stored credentials, or manage users.
Accounting	billing	Whoever pays the bill	Read your Outpost subscription and invoices, and on the MSP plan read client billing and sales.	See endpoints, open remote sessions, or read tickets.

Two more roles come with every Outpost for MSP practices. They are custom roles: you can edit and delete them, and they have no Restore defaults.

Role	Code	Can
Sales	sales	Work the sales pipeline: prospects, quotes, and sending them. No billing and no endpoints.
Project manager	project_manager	Plan and run projects, log and schedule time, approve timesheets, read and write tickets, and read client billing. No invoicing and no pipeline.

Two more custom roles come with procurement:

Role	Code	Can
Purchasing	purchasing	Buy, receive, and stock: suppliers, purchase orders, receiving, supplier bills, returns, and stock, and read the asset register.
Integration: sales	integration_sales	For API keys used by quoting and sales tools: the sales pipeline, and reading purchasing, stock, and assets.

Note

Starting a remote session needs remote:initiate and the permission for the mode the session opens in: remote:unattended, remote:attended, remote:consent, or remote:escorted. The endpoint’s remote access policy picks the mode. Every built-in role that holds remote:initiate also holds all four mode permissions. To control how technicians connect, remove mode permissions from their role, or set the modes an endpoint allows in its remote access policy. See Permission for each mode.

Every role that holds remote:initiate, built-in or custom, also holds remote:ai_control, which lets Pioneer AI control a session the technician has open. Remove it from a role to keep that role’s technicians from using it. See Let Pioneer AI control a session.

The Owner role is the ceiling. No other role holds a permission the owner does not, and a Support Manager holds every permission a Field Technician holds.

Which roles you can assign where

Where	Roles offered
Settings > Team, Invite someone	Every role you can give, if you hold role:manage. A role that holds permissions you lack is left out. Otherwise Technician (Field Technician), Support manager, and Owner. Only owners are offered Owner.
Settings > Team, Roles on a person’s row	Every role. A role that holds permissions you lack is shown locked. Only owners can give or take away Owner.
The Team step of first-run setup	Field Technician, Support Rep, Support Manager, Accounting

An organization always keeps at least one active owner.

To change someone’s roles after they have joined, select Roles on their row in Settings > Team. You need role:manage, which among the built-in roles only the owner holds. If you are not an owner, you cannot give anyone a role that holds permissions you lack. A role change applies from the person’s next request, and they receive an email saying their account permissions were changed. See Change a person’s roles.

Related

• Manage roles
• Invite your team
• Permissions
• Audit logs