Creating and Editing Custom Roles
There are various preconfigured roles within the OneTrust Platform that you can assign to users. However, if you need a custom role to better meet your organization's needs, you can create a new role either manually from scratch or from a copy of another role. OneTrust recommends starting off with a copy of an existing role and adjusting the permissions accordingly.
Custom roles must be manually managed. A maximum of 150 custom roles can be created in a OneTrust Platform account.
Some inventory types in the OneTrust Platform, such as Projects and Vendors, span across multiple products. You may need permissions from more than one Permission Group to create a custom role. For instance, the Projects functionality may need permissions from the AI Governance, Global Data Manager, and Data Mapping Automation permission groups. Please reach out to OneTrust Support if you have any concerns about a permission based on its permission group origin.
You can view all system and custom roles created within the platform using the Roles screen. In addition to seeing the name and description of each role, you can differentiate between system and custom roles using the Source field and identify the number of users assigned to each role using the Users column. You can click the link in the Users column to access the list of users with the given role if needed.
To create a custom role based on an existing role
This is the recommended method for creating a new custom role.
If you create a custom role based on the default Site admin role, not all permissions will be copied automatically. Some permissions are omitted to prevent unauthorized actions.
Add Custom Role Screen Reference
- Field
- Description
- Permission group
-
Product or feature set that the permission levels support.
- Viewer
-
Permission level that allows users to view records and submit their own records through the Self-Service Portal.
- Collaborator
-
Permission level that allows users to contribute to the programs and data by editing records and collaborating through comments and tasks.
- Manager
-
Permission level that allows users access to full functionality, including the ability to create new records, delete records, and update settings or configurations.
Check Box Selection Statuses
|
Selection Status |
Description |
|---|---|
|
|
The blank box indicates that no permissions within that permission level for the permission group are currently enabled for the role, but can be enabled if needed. |
|
|
The grayed-out box indicates that the permission group does not contain any permissions that can be enabled at that permission level. For example, the Custom Object Management permission group in the image above does not contain any Viewer or Collaborator-level permissions. As a result, those levels display grayed-out boxes that cannot be enabled. |
|
|
The checked box indicates that all permissions within that permission level for the permission group are enabled for the role. A check mark will appear when you directly select the box for general permission levels, such as Viewer, Collaborator, or Manager, for a given permission group. For example, the Controls Library permission group in the image above has checked boxes for the Viewer and Manager permission levels. This means that every Viewer and Manager-level permission within the Controls Library permission group is enabled for the role. |
|
|
The minus box indicates that some permissions within that permission level for the permission group are enabled for the role. A minus will appear when you drill-down into a permission group and assign individual permissions. For example, the Assessments permission group in the image above has minus boxes for the Collaborator and Manager permission levels. This means that some but not all Collaborator and Manager-level permissions within the Assessments permission group are enabled for the role. |
To access this view, click a link within the Permission group column on the previous screen.
- Field
- Description
- Permission group
-
Product or feature set that the permission supports.
- Object
-
Object to which the permission is associated.
- Action
-
Type of action available when a user has the permission.
- Permission name
-
Name of the permission.
- Description
-
Brief description that details what the permission allows.
- Permission level
-
Level of access or persona of the permission.
To manually create a custom role
To edit a custom role
System default roles cannot be edited.
To delete a custom role
System default roles cannot be deleted.
Custom Roles FAQ
The following responses are supported solutions to frequently asked questions (FAQ) on custom roles. The OneTrust team continuously monitors these inquiries and will make additional FAQ available as they are identified.
What is a custom role?
A custom role lets administrators tailor access by selecting specific permissions instead of relying solely on predefined OneTrust roles. This helps enforce least‑privilege access while matching how users actually work.
Who can create and manage custom roles?
Only users with the appropriate administrative privileges (such as Site Admins or equivalent role‑management permissions) can create, edit, or delete custom roles.
Can I update an existing custom role after it’s created?
Yes. You can edit a custom role at any time to add or remove permissions. Changes take effect immediately for all users assigned to that role.
How are custom roles different from OneTrust’s predefined roles?
Predefined roles are managed by OneTrust and designed to support common personas and use cases. Custom roles are managed by your organization and allow you to fine‑tune permissions beyond what predefined roles offer.
When should I use a system role versus creating a custom role?
Use a system role when the predefined role already matches the user’s responsibilities and access needs. System roles are maintained by OneTrust and automatically stay up to date as the platform evolves, making them the easiest and lowest‑maintenance option.
Create a custom role when you need more granular or tailored access than a system role provides such as enforcing least‑privilege access, supporting specialized workflows, or limiting access to only a subset of functionality.
Best practice: Start with a system role whenever possible, and create a custom role only when there is a clear business or security requirement that cannot be met by an existing role.
Are custom roles automatically updated by OneTrust?
Yes. When OneTrust introduces new permissions that are required for existing functionality, those permissions are automatically added to custom roles that already include the related core permission.
What types of permissions are automatically added?
Permissions that support existing actions already allowed by the role or require dependencies for previously granted functionality. OneTrust does not add unrelated or expanded‑scope permissions relating to new functionality.
Can I see when my custom role has been updated?
Yes. Role details and permission views indicate newly introduced or recently added permissions, allowing administrators to review changes and understand why they were added.