Best Practices for User and Role Provisioning in HCM

These best practices and guidelines help you to identify the processes used for user and role provisioning in HCM. We'll present different examples and scenarios to explain how these processes should be used.

Understanding the proper execution of these processes helps support stability and manage resources responsibly.

User and Role Provisioning Processes

There are four processes for user and role provisioning. You should run only one of these processes at a time. These processes should never overlap. Make sure you allow time for one process to complete before scheduling another process.

Here are the four user and role provisioning processes:

Process

Purpose

How Often

Usage

Best Practices

Send Pending LDAP Requests

Sends to the LDAP directory the requests related to user account provisioning as well as the requests for adding and removing user roles. You typically use this to process the provisioning requests created by bulk processes as well as to process future dated requests that are now active.

Daily

As needed

This job processes requests to:
  • Create, suspend, and reactivate user accounts
  • Provision and deprovision roles
  • Update person attributes for individual users including work emails
  • Send information about HCM data roles which originate in Oracle HCM Cloud
Parameters usage:
  • User Type
    • All - Process requests for all user types. Recommended.
    • Party - Process requests only for CRM parties.
    • Person - Process requests only for HCM persons.
  • Batch Size - Number of batches to process the pending requests
    • A - Uses batch size of 10. Recommended.
    • AF - Uses batch size of 10, but each run also processes requests that failed in previous runs.
    • 20 - Used only when processing very large number of requests.

For more information, see the topic Why You Should Run the Send Pending LDAP Requests Process.

DOs
  • Schedule at least once a day with Batch Size as A.
  • If required, schedule to run more than once a day based on your requirement. Make sure the next run starts at least 30 minutes after the completion of previous run.
  • Run the job after loading workers or users in bulk using HCM Data Loader. For more information, see the topic Processes to Run After Loading Data from the HCM Data Loader guide.

DON'Ts

  • Don't schedule to run in intervals of less than 30 minutes. Running the job too frequently can result in unnecessary processing overhead for the application and can result in performance issues.
  • Don't schedule to run with Batch Size as AF.
    • Batch Size AF should only be used to run the job manually to reprocess faulted requests after issues are resolved.
    • If scheduled to run with Batch Size AF, each time the job runs, it creates new LDAP requests for faulted requests to reprocess them. If the underlying issue for the fault is not resolved, it will keep creating new LDAP requests over and over again.
  • Don't schedule to run with Batch Size > 20. Default batch size is 10 (A) and recommended maximum batch size is 20.

Auto provision Roles for All Users

Evaluates roles membership for all users, including inactive users, against the role provisioning rules.

As needed

Rarely

This process compares all current user assignments with all current role mappings and creates required requests to add or remove roles to users.

Parameters Usage

  • Process Generated Role Requests - Indicates whether the job should process the generated LDAP requests
    • Yes - When the number of role requests generated is expected to be small, set the parameter to Yes so this job also processes the generated requests.
    • No - When thousands of role requests are expected to be generated, set the parameter to No, to defer the processing to next run of Send Pending LDAP Requests job.
  • Worker Assignment Status - Assignment status of workers for whom the autoprovisioning rules should be performed by the job
    • Active
    • Active, Suspended
    • Inactive
    • Suspended

To improve performance while processing large number of requests, enable Bulk Mode for this job.

DOs

Run the job once on demand for below scenarios:

  • Initial role assignment for existing users after creating role mappings
  • When new role-mapping rules are added or existing rules changed

For more information, see the topic Autoprovisioning.

DON'Ts

  • Don't schedule to run regularly since this job evaluates all the role-mapping rules and validates them for the entire user population, which is a costly operation.
    • After initial role assignments are done, role-mapping rules are performed incrementally every time workers are created/updated/terminated
    • More the number of role-mapping rules and number of users, the longer and costlier are the processing done by this job
  • Running the job too frequently can result in unnecessary processing overhead for the application and can result in performance issues.

Send Personal Data for Multiple Users to LDAP

Reconciles personal information changes in Oracle HCM Cloud with LDAP directory.

As needed

Rarely

For HCM person records updated in bulk, this process updates their personal data in LDAP to match with their data in Oracle HCM Cloud. This process updates First Name, Last Name, Email, and Manager attributes.

This process applies only to HCM person users and not to party users.

Parameters Usage
  • User Population
    • All users
    • Changed users only

For more information, see the topic Why You Send Personal Data to Identity Store.

DOs
  • Run once on demand with parameter All Users only as one-time synchronization of all user records to LDAP during initial implementation.
  • Run once on demand with parameter Changed users only after changing personal data of workers in bulk. The job then synchronizes personal data only for those changed users to LDAP. For more information, see the topic Processes to Run After Loading Data.
DON'Ts
  • Don't schedule to run regularly with parameter All Users, since each time the job is run, it creates an LDAP request for each user regardless of whether personal information was changed or not. If the job is scheduled, it creates two issues:
    • Create unnecessary LDAP requests for all users in the application causing the LDAP requests table to grow in size.
    • Cause unnecessary processing overhead for Send Pending LDAP Requests job and can result in performance issues.

Retrieve Latest LDAP Changes

Updates the Oracle HCM Cloud person records with data coming from the LDAP directory.

Very rarely

This process synchronizes all users and roles from LDAP directory to Oracle HCM Cloud. If a difference is noticed between roles provisioned to a user in Security Console and roles on the Manage User Account page, it is recommended to run this process.

This job does not have any parameters.

For more information, see the topic Retrieve Latest LDAP Changes.

DOs

Run once on demand in below scenarios:
  • After a release update
  • User/role records in Oracle HCM Cloud are out-of-synch with LDAP and confirmed by Oracle Support to run the job
DON'Ts
  • Don't schedule to run regularly since it is unnecessary processing and does not serve any functional purpose. All the user data are first created in Oracle HCM Cloud and synchronized to LDAP. User records aren't expected to be changed directly in LDAP so there is no requirement to retrieve changes regularly from LDAP to Oracle HCM Cloud.

Common Scenarios of User and Role Provisioning Processes

Let's go through several scenarios to better understand the user and role provisioning processes. Some of the processes have the potential to slow down your environment, so we recommend familiarizing yourself with these scenarios to understand the impact before scheduling a process.

Scenario 1: Importing New Hires Using HCM Data Loader

  • The User Account Creation option on the Manage HCM Enterprise Information page is set to Both person and party users. This setting ensures that the user account is automatically generated when each worker is imported.

  • New Hires are loaded by using HCM Data Loader to import the Worker.dat file.

  • User Account requests are created automatically for each imported person.

What you should do next:

After completing the import of New Hires using HCM Data Loader, run the Send Pending LDAP Requests process once. This job sends all pending user account create requests from the HCM Cloud to the LDAP directory.

What you should not do:

  • Auto provision Roles for All Users

  • Retrieve Latest LDAP Changes

  • Copy Personal Data for All Users to LDAP

Scenario 2: Changes in Manage Role Provisioning Rules in your Organization

Your organization is making changes to Manage Role Provisioning Rules by adding new role provisioning rules, or by updating existing role provisioning rules. These changes may impact how the roles should be assigned to new or existing users.

What you should do next:

After the update of auto provisioning mapping is completed:

  • Run the Auto provision Roles for All Users process once with default parameters.

This job will evaluate every user, including active and inactive users, and will update role memberships according to updated role auto provisioning rules. This is the only situation when you should run this process in a production environment.

Scenario 3: Workers were Imported Before Auto provisioning Mappings in Manage Role Provisioning Rules Were Created

Your organization imported workers and created user accounts for them without first creating role provisioning rules using the Manage Role Provisioning Rules task. Existing user accounts were not evaluated against new role provisioning rules.

What you should do next:

It's critical to avoid this situation. All role-provisioning rules should be created before the workers are loaded in bulk, at a minimum the Employee role rule must be created.

After the roles provisioning rules are created, run:

  • The Auto provision Roles for All Users process once with default parameters. This job evaluates, including active and inactive users, and will update role memberships according to updated role auto provisioning rules.

Scenario 4: Manual Update of Employee's Manager, First Name, Last Name, or Email

You have a short list of employees and you're going to use the application to update one of the following fields:

  • First Name

  • Last Name

  • Email

  • Manager

What you should do next:

Nothing. This HR transaction doesn't require any user provisioning related activities.

What you should not do:

Don't run or schedule any of the user and role provisioning processes after this HR transaction completes.

Scenario 5: Bulk update of Employee's Manager, First Name, Last Name, or Email

You're going to update the following employee (worker) fields in bulk using HCM Data Loader:

  • First Name

  • Last Name

  • Email

  • Manager

And, you're not sure if this change requires additional user-related activities.

What you should do next:

After importing the updated worker information using HCM Data Loader:

  • Run the Send Personal Data for Multiple Users to LDAP once.

    This job will update the LDAP records with person profile changes completed by the HCM Data Loader import. Be sure to run the job in Changed mode, not All Users mode.

  • Run the Send Pending LDAP Requests process only when email was updated. This keeps the LDAP directory in sync.

Scenario 6: Manual Update of Employee's Assignment Location

You have an employee who changed job locations. You're going to update their assignment location using the application interface. Changing the employee's location may affect their role assignment.

What you should do next:

Nothing. This HR transaction automatically evaluates this employee against the role auto provisioning rules. If any changes are required in this employee's role memberships, they will be automatically completed when you save your HR transaction.

What you should not do:

Don't run or schedule any of the user and role provisioning processes after this HR transaction completes.

Scenario 7: You manually added job roles to a person

You were asked to add job roles to the selected employee manually and you're not sure if there's anything else to do with the LDAP directory.

What you should do next:

Nothing. This HR transaction automatically processes pending LDAP requests for the selected employee.

What you should not do:

Don't run or schedule any of the user and role provisioning processes after this HR transaction completes.

Scenario 8: Workers were loaded with HCM Data Loader with suppressed user account creation

Workers were loaded with suppressed user account creation, Counter-intelligences = N, and you're not sure if there's anything else you need to do with the LDAP directory.

What you should do next:

Nothing. Imported workers aren't expected to have user accounts so there's no need to run any additional LAP-related processes.

What you should not do:

Don't run or schedule any of the user and role provisioning processes after this HR transaction completes.

Scenario 9: User accounts were created for existing person records using HCM Data Loader

Workers were loaded without creating user accounts. You're going to create user accounts for existing workers in bulk by using HCM Data Loader to import the properly prepared User.dat file. You're also assigning some manual roles to new user accounts using this same method.

You're concerned about auto provisioning roles and don't know if there's anything else to do with LDAP processes.

What you should do next:

  • After completing the import of the User.dat file using HCM Data Loader, run the Send Pending LDAP Requests once.

    This job sends all pending user account and role assignment requests from HCM to the LDAP directory. Every new user account will also be evaluated against the auto provisioning rules during the creation process.

What you should not do:

After loading user account requests with HCM Data Loader, don't schedule any of the following processes:

  • Auto provision Roles for All Users

  • Retrieve Latest LDAP Changes

  • Copy Personal Data for All Users to LDAP

Scenario 10: You need to run the Auto provision Roles for All Users process and have a large volume of user accounts

You want to run the process initially for employees with active assignments ahead of other assignment status. The Auto provision Roles for All Users process picks up all user accounts every time it runs. This might have a long runtime when there is a large volume of user accounts. You can overcome this using an optional filtering parameter, Employee's Assignment Status.

The Employee's Assignment Status parameter lets you process only those user accounts linked to workers, whose assignment is in the selected status. It can have one of the following values:

  • [Blank] - Default
  • Active
  • Active, Suspended
  • Inactive
  • Suspended

What you should do next:

After the update of auto provisioning is completed for the specific assignment status, run the Auto provision Roles for All Users process once with the default parameters. This job evaluates every user, including active and inactive users, and will update role memberships according to updated role auto provisioning rules. This is the only situation when you should run this process in a production environment.