Best practices for custom roles and permissions
Who is this article for?
Instructor, no.
Incydr Professional, Enterprise, Gov F2, and Horizon, no.
Incydr Basic, Advanced, and Gov F1, no.
CrashPlan Cloud, no.
Retired product plans, yes.
CrashPlan for Small Business, no.
Overview
After you have an understanding of managing user roles, you're ready to customize roles and permissions. Our recommended best practices provide guidelines for developing custom roles in your Code42 environment using its powerful and complex permissions.
Several standard roles are already preconfigured in your Code42 environment. These roles are thoroughly tested and provide for most common use cases.
Best practices
Process
We recommend this process for creating a new role in your Code42 environment:
- Check the existing roles to see if they meet your needs
- Make a duplicate of an existing role, then add or remove permissions as needed
- Test your customized role to ensure it behaves as expected
- Assign your custom role to users
Check existing roles first
Several standard roles are already preconfigured in your Code42 environment. These roles are thoroughly tested and provide for most common use cases.
Review the existing roles at Settings > Security > Roles.
Duplicate and modify an existing role
While you can create new roles and add permissions, we recommend starting with an existing role and changing permissions as needed for your environment.
Code42 for Enterprise permissions are modular and affect specific actions. Because of this, combining certain role permissions or omitting other permissions can cause unexpected behavior for users.
Test your custom roles
Due to the complexity of the available permissions, it is vital to test your custom roles before deploying them to users.
After creating a custom role, assign it to a test user. Then sign in as that test user and try the functions you expect that user to perform. For example, if you're creating a custom role for a help desk technician, test the role by looking through user accounts, deactivating and reactivating a user, and restoring a file from the Code42 console.
Assign your custom role to users
After testing that your custom role behaves as expected, assign that role to users in your Code42 environment.
Considerations
Be careful with SYSADMIN
The SYSADMIN role contains the admin permission, which is granted to the local administrator account. Users with the admin permission can:
- Read and write all information for all users, organizations, and settings
- Grant or remove all permissions for all users, including themselves and other SYSADMIN users
Though users with the admin permission can read and write all information in the Code42 console, it does not include all other permissions. For example, a user with admin permission cannot perform admin restores for other users.
Limiting the number of accounts with the admin permission is a good way to minimize the risk of incorrect configuration (even accidental) of your Code42 environment.
Example custom roles
These examples come from actual requests made to our Customer Champions.
Read-only user
Desired functionality
An organization wants to have "read-only" help desk users. These read-only users need to view user information in the Code42 console, but should not have permission to interact with backups, namely:
- pausing backups
- resuming backups
- performing archive maintenance
Starter role
Org Help Desk
Permissions
| Starting Permissions | Added Permissions | Removed Permissions | Final Permissions |
|---|---|---|---|
|
computer.read console.login cpd.login cpd.restore cpp.login cps.login org.read plan.read pushrestore.limited select user.read |
allcomputer.read allorg.read alluser.read viewlogs |
pushrestore.limited select |
allcomputer.read allorg.read alluser.read computer.read console.login cpd.login cpd.restore cpo.login cpp.login cps.login org.read user.read viewlogs |
Regulation-compliant backup user
Desired functionality
An organization needs to give users permission to manage their backups, but the users should not be allowed to restore data from the Code42 console for compliance reasons.
The desired behavior requires two roles: the standard PROe User role, which allows users to sign in to the Code42 console, and a customized Desktop User role.
Starter role
Desktop User
Permissions
| Starting Permissions | Added Permissions | Removed Permissions | Final Permissions |
|---|---|---|---|
|
cpd.login cps.login cpd.restore plan.create restore.personal select.personal spd.login |
pushrestore |
restore.personal |
cpd.login cpd.restore cps.login plan.create pushrestore select.personal spd.login |
Backup-only user
Desired functionality
An organization needs to give users permission to back up data, but not restore it on their own. To restore data, the users must contact their IT department.
Starter role
Desktop User
Permissions
| Starting Permissions | Added Permissions | Removed Permissions | Final Permissions |
|---|---|---|---|
|
cpd.login cps.login cpd.restore plan.create restore.personal select.personal spd.login |
cpd.restore restore.personal select.personal pushrestore |
cpd.login cps.login plan.create spd.login |
Role details
The available standard roles, as well as the permissions, limitations, and recommended use cases for each are described in the Roles reference.
For details about the specific permissions held by each role, review them in your Code42 console at Settings > Security > Roles.
Videos
Watch the video below to learn more about how to work with user roles. For more videos, visit the Code42 University.