Users, Groups & Permissions

octoja uses a group-based access model with users, groups, and granular access rules. A group decides three things: which features its members can use (permissions), which customers they can reach (customer access), and which devices they can work with and what they may do on them (device access).

Users

A user is a person with access to octoja. A user account includes an email address and an authentication method (password, TOTP two-factor authentication, or Microsoft SSO). There are no fixed user roles — access is controlled entirely through groups.

Groups

A group bundles a set of permissions together with a customer-access and a device-access scope. Users belong to one or more groups, and a user's effective access is the union of everything their groups grant. A user with no group membership can sign in and view their own profile, but reaches no managed content.

You build your own access model by creating groups that match how your team works — for example, a help-desk team that can reach one customer's workstations read-only, without touching anyone else.

Permissions

Permissions decide which features a group's members can use. The group editor shows each one under the label below; the identifier in parentheses is what appears in technical contexts such as the API:

User Management (users.manage) — Creating, editing, and deleting user accounts

Group Management (groups.manage) — Creating, editing, and deleting groups

Customer Management (customers.manage) — Creating, editing, and deleting customers and their sites

Monitoring Check Management (monitoring-checks.manage) — Managing monitoring check configurations and assignments

Alert Management (alerts.manage) — Managing the alert rules that notify you when a monitoring check keeps failing

Software Deployment Management (software-deployments.manage) — Managing software deployment that rolls software out to devices

Custom Package Management (custom-packages.manage) — Creating and managing config packages (custom packages)

Agent Management (agents.manage) — Managing agent deployment settings and enrollment tokens

Case Management (tickets.manage) — Creating, updating, and closing cases

View Cases (tickets.view) — Read-only access to view cases

Reports (reports.manage) — Creating, editing, and running report templates

Integration Management (integrations.manage) — Managing third-party integrations such as Lywand, webhooks, and Teams

Branding Management (branding.manage) — Managing platform branding settings

Tag Rules (tags.manage) — Managing tag rules that automatically apply tags to devices

View Patch Management (patch-management.read) — Viewing patch policies, cycles, and results

Patch Policy Management (patch-management.write) — Creating and editing patch policies

Approve Patch Cycles (patch-cycles.approve) — Approving, rejecting, and finalizing patch cycles

Emergency Patch Cycles (patch-cycles.emergency) — Creating emergency patch cycles that bypass ring ordering

Manage automations (automations.manage) — Creating, editing, running, and deleting automation workflows

View Reports (reports.view) — Viewing and generating reports, without editing or deleting report templates

Create Custom Tags (tags.create-custom) — Creating new custom tags (members without it can only apply existing tags)

Check Repository Management (check-repositories.manage) — Managing check repositories, the instance-wide sources of monitoring checks

Custom Check Management (custom-checks.manage) — Managing the instance-wide catalog of custom checks

Customer access

Customer access decides which customers a group's members can see and work with. A group is set to one of:

• Access all customers — every customer in the organization.
• Specific customers — an explicit list you pick.
• Customer tag rules — every customer whose tags match the rules you define, so newly added customers are included automatically.

You can combine a specific list with tag rules in the same group.

Device access

Device access refines what members reach within their accessible customers — a group with no customer access reaches no devices at all. It has two parts:

• Which devices — reach every device of the accessible customers, or only devices that match device rules.
• Allowed actions — which device actions members may perform: Service Control, Process Control, Remote Desktop, Terminal, Registry, File Browser, Software Management, Event Log, Run Script, Run Maintenance, Edit Device, Delete Device, Send Notification, and Bypass Remote-Desktop Consent.

A group that can reach devices but has no allowed actions gives read-only device access — members can see the devices but cannot act on them.

To see the combined result of every group — who can reach which customers and devices, and why — open the Access Overview page. It shows access by user, by customer, or by device, so you can confirm your groups grant exactly what you intended.

Administrator groups

A group can be marked as an Administrator group. Its on-screen description reads: "New permissions introduced in future updates are granted to administrator groups automatically." Enable it on your full-access group so it never falls behind when a future octoja update adds a new permission.

Authentication

Users can authenticate using:

• Local password — set during account creation
• TOTP two-factor authentication — an authenticator app generates a 6-digit code at login
• Microsoft SSO — sign in using a Microsoft work or school account via OIDC

Related articles: Create a User, Create a Group, Assign Permissions, User Fields, Reset Your Password