We’re running Oracle HCM Cloud 23D and experiencing significant synchronization delays when employee data changes in the Core HR module. Updates to employee records (address changes, job transfers, salary adjustments) are taking 2+ hours to propagate to our downstream systems (payroll, benefits, time tracking).
Our integration uses the REST API with event-driven workflow triggers that should fire when employee records are updated. I’ve checked the integration batch scheduling and the jobs are running every 15 minutes as configured:
Schedule: */15 * * * *
Endpoint: /hcmRestApi/resources/11.13.18.05/workers
Method: GET with lastUpdateDate filter
But even with this frequency, we’re seeing delays. The API rate limiting seems fine - we’re nowhere near the throttle limits. Has anyone dealt with similar latency in Core HR data synchronization? I’m wondering if there’s a better approach than polling the API every 15 minutes.
I want to address the event-driven workflow triggers you mentioned. In 23D, HCM supports business events that fire when specific actions occur (like employee hire, transfer, termination). However, these events are not enabled by default for all data changes. You need to explicitly configure which business events should trigger your integration workflows. Check your event subscription configuration in HCM - you might have subscribed to high-level events but not the granular field-level change events you need.
Have you checked the connection pooling settings for your REST API client? If your integration is creating a new connection for each API call, you’re adding overhead that compounds with the 15-minute polling frequency. Implement connection pooling with a minimum of 5-10 persistent connections. Also, verify that your API client is handling pagination correctly - if you have a large employee base, the API might be returning partial results and your integration needs multiple calls to get all updates, adding to the delay.
Looking at your API call pattern, you’re using a GET request with lastUpdateDate filter. This is a common approach but has limitations. The lastUpdateDate timestamp in HCM reflects when the record was last modified in the database, not when it was committed and approved. For employee changes that go through approval workflows, there can be a significant gap between the modification time and when the data is actually ready to be consumed. You need to add a status filter to your query to only pull records in ‘Active’ or ‘Approved’ status. This ensures you’re not reading incomplete data.
I agree with moving away from polling, but there’s another factor to consider. In 23D, Core HR has an internal workflow that processes data changes through multiple validation and approval stages. Even if your integration was real-time, you might still see delays because the data hasn’t finished processing through HCM’s internal workflows. Check if the records you’re trying to sync are in a ‘Pending’ or ‘In Progress’ state in HCM. Your integration might be reading the old values because the new values haven’t been committed yet.