Summary and recommendation
Code42 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.
Code42 user management lives under Administration > Users in the Code42 console.
The permission model is strictly role-based: four predefined roles (System Admin, Security Center User, Customer Cloud Admin, Desktop User) cover every app access pattern, and permissions cannot be customized within a role.
Role assignment is the primary lever for controlling what any user can see or do.
Quick facts
| Admin console path | Administration > Users |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| System Admin | Full administrative access to all Code42 console features including user management, policy configuration, alerts, cases, and reporting. | System Admin role grants unrestricted access; should be assigned only to trusted administrators. | |||
| Security Center User | Access to Alerts, Cases, and Forensic Search for security investigation workflows. | Cannot manage users, configure backup policies, or access billing settings. | |||
| Customer Cloud Admin | Manages users, devices, and organizational settings within an assigned customer organization. | Cannot access cross-organization settings or billing. | |||
| Desktop User | End-user role; can install the Code42 agent and access personal backup/restore functions. | Cannot access the admin console or any administrative features. | Desktop Users consume a licensed seat. |
Permission model
- Model type: role-based
- Description: Code42 uses a predefined role-based access control model. Administrators assign one or more built-in roles to each user. Roles determine which console features and data a user can access.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Role-level; permissions are bundled per role and cannot be individually customized within a role.
How to add users
- Sign in to the Code42 console.
- Navigate to Administration > Users.
- Click 'Add user'.
- Enter the required user details (username/email, first name, last name).
- Assign one or more roles to the user.
- Optionally assign the user to an organization.
- Click 'Save' to create the user account.
- The user receives an email invitation to set their password and activate their account.
Required fields: Email address (used as username), First name, Last name
Watch out for:
- Users must activate their account via the emailed invitation before they can log in.
- If SSO is enforced, the user's email domain must match the configured SSO identity provider.
- Users must be assigned to an organization; the default organization is used if none is specified.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | Administration > Users > Import users (CSV upload option within the Users page) |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Code42 supports both deactivating and deleting users. Deactivating a user blocks console and agent access while preserving their data and backup history. Deleting a user permanently removes the account. Official docs describe deactivation as the recommended approach to retain data for investigation purposes.
- Sign in to the Code42 console.
- Navigate to Administration > Users.
- Search for and select the target user.
- Click 'Deactivate user'.
- Confirm the deactivation in the dialog.
| Data impact | Behavior |
|---|---|
| Owned records | Deactivated users retain their backed-up data and file event history, which remains accessible to administrators for investigation. Deleted users have their data removed. |
| Shared content | Not documented |
| Integrations | Deactivating a user stops the Code42 agent on their devices from syncing. SCIM-provisioned deactivations are triggered automatically when the user is deprovisioned in the IdP. |
| License freed | Deactivating a user frees their licensed seat for reassignment. |
Watch out for:
- Deactivated users can be reactivated; deleted users cannot be restored.
- If SCIM provisioning is in use, deprovisioning the user in the IdP automatically deactivates them in Code42 rather than deleting them.
- Backup data for deactivated users is retained according to the organization's data retention policy, not indefinitely.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Licensed User Seat | Code42 agent deployment on endpoints, file event collection, backup, and console access based on assigned role. | Custom pricing; approximately $90/user/year at base tier per available market data. |
- Where to check usage: Administration > Users (filter by status to view active vs. deactivated users and seat consumption)
- How to identify unused seats: Filter the Users list by 'Last activity' or 'Device last connected' to identify users with no recent agent activity. Deactivated users do not consume a seat.
- Billing notes: Code42 is sold on an annual subscription basis with custom enterprise pricing. Seat counts are negotiated at contract time. Deactivating users frees seats; contact Code42 account management to adjust contracted seat counts.
The cost of manual management
Every app in your stack that lacks automated provisioning adds recurring manual overhead, and Code42 is no exception. Each new hire requires an admin to create the account, assign roles, and confirm org placement - then wait for the activation email to clear before access is live.
Offboarding carries its own risk: deactivation blocks access and preserves data for investigation, but deletion is permanent and irreversible, so the wrong action at the wrong time has lasting consequences.
At scale, tracking active versus deactivated seats across Administration > Users - filtered by last activity or device last connected - becomes a recurring audit task rather than a one-time setup.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual management is workable for small, stable teams where role assignments rarely change. For organizations with frequent onboarding, offboarding, or role transitions, the lack of custom roles and the absence of webhooks for user lifecycle events mean that every app change requires direct console intervention.
Teams already running an IdP should evaluate SCIM provisioning (Enterprise plan required) before committing to a manual workflow at scale.
Bottom line
Code42's manual user management is straightforward for basic operations but shows friction at scale. The predefined role model covers common access patterns cleanly, and deactivation-before-deletion is the right default for data-sensitive environments.
The real cost is operational: no custom roles, no lifecycle event hooks, and a console that can lag on status updates mean that growing teams will outgrow manual management faster than the tooling suggests.
Automate Code42 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.
