We’re experiencing significant delays in our onboarding workflow on ohcm-24a. New hire provisioning tasks that should trigger immediately are taking 24-36 hours to complete, blocking system access for employees starting their first day.
The workflow is supposed to execute synchronously - creating AD accounts, assigning licenses, and generating IT tickets through our ServiceNow integration. We’ve noticed the job scheduler shows tasks in ‘pending’ status for extended periods.
Here’s what we’re seeing in the workflow logs:
<WorkflowTask id="IT_PROVISION" status="PENDING">
<Trigger>NEW_HIRE_COMPLETE</Trigger>
<ScheduledTime>2025-03-13T08:00:00Z</ScheduledTime>
<ActualExecution>2025-03-14T14:30:00Z</ActualExecution>
</WorkflowTask>
The IT ticketing API integration seems to lack proper retry logic when the external system is busy. Has anyone dealt with similar synchronous execution issues or job scheduler configuration problems in their onboarding workflows?
I’ve seen this pattern before. The workflow engine in ohcm-24a changed how it handles external API calls. Check your BPM configuration - there’s a timeout setting that defaults to 30 seconds. If ServiceNow doesn’t respond within that window, the task gets queued for retry but the scheduler treats it as low priority. You might need to adjust the workflow execution mode from asynchronous to synchronous for critical provisioning steps.
Two things to investigate: First, the synchronous workflow execution might be timing out due to ServiceNow latency. You need exponential backoff in your retry logic. Second, check if your IT ticketing API integration is using the correct authentication method - token refresh issues can cause silent failures that appear as delays. I’d recommend enabling detailed logging on the integration endpoint to see exactly where the bottleneck is. The 24+ hour delay suggests the job scheduler is only picking up failed tasks during its daily maintenance window rather than immediate retry cycles.
Have you checked the integration agent’s processing capacity? In ohcm-24a, the default agent configuration limits concurrent API calls to 5. During peak onboarding periods, this creates a queue. You can increase this in the Integration Cloud configuration, but monitor your ServiceNow instance capacity too. The lack of proper retry logic is concerning - your integration should implement circuit breaker patterns to handle downstream failures gracefully rather than just timing out and waiting for the scheduler.
I dealt with this exact issue last quarter. The problem is multi-layered and requires addressing all four focus areas systematically.
Synchronous Workflow Execution:
Your workflow is configured for synchronous execution but the external API calls are failing silently. Modify your workflow to use the ‘Wait for Callback’ pattern instead of blocking synchronous calls:
<WorkflowTask id="IT_PROVISION" executionMode="ASYNC_CALLBACK">
<CallbackEndpoint>https://your-hcm.oracle.com/callback</CallbackEndpoint>
<TimeoutAction>ESCALATE</TimeoutAction>
</WorkflowTask>
Job Scheduler Configuration:
Navigate to Setup and Maintenance > Search: ‘Scheduled Processes’ > Find ‘Onboarding Integration Processor’. Change the schedule from the default 4-hour interval to 15-minute increments:
- Schedule Type: Interval
- Frequency: Every 15 minutes
- Priority: High
- Max Runtime: 30 minutes
Also increase the job scheduler thread pool: Tools > Integration > Configuration > Set ‘maxConcurrentJobs’ to 20 (from default 5).
IT Ticketing API Integration:
Implement proper retry logic with exponential backoff in your integration code. Here’s the pattern:
// Pseudocode - Retry logic implementation:
1. Set maxRetries = 3, baseDelay = 5 seconds
2. For each API call attempt:
- Try POST to ServiceNow endpoint
- On failure: wait (baseDelay * 2^attemptNumber) seconds
- Log failure reason and retry count
3. After max retries: create fallback IT ticket via email
4. Send notification to IT ops team
// Reference: Oracle Integration Cloud Error Handling Guide
Add connection pooling configuration:
- Min Pool Size: 5
- Max Pool Size: 20
- Connection Timeout: 10 seconds
- Read Timeout: 30 seconds
Retry Logic Architecture:
Implement a dead letter queue for failed provisioning tasks:
- Create custom object ‘Failed_Provisioning_Tasks__c’ to track failures
- Configure integration to write failed tasks to this queue
- Set up separate scheduled job to process dead letter queue every hour
- Implement circuit breaker: after 3 consecutive ServiceNow failures, switch to email-based fallback for 30 minutes
Additional Monitoring:
Enable detailed integration logging:
- Tools > Integration > Logging > Set level to ‘FINE’ for onboarding integrations
- Create alert when queue depth exceeds 10 pending tasks
- Dashboard widget showing average provisioning time
Validation Steps:
- Test with single new hire in non-production environment
- Verify task completes within 15 minutes
- Simulate ServiceNow timeout - confirm retry logic triggers
- Check audit trail shows all retry attempts
- Validate fallback mechanism activates after max retries
After implementing these changes, our provisioning time dropped from 24+ hours to under 20 minutes, even during peak periods. The key is treating external integrations as unreliable by design and building resilience at every layer.
Look at your transaction boundaries in the workflow definition. If the entire onboarding process is wrapped in a single transaction, any external API timeout will roll back the whole thing and force a complete restart. Break it into smaller transactional units with savepoints. Also verify the job scheduler’s thread pool allocation - if you’re running multiple integrations simultaneously, they might be starving each other of resources.