Summary and recommendation
Automox user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Automox user management lives entirely in Console > Settings > Users.
Four fixed roles cover the full access spectrum: Administrator, Billing Administrator, Operator, and Read-Only.
Only Administrators can invite users or change roles, so provisioning always requires at least one active admin in the org
a constraint that applies here just as it does in every app where role-gated invites are the only path to access.
Quick facts
| Admin console path | Console > Settings > Users |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | All tiers (SSO/SAML free) |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Administrator | Full access to all console features including policy management, device management, user management, billing, integrations, and all zones. | Only Administrators can invite new users or change other users' roles. | |||
| Billing Administrator | Access to billing and subscription settings only. Cannot manage devices, policies, or users. | Cannot access device inventory, policies, or user management outside of billing. | Intended for finance/procurement contacts who should not have operational access. | ||
| Operator | Can manage devices and policies within assigned zones. Cannot access billing or user management. | Cannot manage users, billing, or access zones they are not assigned to. | Zone-scoped access means an Operator only sees devices and policies in their assigned zone(s); cross-zone visibility requires Administrator role. | ||
| Read-Only | Can view devices, policies, reports, and activity logs. Cannot make any changes. | Cannot create, edit, or delete policies, devices, or users. |
Permission model
- Model type: role-based
- Description: Automox uses a fixed set of predefined roles (Administrator, Billing Administrator, Operator, Read-Only). Operators can be scoped to specific zones, providing a degree of access segmentation. There are no custom role definitions.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Role-level with zone-based scoping for the Operator role. No per-feature or per-object permission overrides.
How to add users
- Log in to the Automox console at https://console.automox.com.
- Navigate to Settings > Users.
- Click 'Invite User'.
- Enter the invitee's email address.
- Select a role (Administrator, Billing Administrator, Operator, or Read-Only).
- If assigning the Operator role, optionally select one or more zones to scope access.
- Click 'Send Invite'. The invitee receives an email to set up their account.
Required fields: Email address, Role
Watch out for:
- Only users with the Administrator role can invite new users.
- Invitations expire if not accepted; a new invite must be sent if the link expires.
- Zone assignment for Operators must be configured at invite time or edited afterward; an Operator with no zone assigned may have limited or no device visibility.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Not documented |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Automox allows Administrators to remove (delete) users from the organization via Settings > Users. The official help documentation describes a 'Remove' action that revokes the user's access to the console. SCIM deprovisioning can also trigger user removal automatically when the user is deactivated in the connected IdP.
- Log in to the Automox console at https://console.automox.com.
- Navigate to Settings > Users.
- Locate the user to be removed.
- Click the action menu (ellipsis or gear icon) next to the user.
- Select 'Remove User' and confirm the action.
| Data impact | Behavior |
|---|---|
| Owned records | Policies and configurations created by the removed user remain in the console and are not deleted. |
| Shared content | Shared policies, groups, and worklets are unaffected by user removal. |
| Integrations | API keys or tokens associated with the removed user's account should be audited and rotated separately, as removal of the user does not automatically revoke API keys. |
| License freed | Automox licenses are endpoint-based, not per-user seat licenses; removing a user does not directly free a billable seat. |
Watch out for:
- Automox pricing is per endpoint, not per user, so removing users does not reduce the subscription cost.
- If SCIM provisioning is active, deprovisioning the user in the IdP will remove their Automox access; manual removal in the console is also effective but may conflict with IdP state if SCIM is enabled.
- There is no documented 'deactivate/suspend' state separate from full removal; removal is the primary offboarding action.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Endpoint license | All console users are included at no additional per-user cost. Licensing is based on the number of managed endpoints (devices), not the number of console users. | From $1/endpoint/month for Patch OS tier; Automate Essentials and Automate Enterprise are custom-priced. |
- Where to check usage: Console > Settings > Subscription (shows endpoint count against licensed limit)
- How to identify unused seats: Navigate to Settings > Users to review the list of console users and their last-login activity. Automox does not expose a dedicated 'inactive users' report in the standard UI; last-login timestamps must be reviewed manually.
- Billing notes: Billing is based on managed endpoint count, not user count. Adding or removing console users has no direct impact on the subscription invoice. Endpoint counts are visible under Settings > Subscription.
The cost of manual management
Automox licenses by managed endpoint, not by console user count, so adding or removing users has no direct billing impact. Endpoint usage is visible under Settings > Subscription.
Because there is no dedicated inactive-user report in the UI, identifying stale accounts means manually reviewing last-login timestamps in the Users list - a step that compounds in overhead across a growing environment.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
SCIM 2.0 is available and is the recommended path for orgs already running an IdP, covering every app in the provisioning pipeline including Automox without requiring SSO as a prerequisite. For teams without an IdP integration, manual invite-and-remove via the console is straightforward but requires an Administrator to execute every change.
Zone assignment for Operators must be set at invite time or edited afterward - an Operator with no zone assigned may have limited or no device visibility, which is easy to miss during bulk onboarding.
Bottom line
Automox's user management is functional and low-overhead for small to mid-sized teams: endpoint-based billing means user churn has no cost consequence, and SCIM support removes manual toil for orgs with an IdP.
The ceiling is role flexibility - the fixed role set and the absence of a last-login report are real operational gaps for larger organizations that need fine-grained access control or automated stale-account detection across every app in their stack.
Automate Automox workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
