Oracle CX Sales User Management Guide

• Model type: role-based
• Description: Oracle CX Sales uses a role-based access control (RBAC) model built on Oracle Fusion Applications Security. Access is governed by Job Roles (coarse-grained, job-function-level) and Duty Roles (fine-grained, task-level). Job Roles are assigned to users; Duty Roles are inherited through role hierarchies. Data access is further controlled by Data Security Policies that restrict which rows a user can see based on territory, business unit, or resource hierarchy.
• Custom roles: Yes
• Custom roles plan: Available on all Oracle CX Sales subscriptions; custom roles are created in the Security Console by copying and modifying predefined roles.
• Granularity: Function-level (UI actions, REST API access) via Duty Roles and Privileges; row-level data access via Data Security Policies tied to territories, business units, and resource hierarchies.

1. Navigate to Navigator > Tools > Security Console.
2. Click the 'Users' tab.
3. Click 'Add User Account'.
4. Enter required fields: Last Name, First Name, Email, and User Name.
5. Optionally set a password or select 'Send auto-generated password' to email the user.
6. Under 'Roles', click 'Add Role' and search for the appropriate Job Role(s) (e.g., 'Sales Representative').
7. Click 'Save and Close'.
8. If the user needs territory-based data access, separately assign them to a territory via Navigator > Sales > Territories.

Required fields: Last Name, First Name, Email Address, User Name (must be unique; typically email format)

Watch out for:

• User creation in the Security Console creates an Oracle Identity Cloud Service (IDCS) or OCI IAM account; the user must also be associated with a Person record (Worker or Contact) in HCM if HR-linked attributes are needed.
• Role assignment alone does not grant data access; territory assignment and resource hierarchy setup must be completed separately.
• Email delivery of auto-generated passwords depends on the instance's SMTP configuration being active; test before bulk provisioning.
• User names cannot be changed after creation in most configurations; plan naming conventions carefully.
• New users may not appear in CX Sales search or assignment lists until the LDAP synchronization job runs (scheduled or manually triggered via Navigator > Tools > Scheduled Processes > 'Send Pending LDAP Requests').

• Can delete users: No
• Delete/deactivate behavior: Oracle CX Sales does not support hard deletion of user accounts through the standard UI. Users are deactivated (their account status is set to inactive), which revokes login access and removes them from active user lists. The user record and all associated data are retained. This aligns with Oracle Fusion Applications' audit and data integrity requirements.

1. Navigate to Navigator > Tools > Security Console.
2. Click the 'Users' tab and search for the user by name or email.
3. Click the user's name to open their account.
4. Click 'Edit'.
5. Change the 'Account Status' field to 'Inactive'.
6. Click 'Save and Close'.
7. Optionally, remove all role assignments before deactivating to ensure no residual access if the account is ever reactivated.
8. Run the 'Send Pending LDAP Requests' scheduled process to propagate the change.

Watch out for:

• Deactivated users still appear in historical audit logs and as record owners; this can cause confusion in pipeline reports if ownership is not reassigned.
• If the user was a territory owner or resource hierarchy node, their deactivation can break territory coverage and team visibility for active users below them in the hierarchy.
• Reactivating a previously deactivated user restores their account but does not automatically restore role assignments if those were removed during deactivation.
• Oracle does not provide a bulk deactivation UI; deactivating large numbers of users requires either individual processing in the Security Console or a SCIM API call per user.

• Where to check usage: Navigator > Tools > Security Console > Users tab (filter by Active status to count active named users); Oracle also provides license usage reports through the Oracle Cloud Customer Connect portal and your Oracle Universal Credits dashboard.
• How to identify unused seats: Filter the Security Console Users list by 'Last Login Date' to identify accounts that have not logged in within a defined period. Oracle does not provide a native 'unused seat' report in the CX Sales UI; administrators typically export the user list and analyze last-login data externally.
• Billing notes: Oracle CX Sales is sold as a named user subscription, typically on annual or multi-year contracts. Seat counts are reconciled at renewal. Adding users mid-term may require a contract amendment. Deactivating users frees seats contractually only as permitted by your specific agreement; consult your Oracle account manager. Oracle Universal Credits customers may have more flexibility in reallocating seats across services.

Oracle does not provide a bulk deactivation tool in the UI. Offboarding large cohorts means processing each account individually in the Security Console or scripting SCIM API calls per user - a significant time cost at scale.

After creating a user, a scheduled LDAP synchronization job ('Send Pending LDAP Requests') must complete before the new account appears in CX Sales assignment fields. This job can be triggered manually via Navigator > Tools > Scheduled Processes, but the dependency is easy to miss and causes provisioning delays.

There is no native 'unused seat' report in the CX Sales UI. Identifying inactive accounts requires exporting the user list from the Security Console and analyzing last-login data externally - a manual step that compounds at renewal time when seat counts are reconciled.

Administrators consistently flag the territory-assignment gap: users provisioned with correct roles still see no records until territory setup is completed separately, and this step is not surfaced during user creation.

The Security Console is reported as slow and difficult to navigate for organizations managing hundreds or thousands of users. Role hierarchy complexity - Job Roles inheriting Duty Roles inheriting Privileges - makes access troubleshooting time-consuming, with no built-in 'effective permissions' view for a given user.

Oracle's licensing structure is a recurring friction point. Understanding which features are included at which tier typically requires direct engagement with an Oracle sales representative rather than self-service documentation.

Common complaints:

• Users report that the LDAP synchronization job ('Send Pending LDAP Requests') must be manually triggered or waited upon after user creation before the new user appears in CX Sales assignment fields, causing delays in provisioning.
• Administrators note that there is no bulk deactivation tool in the UI; deactivating large cohorts of users requires individual manual steps or custom SCIM API scripting.
• Territory assignment being separate from user creation is a frequent source of confusion; newly created users with correct roles still cannot see data until territory setup is completed.
• The Security Console is described as slow and difficult to navigate when managing large user populations (hundreds or thousands of users).
• Customers report that Oracle's licensing model makes it difficult to understand exactly which features are included at which price tier without direct engagement with an Oracle sales representative.
• Role hierarchy complexity (Job Roles inheriting Duty Roles inheriting Privileges) makes troubleshooting access issues time-consuming; there is no simple 'effective permissions' view for a given user.
• Reactivating a previously deactivated user does not restore their previous role assignments, requiring administrators to manually re-add roles.

Manual management in Oracle CX Sales is viable for small, stable teams where provisioning events are infrequent. The multi-step nature of full provisioning - user creation, role assignment, territory assignment, LDAP sync - means every app touchpoint requires deliberate follow-through, and skipping any step produces a user who can log in but sees no data.

For organizations with regular onboarding and offboarding volume, the absence of bulk operations and the LDAP sync dependency create compounding overhead. The lack of a native unused-seat report also means license hygiene requires recurring manual effort outside the platform.

Teams on Oracle Fusion Cloud CX Sales v11.12.1.0.0 or later with SSO configured have access to native SCIM 2.0, which addresses bulk provisioning and deactivation at the cost of additional integration complexity - particularly around role and territory assignment, which SCIM does not handle.

Bottom line

Oracle CX Sales manual user management is thorough but deliberately multi-step: provisioning a single user correctly requires actions across the Security Console, territory management, and a scheduled sync job.

Every app that relies on sales data visibility is downstream of this setup, so incomplete provisioning produces silent failures - users who exist but see nothing. For small teams, the process is manageable with a documented runbook.

For larger organizations, the absence of bulk tools and native license reporting makes manual management a sustained operational cost that grows with headcount.