Oracle HCM User Management Guide

• Model type: hybrid
• Description: Oracle HCM uses a layered security model combining Role-Based Access Control (RBAC) for functional permissions and Data Security for population-level access. Functional access is granted via job roles and abstract roles (predefined or custom). Data access is controlled by data roles, which pair a job role with a security profile defining which workers, organizations, or positions a user can see. Security profiles can be scoped by legal employer, business unit, department, position, or management hierarchy. Both layers must be correctly configured for a user to perform any meaningful action.
• Custom roles: Yes
• Custom roles plan: Included in base Oracle HCM Cloud subscription; custom role creation is performed in the Security Console
• Granularity: Function-level (individual duties and privileges can be added or removed from custom roles) combined with data-level scoping via security profiles. Duty roles aggregate privileges; job roles aggregate duty roles. Administrators can create custom job roles by copying Oracle-delivered roles and modifying the duty role composition.

1. Navigate to: Navigator > My Client Groups > Workforce Structures > Manage HCM Users, OR Navigator > Tools > Security Console > Users.
2. In Manage HCM Users, search for the person record (the person must already exist as a worker, contingent worker, or non-worker in HCM).
3. Select the person and click 'Create User Account' if no account exists, or 'Edit User Account' to modify an existing one.
4. Enter the username (typically auto-generated from the person's name or email, depending on configuration).
5. Set the user's email address (used for password reset notifications).
6. Assign roles: add the appropriate abstract roles (Employee, Line Manager) and job roles. Each job role that requires data access must be paired with a data role or security profile.
7. Save the record. The system sends a welcome email with a password reset link if email notifications are enabled.
8. Alternatively, user accounts can be created directly in Security Console (Navigator > Tools > Security Console > Users > Add User Account) for non-worker users such as implementation consultants or integration accounts.

Required fields: Person record must exist in Oracle HCM (First Name, Last Name, Date of Birth or National ID depending on configuration), Username (auto-generated or manually entered), Email address (for notifications and password reset), At least one role assignment

Watch out for:

• A user account cannot be created in HCM without a corresponding person record, except for non-worker accounts created directly in Security Console.
• Automatic user provisioning (triggered by new hire or assignment creation) depends on provisioning rules configured under: Navigator > My Client Groups > Workforce Structures > Manage HCM User Provisioning Rules. If rules are not set up, accounts are not created automatically.
• Role assignments take effect immediately but data security profile evaluation may be delayed until the next scheduled process (Run User and Roles Synchronization Process) completes.
• Username format is controlled by a system profile option (ORA_PER_USER_NAME_GENERATION_METHOD); changing this after go-live affects only new accounts.
• SSO-enabled environments: the username in HCM must exactly match the identity provider's username/subject claim, or login will fail.
• Non-worker user accounts (e.g., for external consultants) created in Security Console are not linked to a person record and do not consume an HCM employee license, but Oracle's licensing terms should be verified for each use case.

• Can delete users: No
• Delete/deactivate behavior: Oracle HCM does not support permanent deletion of user accounts or person records due to audit trail and data integrity requirements. User accounts are deactivated (suspended) rather than deleted. The person record remains in the system. In Security Console, an account can be set to 'Inactive' status, which prevents login. Worker termination in HCM triggers automatic account deactivation if provisioning rules include a termination action, but the account record persists.

1. Option A – Via Manage HCM Users: Navigator > My Client Groups > Workforce Structures > Manage HCM Users. Search for the person, open their user account, and set the account status to 'Inactive'. Save.
2. Option B – Via Security Console: Navigator > Tools > Security Console > Users. Search for the user, open the account, and set status to 'Inactive'. Save.
3. Option C – Via Worker Termination: Navigate to the worker's employment record and process a termination (Navigator > My Client Groups > Employment > Terminate Employment). If provisioning rules are configured with a termination trigger, the user account is automatically deactivated on the termination effective date.
4. To revoke specific roles without fully deactivating: open the user account in Manage HCM Users or Security Console, remove the role assignments, and save.
5. Run the 'Send Pending LDAP Requests' scheduled process if using LDAP synchronization, to propagate changes to the identity store.

Watch out for:

• Terminating a worker in HCM does not immediately deactivate the user account unless the 'Send Pending LDAP Requests' scheduled process runs and provisioning rules include a termination action.
• If the terminated worker is rehired, the existing user account can be reactivated rather than creating a new one, which preserves role history.
• Deactivating an account in Security Console does not terminate the worker's employment record; HR and payroll processes must be handled separately.
• Accounts deactivated in HCM may remain active in a connected IdP until the next SCIM sync or manual deactivation in the IdP.
• Users with active approval workflow tasks at the time of deactivation may cause workflow stalls; reassign pending tasks before deactivating.

• Where to check usage: Navigator > Tools > Security Console > Users - filter by status (Active/Inactive) to review active user accounts. For licensed headcount, Navigator > My Client Groups > Workforce Structures > Manage HCM Users provides a list of all persons with user accounts. Oracle also provides usage reports via the Oracle Cloud Customer Connect portal and through the Oracle License Management Services (LMS) process at renewal.
• How to identify unused seats: No native 'last login' report is surfaced in the standard HCM UI. Administrators can run the 'User Login History' report via Oracle BI Publisher or OTBI (Oracle Transactional Business Intelligence) using the subject area 'Workforce Management – User Login Real Time' to identify accounts with no recent login activity. Inactive accounts can also be identified in Security Console by filtering on account status.
• Billing notes: Oracle HCM is licensed on a per-employee basis for all active employees in the system, not per named user or per login. Contracted headcount is set at signing with a minimum of 1,000 employees. Overages above contracted headcount are typically trued up at renewal. Test/sandbox environments are licensed separately (~$150K/year estimated). Add-on modules are priced per employee per month regardless of whether individual employees use the module. Pricing is negotiated; list prices are indicative only.

Oracle HCM is licensed per active employee, not per named user or login, with a minimum of 1,000 employees and a 3-year minimum term. Add-on modules (Recruiting, Talent Management, Learning) are priced per employee per month regardless of individual utilization, so unused module access does not reduce cost mid-term.

Overages above contracted headcount are typically trued up at renewal rather than billed in real time.

There is no native last-login column in the standard user management UI. Identifying inactive accounts requires building a custom OTBI report against the 'Workforce Management – User Login Real Time' subject area - a step that many teams skip, leaving stale accounts active and counted against license.

Test and sandbox environments carry a separate licensing cost estimated at approximately $150K/year.

The dual-layer security model is the most consistently reported pain point across Oracle HCM administrator communities.

The combination of job roles, data roles, and security profiles creates a configuration surface where a single missing link - typically the data role - produces no visible error, just an empty UI for the affected user.

Provisioning delays are a close second. Changes to user accounts are not propagated in real time; the 'Send Pending LDAP Requests' scheduled process must run before updates reach the identity store.

Teams that do not configure termination triggers in their provisioning rules report that terminated employees retain active accounts until someone notices.

Non-worker accounts (external consultants, integration service accounts) created in Security Console are not linked to person records, making them harder to surface in routine access audits.

Common complaints:

• Users frequently report that the dual-layer security model (job roles + data roles + security profiles) is complex to configure correctly, and that granting a job role without the correct data role results in the user seeing no data, which is difficult to diagnose.
• The 'Send Pending LDAP Requests' scheduled process must be run manually or on a schedule to propagate user account changes to the identity store; changes are not real-time, causing delays between HR actions and actual access changes.
• Automatic user provisioning rules are not intuitive to configure, and many customers report that terminated employees retain active accounts because provisioning rules were not set up to handle terminations.
• There is no built-in 'last login date' column in the standard user management UI; administrators must build custom OTBI reports to identify inactive accounts.
• License reconciliation is opaque; customers report difficulty determining exactly which employees are counted against their license and how to reduce headcount mid-term.
• Creating user accounts for non-worker users (e.g., external consultants, integration service accounts) requires using Security Console rather than the standard HR workflow, and these accounts are not linked to person records, making them harder to audit.
• Role inheritance and duty role hierarchies are difficult to audit; customers report that Oracle-delivered roles change between quarterly updates, sometimes adding or removing privileges unexpectedly.

Oracle HCM is the right choice when it is already the system of record for workforce data and every app in the environment needs to reflect HR-authoritative identity. Its provisioning rules, when correctly configured, can automate account creation and deactivation across the employee lifecycle without manual intervention.

The tradeoffs are real: the security model requires sustained administrative expertise to maintain correctly, license reconciliation is opaque mid-term, and there is no real-time propagation of access changes without a connected identity provider handling SCIM sync.

Teams without a dedicated HCM security administrator or an IdP integration in place will find manual access management error-prone at scale.

Bottom line

Oracle HCM delivers a comprehensive, HR-authoritative identity foundation when its provisioning rules and dual-layer security model are configured correctly - but that configuration is non-trivial and does not self-maintain.

Every app downstream of Oracle HCM depends on those provisioning rules firing accurately and on the scheduled sync processes running on time; gaps in either produce access that lags reality.

Organizations already committed to the Oracle ecosystem and willing to invest in ongoing security administration will get the most from it; those without that capacity should plan explicitly for the operational overhead before relying on it as a sole access control layer.