OneTrust User Management Guide

• Model type: hybrid
• Description: OneTrust uses a hybrid model combining predefined system roles (System Administrator, module-specific roles) with custom role creation. Permissions can be assigned at the role level and further scoped by Groups, which control access to specific records, workflows, and data assets. Role assignments are additive.
• Custom roles: Yes
• Custom roles plan: Available on paid plans; exact tier threshold not publicly documented-confirm with OneTrust.
• Granularity: Roles control module-level and action-level permissions (view, create, edit, delete, approve). Groups further restrict or grant access to specific records, assessments, or organizational units. Some modules (e.g., Privacy Rights Automation) have additional workflow-level permission controls.

1. Log in to the OneTrust platform at app.onetrust.com.
2. Navigate to Platform Settings (gear icon) → Users & Groups → Users.
3. Click 'Invite User' or 'Add User'.
4. Enter the user's First Name, Last Name, and Email Address.
5. Assign one or more Roles from the available role list.
6. Optionally assign the user to one or more Groups.
7. Click 'Save' or 'Send Invitation'. The user receives an email invitation to set their password (if SSO is not enforced).
8. If SSO is enforced, the user account is created but login is via the configured IdP.

Required fields: First Name, Last Name, Email Address, At least one Role

Watch out for:

• If SCIM provisioning is active, users should be provisioned from the IdP rather than manually to avoid sync conflicts.
• Email domain must be reachable; invitation emails can be blocked by corporate spam filters.
• Role assignment at invite time is required; users with no role assigned have no meaningful access.
• If SSO is enforced, the invited user must exist in the IdP before they can log in, even if the OneTrust account is created.
• Group assignment is separate from role assignment and must be done explicitly; new users are not auto-added to any group.

• Can delete users: Verify in tenant
• Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.

1. Navigate to Platform Settings → Users & Groups → Users.
2. Locate the user by searching by name or email.
3. Click on the user's name to open their profile.
4. Click the 'Deactivate' button (or toggle the Active/Inactive status).
5. Confirm the deactivation in the dialog prompt.
6. The user is immediately unable to log in. Their record remains visible in the user list with an 'Inactive' status.

Watch out for:

• There is no bulk deactivation option in the UI; each user must be deactivated individually unless done via API.
• Deactivated users still appear in user lists and historical reports; filter by 'Active' status to exclude them from operational views.
• If SCIM is enabled, deactivation should be triggered from the IdP to keep directory and OneTrust in sync; manual deactivation in OneTrust may be overridden on the next SCIM sync.
• Users who are the sole owner of critical records (e.g., DPIAs, vendor assessments) should have ownership transferred before deactivation to avoid workflow blockages.
• Reactivating a previously deactivated user restores their account with the same roles and group memberships they had at deactivation.

• Where to check usage: Platform Settings → Users & Groups → Users (filter by Active status to see current active seat count). No dedicated license usage dashboard is publicly documented; seat consumption visibility may require contacting the OneTrust account team or CSM.
• How to identify unused seats: Filter the Users list by 'Last Login' date (if available in the tenant's UI version) or export the user list via API (GET /api/v2/SystemUsers) and sort by lastLoginDate field to identify users who have not logged in recently.
• Billing notes: OneTrust uses annual subscription pricing negotiated per contract. Seat counts and module access are defined at contract signing. Adding users beyond the contracted seat count may require a contract amendment. Pricing is not publicly listed for most product lines; all changes go through the OneTrust account team. SCIM and SSO features require Enterprise tier.

OneTrust does not offer a bulk deactivation option in the UI - each user must be deactivated individually unless you use the API. There is no dedicated license usage dashboard; identifying unused seats requires either filtering the Users list by last login date or exporting via API and sorting by lastLoginDate.

Seat counts and module access are fixed at contract signing, so overages require a contract amendment through the OneTrust account team.

Reviewers on G2 and TrustRadius consistently flag role and permission configuration as complex and poorly documented, often requiring CSM or professional services involvement for initial setup. The admin console navigation changes materially between platform versions, making internal runbooks go stale quickly.

Help documentation is largely behind a login wall at my.onetrust.com, which compounds onboarding friction. When SCIM is active, manual user changes in OneTrust can be silently overwritten on the next IdP sync - a recurring source of unexpected permission changes reported in community feedback.

Common complaints:

• Users report that the admin console navigation changes significantly between OneTrust platform versions, making documentation and internal guides quickly outdated.
• Multiple reviewers on G2 and TrustRadius note that role and permission configuration is complex and not well-documented, requiring professional services or CSM assistance for initial setup.
• Users report difficulty identifying which users have not logged in recently due to limited built-in reporting on seat utilization.
• Reviewers note that bulk user management (bulk deactivation, bulk role changes) is not available in the UI and requires API usage or manual one-by-one actions.
• Community feedback indicates that when SCIM is enabled, manual user changes in OneTrust can be silently overwritten by the next IdP sync, causing unexpected permission changes.
• Users report that the help documentation is largely behind a login wall (my.onetrust.com), making pre-purchase and onboarding research difficult.
• Some reviewers note that seat count reconciliation and license usage visibility require going through the account team rather than being self-serve in the platform.

Manual management is workable if your OneTrust footprint is small, your team changes infrequently, and you are not yet on an Enterprise plan with SSO enforced. Once headcount grows or compliance audit requirements tighten, the absence of bulk actions and limited seat-utilization reporting become real operational costs.

The External Respondent / Vendor Portal model is worth understanding early: external parties respond via a dedicated portal and do not consume internal named seats, which affects how you scope your contract.

Bottom line

OneTrust's manual user management is functional but deliberately minimal - no bulk actions, no native seat-utilization dashboard, and a permission model complex enough that most teams need outside help to configure correctly.

Every app in a compliance-heavy stack carries audit trail obligations, and OneTrust reflects that: user records are never permanently deleted, deactivation is the only offboarding path, and role assignments must be explicit at invite time.

Plan for SCIM from the start if you are on Enterprise; retrofitting it after manual provisioning has been running creates sync conflicts that are difficult to untangle.