Onboarding integration fails to send new hire data to external HRIS platform

HCM Workday HCM
, , , , , , , ,
1

Our onboarding integration to push new hire information to our external HRIS system has stopped working. The integration completes without errors in Workday, but no data appears in the target system.

I’ve verified the connection details are correct and the endpoint is accessible. The integration logs show successful execution, but when I check the external system, none of the new hires from the past week are present.

Integration log snippet:


Integration: NEW_HIRE_SYNC
Status: Success
Records Sent: 15
HTTP Response: 200 OK

Despite the success status, our HRIS vendor confirms they’re receiving no data. The data mapping looks correct in the template, but something is clearly breaking in the transmission. Any ideas on what could cause this disconnect between Workday showing success and the external system receiving nothing?

2

Look at your data mapping for null value handling. Sometimes integrations succeed in Workday but the external system silently drops records with null values in non-nullable fields. Review your transformation rules and add default values or conditional logic for optional Workday fields that might be required in the HRIS system. Also check if your new hire data includes all mandatory fields like start date, department code, and manager ID in the format the external system expects.

3

This is a classic case of successful transmission with silent data rejection. Let me address all three focus areas systematically.

Data Mapping Validation: Your integration shows 15 records sent, but the external system receives nothing. This indicates your data mapping is producing output, but it’s not in the format the HRIS expects. Here’s how to diagnose:

First, export a sample payload from your integration event logs. Navigate to Integration Systems → Integration Events → Select your NEW_HIRE_SYNC integration → View Details → Download Payload. Compare this against your HRIS vendor’s API documentation.

Common mapping issues to check:

  • Date format: Workday typically outputs ISO 8601 format (2025-04-22T10:15:00Z), but your HRIS might expect MM/DD/YYYY
  • Employee ID format: Verify you’re sending the correct ID type (Employee_ID vs Contingent_Worker_ID)
  • Required vs optional fields: Your HRIS may have made previously optional fields mandatory
  • Nested object structures: Ensure address and contact information are properly nested

Connection Details Investigation: Your 200 OK response is misleading. Many REST APIs return 200 for received requests but process validation asynchronously. Here’s what to verify:

  1. Authentication scope: Your OAuth token might lack write permissions. Check the token scope includes ‘employee.write’ or equivalent.

  2. Endpoint versioning: Confirm you’re hitting the correct API version. Some HRIS platforms maintain multiple API versions simultaneously.

  3. Request headers: Verify Content-Type is set correctly (application/json vs application/xml).

  4. Test with Postman: Use the exact payload from Workday and send it manually to isolate whether the issue is in Workday’s transmission or the external system’s reception.

Integration Logs Deep Dive: The summary logs are insufficient. You need detailed transaction logs:

In Workday Studio, enable verbose logging:


Log Level: DEBUG
Log Categories: Integration_Events, Data_Mapping, HTTP_Transport

Then run your integration and examine:

  • Pre-transformation data (raw Workday data)
  • Post-transformation data (mapped payload)
  • HTTP request headers and body
  • Complete HTTP response including headers

Coordinate with your HRIS vendor to enable their inbound API logging simultaneously. Compare timestamps to match requests with their logs.

Root Cause Resolution: Based on your symptoms, I suspect one of three issues:

  1. Field validation failure: Your HRIS added a new required field. Check their recent release notes. Add a default value or conditional mapping for any new required fields.

  2. Async validation: The 200 OK confirms receipt, but validation happens later. Ask your vendor for a webhook or callback URL to receive validation results. Update your integration to handle async responses.

  3. Silent authentication failure: Your token has read-only scope. Regenerate with full permissions and update the integration security credentials.

Immediate Action Plan:

  1. Contact your HRIS vendor and request their application logs for the timestamp range of your integration runs
  2. Enable DEBUG logging in Workday and capture a complete payload
  3. Test the payload manually using Postman with your current credentials
  4. Compare your payload structure against the vendor’s latest API documentation
  5. Add error handling to your integration to capture non-200 responses or async validation failures

The disconnect between Workday’s success status and the external system’s empty state almost always traces to either authentication scope limitations or data validation failures that aren’t properly surfaced in the API response. Focus your troubleshooting on those two areas first.

4

Check your authentication token. We had a situation where our OAuth token expired but the system was still accepting requests with a 200 response code, just not processing them. The connection test might pass because it uses a different authentication path than the actual data transmission. Regenerate your credentials and update them in the integration system configuration.

5

This sounds like a payload format mismatch. Even though you’re getting a 200 OK response, the external system might be rejecting the data silently. Check if your HRIS vendor recently changed their API schema. I’d recommend enabling detailed logging on both sides to see the actual payload being sent versus what they expect to receive.