1. Implementing Global Human Resources
  2. How You Communicate Person and Assignment Changes to Consumer Applications

How You Communicate Person and Assignment Changes to Consumer Applications

You may need to alert other Oracle Fusion applications when you make changes to person and assignment details to synchronize their information with Oracle Fusion Global Human Resources.

To share the changes made to person and assignment details with consumer applications, you need to run the Synchronize Person Records process. The process generates an HCM event, ChangedPersonDetails that consumer applications listen to.

HCM Synchronize Person Records process

The Synchronize Person Records process generates events and notifies about the person and assignment for Contingent Worker and Employee worker types only.

When you start the process, you can specify the start and end dates. The process generates events for the changes made between the start and end dates that you specified. If you don’t specify the dates, the process runs on the application date, and generates events for changes made on that date.

Note: If you make changes to person records daily, it's recommended that you schedule the Synchronize Person Records to run once daily at the end of the day (without specifying start and end dates). Don’t schedule the process multiple times in a day.

Note that in the Coexistence for HCM environment, you can run Synchronize Person Records after you upload person records to Oracle Fusion for the first time.

You must keep these points in mind when you run the Synchronize Person Records process:

  • When you run the process for the first time, specify the start date and end date. Start date refers to the date when the oldest existing record for that person was created in the application, and end date refers to the application date.

    Example for start date:

    Let's say a person was hired on 01/01/2009 as an employee. But their employment was cancelled for some reason. Though they're no longer an employee, their person record exists in the application. The date on which this person’s record was created in the application is their start date, which is 01/01/2009.

    Now, if the same person is rehired on 05/05/2015, then the hire date is 05/05/2015. But their start date still remains as 01/01/2009, which is the oldest record for that person in the application.

  • When you load person records subsequently, run Synchronize Person Records on the application date (without specifying the start and end dates).
  • To ensure optimum performance, ensure that the start date and end date of the process has a maximum difference of only up to 7 days.

This table summarizes the process parameters.

Parameter Data Type Default Value Purpose
From Date Date Application date (Today’s date) Used along with the To Date parameter. The date range identifies all changes stored in Oracle HCM Cloud that should generate an event. The date range must not be longer than 7 days.
To Date Date Application date (Today’s date) Used along with the From Date parameter. The date range identifies all changes stored in Oracle HCM Cloud that should generate an event. The date range must not be longer than 7 days.
After Batch Load Character No (N) Use this parameter when you are loading data through HCM Data Loader (HDL) or HCM Spreadsheet Loader (HSDL). The ChangedPersonDetails event is suppressed for these batch loading processes. Because of this data isn’t synchronized during the data load. To enable synchronization, you need to run the process with this parameter set to Yes. When this parameter is set to Yes, the process considers all changes during the period by considering these dates.
  • Effective_start_date
  • Last_update_date of the person or employment tables
When the parameter value is set to No, only the Effective_Start_Date is considered

When You Run the Process

Let’s look at the common use cases when you need to run the process and the parameters that you need to specify.

Use Case Execution Type Parameter Values Guidelines
When future dated hires or work relationships become effective. When pending workers are converted as employees or contingent workers. Daily (To handle future dated changes)
  • From Date: Null
  • To Date: Null
  • After Batch Load: No
 When you specify the dates as NULL, it’s assumed that the changes that happened on the application date (today’s date) must be picked up by the process.
When data load contains active employees or contingent workers. After loading data
  • From Date: Date when the data load started
  • To Date: Date when the data load completed
  • After Batch Load: Yes

Person or assignment data, or both is loaded in 1 or 2 days. Hence, the date range between loads is 1-2 days. When you provide the date range, ensure it’s less than 7 days, else the process will terminate with a warning message.
When future-dated hires or work relationships become effective as on today's date, OR when pending workers are converted to employees or contingent workers, and are effective as of today’s date Future-dated changes that are effective on that day

Changes Notified to Consumer Applications

When you run Synchronize Person Records, the process generates the ChangedPersonDetails event when you make changes to the following person and assignment details:

  • Person details:

    • Name

    • Work email

    • Work phones

    • Service dates

  • Assignment details:

    • Job

    • Position

    • Department

    • Work location

    • Work location address

    • Manager

    • Work type

Note: Please note these important considerations:

  • The ChangedPersonDetails event isn't generated if you make changes to the following workforce structure setup objects.

    • Job

    • Position

    • Department

    • Work location

    • Work location address

  • The event isn't generated for data changes in these cases.

    • Changes to ex-employees and ex-contingent worker records as of the application date (current date).

    • Changes to employee records with a future hire or start date.