Atera User Management Guide

• Model type: custom-roles
• Description: Two built-in preset roles (Admin and Beginner) that cannot be deleted or fully modified. Admins can create unlimited custom roles by toggling individual permissions across Remote management, RMM administration, Ticketing, and System categories. Each role can optionally be scoped to specific sites or customers. Roles are assigned to technicians individually.
• Custom roles: Yes
• Custom roles plan: All plans
• Granularity: Per-permission toggle within functional categories (remote management, RMM administration, ticketing, system/reporting). Site/customer-level access scoping per role. Folder-level exclusions supported within roles.

1. Log in as a user with Admin permissions.
2. Navigate to Admin > Users and security > Technicians.
3. Click the button to add a new technician.
4. If available seats exist, the Add technician page opens directly. If no seats are available, an 'Add seat to subscription' confirmation window appears - click 'Add seat' to expand the license.
5. Enter the required fields: Email address (username), Role, First name, Last name, Phone (optional).
6. Save the new technician record.
7. The technician receives an automated email with a link to set their password.
8. After the technician's first login, an Admin can reassign them from the default Beginner role to any other role.

Required fields: Email address (username), Role, First name, Last name

Watch out for:

• New technicians are always assigned the Beginner role on creation regardless of the role selected during setup; role reassignment is only possible after the technician's first login.
• If the seat count equals active technicians, adding a new technician triggers an automatic subscription adjustment (additional charge).
• Welcome/password-setup email may be blocked by spam filters or Outlook rules; Admin can manually reset the password as a workaround.
• CSV bulk import is available for end-users/contacts only, not for technician accounts. Technicians must be added one at a time via the UI.
• CSV import for end-users does not send welcome emails to imported users; only manually added users receive the automated email.
• CSV import for end-users does not support the Department field; departments must be assigned manually after import.
• CSV bulk import of end-users/contacts is restricted to Expert, Master, and Enterprise plans (IT) or Growth, Power, and Superpower plans (MSP).

• Can delete users: No
• Delete/deactivate behavior: It is not possible to delete a technician account. The only available action is to disable (deactivate) the account, which prevents the technician from logging in. The account record and its historical data remain in the system permanently. Disabled accounts can be re-enabled at any time.

1. Navigate to Admin > Users and security > Technicians.
2. Locate the technician to be disabled.
3. Click the ellipsis (…) menu next to the technician.
4. Click 'Disable'.
5. Confirm the action in the confirmation window.
6. The technician is immediately prevented from logging in.

Watch out for:

• Technician accounts cannot be permanently deleted; only disabled. The email/username remains in the system and cannot be reused for a new account.
• Disabling a technician permanently deletes any advanced reports in their personal folder.
• If a removed technician's license slot is formally reduced and a new technician is added in the same billing cycle, both are charged.
• To replace a technician without extra cost, disable the departing technician first, then add the new one - do not reduce the license count.
• Removed technicians retain access until the end of the current billing cycle if their license is formally removed (not just disabled).
• Toggle 'Hide disabled technicians' on the Technicians page to clean up the view; disabled accounts are not removed from the database.

• Where to check usage: Admin > Subscription > Adjust Subscription (shows current technician count vs. licensed seats). Also visible via Admin > Technicians page with the 'Adjust subscription' button on the right-hand side.
• How to identify unused seats: Review the Technicians list at Admin > Users and security > Technicians. Filter by availability status or last activity. Disabled technicians can be hidden using the 'Hide disabled technicians' toggle. No built-in 'last login' report is documented; audit logs at Admin > Users and security > Audit log may provide activity data.
• Billing notes: Pricing is strictly per technician seat; endpoint/device count does not affect cost. Adding a technician when all seats are filled triggers an automatic subscription adjustment and prorated charge for the remainder of the billing cycle. Removing a technician from the license count does not immediately revoke access - access continues until the end of the billing cycle. Disabling a technician (without reducing the license count) frees the seat for reassignment at no extra cost within the same cycle. Add-ons (AI Copilot, Network Discovery, third-party integrations via App Center) are billed separately and are not included in base technician seat pricing.

Adding a technician requires navigating the admin console, filling required fields, and waiting for the new hire to complete first login before their role can be changed from the default Beginner (no-permission) state.

Bulk import via CSV is unavailable for technician accounts; only end-user contacts support CSV import, and even that path skips welcome emails and ignores the Department field. Deprovisioning is disable-only: accounts cannot be deleted, email addresses are permanently reserved, and disabling a technician without formally reducing the license count still consumes a paid seat.

The most consistent friction points reported by Atera users center on lifecycle management gaps. SSO is paywalled to the Enterprise (IT Departments) or Superpower (MSP) tier, which users describe as gating a baseline security control behind the highest plan.

The inability to permanently delete technician accounts - and the resulting email address lock-in - forces workarounds like renaming old accounts before reusing a slot.

The mandatory Beginner role on creation, combined with the first-login requirement before reassignment, adds a predictable onboarding delay for every new technician.

Common complaints:

• SSO for technician login is restricted to the highest-tier plans (Enterprise for IT Departments, Superpower for MSPs), which users describe as paywalling a basic security feature.
• No SCIM-based automated technician provisioning is available; technicians must be added manually one at a time.
• Technician accounts cannot be permanently deleted, only disabled; the email/username persists in the system and cannot be reused, requiring workarounds such as renaming old accounts for new technicians.
• The Beginner role cannot be used for any actions and role reassignment is blocked until after the technician's first login, creating an onboarding friction point.
• CSV bulk import is not available for technician accounts, only for end-users/contacts, and is further restricted to higher plan tiers.
• CSV import for end-users does not trigger welcome emails and does not support the Department field, requiring manual follow-up.
• Many actions (creating new clients/customers, managing billing, accessing PSA-only functions) require full Admin access, with no intermediate role available for non-technical staff such as billing or sales personnel.
• AI Copilot and Network Discovery are billed as separate add-ons outside the base technician seat price.
• Features are fragmented across plan tiers, with capabilities such as SSO, extended audit logs, and private software repositories gated behind top-tier or custom-priced plans.
• Disabling a technician permanently deletes their personal advanced reports folder with no documented recovery option.

Every app in a well-governed stack ideally supports automated provisioning from an IdP; Atera does not, and that gap is the central decision factor. The permission model is genuinely flexible - unlimited custom roles with per-permission toggles across remote management, RMM administration, ticketing, and system categories, each scopeable to specific sites or customers.

The hard constraints are the absence of SCIM, the disable-only account model with permanent email reservation, and SSO availability only at the top tier. Teams managing frequent technician turnover or operating under strict access governance will feel those limits most acutely.

Bottom line

Atera's manual provisioning workflow is functional but entirely UI-driven, with no bulk tooling for technician accounts and no way to automate lifecycle events from an identity provider.

The per-technician seat model is predictable for stable teams, but the combination of no SCIM, no account deletion, and SSO restricted to the highest plan tier creates compounding overhead as headcount changes.

Teams with low technician churn and modest governance requirements will find the platform manageable; those with active onboarding/offboarding cycles or IdP-driven access policies will encounter structural friction that the current feature set does not resolve.