A hire is marked in ICIMS. The offer is accepted. And then nothing shows up in Workday, HR asks where the new employee record is, and the recruiter is refreshing the candidate profile hoping it changes. If you typed “ICIMS Workday integration not syncing” into a search bar, this is the post we wish existed the first time we were asked that question at 4:45 on a Friday.
We have run and supported ICIMS to Workday connections for mid-market and enterprise TA teams, and the pattern is consistent. The integration itself is rarely the problem. Something around it changed: a password, a security policy, a cost center code, a workflow status, a tenant refresh. This guide walks through the seven causes we check, in the order we check them, and the fix for each one.
Where to look first: Workday, then ICIMS
Most teams start on the ICIMS side because that is where the recruiter lives. We do the opposite. Workday keeps a detailed log of every integration run, and reading that log first tells you which of the seven causes you are dealing with before you touch a single ICIMS setting.
In Workday, open Process Monitor, set the Process Type to Integration, and filter to the date range when the missing hires should have arrived. Each run shows a status. The ones that matter here are Completed, Completed with Warnings, Completed with Errors, Failed, and Terminated. Open the event and go to the Messages tab. That is where the actual error text lives. The summary status only tells you whether Workday finished running.
If no integration event exists at all for the window, the run never started. Check Scheduled Future Processes in Workday to confirm the schedule is still active, and check the connector configuration for credentials or endpoint changes (Causes 1 and 7).
Then move to ICIMS. Open the candidate’s profile on the affected requisition and confirm three things: the person actually reached the mapped trigger status, the hire fields the connector requires are populated, and the connector’s error notification (email or a status written back to the record, depending on how your connector was provisioned) did not already tell you the answer. If you inherited the integration and nobody can name the trigger status, our guide to ICIMS Workday integration setup covers how the pieces fit together before you start diagnosing.
Cause 1: The Workday Integration System User expired or is locked
The symptom. Every run in Process Monitor shows Failed with an authentication message: 401 Unauthorized, invalid credentials, or security credentials invalid. Often more than one integration stops on the same day, because they share the same Integration System User (ISU).
Why it happens. The ICIMS connector signs in to Workday with an ISU. If that account was created without an exemption from the tenant password expiration rules, the password expires on schedule like any other user’s, and Workday gives no advance notice. The same thing happens when someone rotates the password during a security review and forgets the ICIMS connector still holds the old one, or when the ISU gets locked after repeated failed attempts from a stale credential.
The fix. In Workday, have the HRIS team run Maintain Password Rules and add the ISU to the System Users exempt from password expiration field. Confirm the ISU was created through Create Integration System User with Session Timeout Minutes set to 0 so sessions do not expire mid-run. Reset the password, avoiding the characters &, “, and >, which cause problems in some integration credential fields. Then update the Integration Password stored in the ICIMS connector configuration and re-run the last failed event.
Cause 2: Security policy changes were never activated
The symptom. Authentication succeeds, but the run ends Completed with Errors or Failed with a permission message. A specific object (pre-hire, job requisition, compensation) cannot be read or written. Sometimes this appears right after a Workday release or after HRIS “cleaned up” security groups.
Why it happens. The ISU sits in an Integration System Security Group, and that group gets its rights from domain security policies assigned through Maintain Permissions for Security Group. Two things go wrong. First, a required domain is missing or has Get only where the connector needs Get and Put (creating a pre-hire needs write access to Pre-Hire Data domains, for example). Second, someone made the right change but never ran Activate Pending Security Policy Changes, so the change exists on paper and not in the tenant. Workday will not apply it until that task runs.
The fix. Read the exact object named in the Messages tab. Have the HRIS team compare the ISU security group’s domain permissions against the connector’s documented requirements, add the missing Get or Put access, and run Activate Pending Security Policy Changes with a comment that names the ICIMS connector so the audit trail is clear. If the connector also initiates a business process such as a compensation change, confirm the matching business process security policy includes the ISU’s group.
Cause 3: Reference data drifted between the two systems
The symptom. Most hires sync and a handful do not. The failures cluster by department, location, or business unit. Messages name a value that “does not exist” or “is not valid”: a cost center, a supervisory organization, a location, a job profile, or a company.
Why it happens. Workday is the system of record for organizational data, and the ICIMS integration documentation is explicit that lookup data (company, departments, locations, job family, positions) syncs from Workday to ICIMS on a schedule, once a day in the Workday Recruiting integration. When HR reorganizes a supervisory org, retires a cost center, or renames a location, ICIMS keeps offering the old value on the requisition until the next lookup sync, and any requisition created in the gap carries a code Workday no longer accepts. Format mismatches cause the same failure: “CC-4501” on the ICIMS side and “4501” in Workday are different values to an integration.
The fix. Confirm the lookup sync ran and completed successfully before you chase individual hires; the ICIMS documentation states that lookup synchronization must complete before applications can flow. Then correct the requisition in ICIMS to the current Workday value and resend the hire. For the long term, agree with HRIS that organizational changes in Workday get announced to TA operations the same day, and add a monthly spot check comparing the ICIMS picklists to the Workday values. This is one of the most common findings in an ICIMS system audit, and it is almost always a process gap rather than a technical one.
Cause 4: The candidate never reached the trigger status
The symptom. Process Monitor shows nothing wrong. Runs are Completed. The hire simply is not in them. On the ICIMS side, the recruiter is certain the candidate was “hired.”
Why it happens. The connector sends a candidate when the person reaches one specific mapped workflow status on the requisition. The Workday Recruiting integration documentation describes applications posting in real time when a workflow status changes, and HCM hire connectors work the same way with a hire status. Three things break that chain. The recruiter moved the candidate to a similar looking status that is not the mapped one (a custom “Offer Accepted” bin instead of the mapped “Hired” status). An admin renamed, reordered, or replaced the status during a workflow profile change without telling whoever owns the integration. Or a workflow rule that was supposed to move the candidate automatically did not fire, which is its own diagnostic; we covered those cases in ICIMS workflow rules not triggering.
The fix. Open the candidate’s workflow history on the requisition and confirm the exact status name and timestamp. Compare it to the status the connector is configured to watch. If they differ, move the candidate to the mapped status (or back and forward through it, if the connector only fires on a change into that status). If a workflow profile change caused it, update the connector mapping and document the status as protected so it does not get edited again during the next cleanup.
Cause 5: A required hire field is missing or in the wrong format
The symptom. Completed with Errors, one record at a time. Messages name a specific field: start date, legal name, address, compensation, pay frequency, or an identifier.
Why it happens. Workday enforces structure that ICIMS does not. Addresses need to arrive as separate components (street, city, region, postal code, country), not a free text block. Compensation needs an amount plus a currency plus a frequency. Dates need a consistent format. And any field the connector maps as required must have a value, even if the recruiter’s process does not normally capture it until onboarding. When an ICIMS admin adds a new custom field or changes a field to optional on the offer iForm, the hire record starts arriving with a gap the connector cannot fill.
The fix. Use the Messages tab to identify the field, correct the value on the ICIMS candidate or offer record, and resend. Then trace why it was empty. Usually the answer is that the field is not required at the trigger status in ICIMS, so make it required at that status or add a workflow rule that stops the status change when the field is blank. Keeping the offer and hire data complete at the point of hire is also the fastest way to make ICIMS onboarding setup pay off, because the same fields feed the new hire’s onboarding tasks.
Not sure which of the seven causes you have?
On a 30 minute call we will walk through your Workday Process Monitor messages and your ICIMS trigger status with you and tell you which cause applies to your instance, and what it will take to fix it. One of our clients measured 90% fewer ICIMS support tickets within 90 days of putting this kind of ownership in place.
Book a discovery callCause 6: Workday matched a duplicate or a former employee
The symptom. A rehire, a contractor converting to an employee, or an internal transfer does not sync, while brand new external hires do. Messages reference an existing pre-hire, worker, or identifier.
Why it happens. Workday will not quietly create a second person record when it recognizes an identifier, an email, or a name and date of birth combination it already holds. Integrators who build on the ICIMS Workday connection routinely add logic for exactly this: detect a current contractor, end the contract before initiating the hire, and flag prior employees for manual HR review based on employment history. If your connector has no rehire path, those records stop at the door.
The fix. For the record in front of you, HR completes the hire or rehire in Workday against the existing pre-hire or worker and closes the loop in ICIMS by hand. For the pattern, agree on a rehire process: either the connector is configured to match on employee ID and route rehires to a review queue, or recruiters flag internal and returning candidates before the trigger status so HR expects them. We also recommend merging duplicate candidate profiles on the ICIMS side before they reach the integration, since two profiles for one person is the most common way a rehire arrives looking like a new hire.
Cause 7: A tenant refresh, credential rotation, or endpoint change
The symptom. Everything worked last week. Nothing changed in ICIMS. Now the runs fail to connect, or they connect to the wrong tenant and the hires appear in sandbox instead of production.
Why it happens. The connector holds four pieces of Workday credentialing: the Web Services URL, the tenant name, the Integration User, and the Integration Password. Any of them can change without anyone telling TA. Workday sandbox refreshes copy production over the sandbox and can overwrite test credentials and security assignments. IT rotates the ICIMS API user’s client secret during a review. The Workday web services endpoint moves to a new data center. The network team tightens an allowlist and drops the connector’s endpoints; the ICIMS documentation calls out that traffic to the connector’s regional endpoints must be allowlisted. Each one presents as an integration that stopped for no reason.
The fix. Re-validate all four credentialing values against what Workday currently expects, confirm the allowlist with your network team, and re-run the failed event. Then write the connector’s dependencies down in one place: which ISU, which endpoints, which ICIMS API user, and who to notify before any of them change. Sandbox refreshes deserve their own line item on that list.
How to keep the ICIMS Workday integration from stopping again
Every one of the seven causes above is preventable with ownership and a short routine. Here is the one we set up for clients.
The payoff is measurable: fewer tickets, fewer manual hires, and a shorter time from offer to day one. The numbers behind that claim are on our ICIMS ROI results page. If your team does not have the capacity to run that routine, this is exactly the kind of recurring work our ICIMS managed services plan covers on a flat monthly basis, alongside the workflow and notification maintenance that usually gets deferred. And when the connector itself needs to be rebuilt or extended, for example to add a rehire path or a compensation change, that is work for an ICIMS integration consultant who has done it on both the ICIMS and Workday sides.
Frequently asked questions
Get your hires flowing into Workday again
Bring the Messages tab export and your trigger status to the call. We will identify the cause, tell you whether it is a configuration fix or a connector change, and map out the routine that keeps it from coming back.
Book a discovery call
