Workday to Okta provisioning sync failed: worker ID mapping error troubleshooting

TL;DR

Make the worker identifier identical in Workday, the integration mapping, and the Okta profile, then re-run one hire. Find which field Workday sends as the worker id, which Okta attribute receives it, and where the two diverge in format, leading zeros, or rehired-worker reuse. Correct the divergence at the source, clear the failed import rows, and import a single affected worker to prove the match before resuming the full feed.

Workday to Okta provisioning sync failed: worker ID mapping error

Use this when

• Okta profile sourcing from Workday shows import errors naming worker or employee identifiers.
• Some hires import cleanly while rehires, transfers, or contingent workers fail.
• The Okta profile holds a blank or mismatched employeeNumber or external source attribute.

Not for this skill when

• The Workday integration itself cannot connect or the report returns no rows. Fix the integration connection first.
• All imports stopped after an Okta admin change freeze. Wait for the freeze to lift and re-check.

Steps

1. Open Okta, go to Directory, Profile Editor, and the Workday sourcing app profile, and note the attribute mapped from the Workday worker id, including any transform applied during import. Then open one failed user in the import results and copy the incoming value Okta received. Verify: you have the exact incoming value and its target attribute name
2. In Workday, open the worker record for the same person and read the Worker ID, Employee ID, and Contingent Worker ID fields, plus the integration field used by the Okta report or web service. Compare character by character with the Okta incoming value, watching for leading zeros, prefixes, or a different id type for contingent staff. Verify: the differing field or format is identified
3. Decide the single canonical identifier with HR and IT together, usually the immutable Workday Worker ID, and align all three places: the Workday integration output, the Okta app profile mapping, and the Okta universal profile attribute. Remove competing mappings that write the same attribute from a second source. Verify: only one mapping writes the identifier attribute and its source is the agreed field
4. For rehired workers, confirm Workday reuses the original worker record rather than creating a second one, and confirm Okta matching rules use the identifier plus email rather than email alone. Merge or correct any duplicate Okta profile created during the failure window so history stays on one account. Verify: the rehire resolves to one Workday record and one Okta profile
5. Run a targeted import for one previously failed worker from the Okta Workday app Import tab, confirm the profile is matched or created with the correct identifier, and check that group rules and app assignments fire as expected for that person. Verify: the single import succeeds with no mapping error
6. Resume the full scheduled import and review the first cycle results for the same error class, then add a weekly spot check comparing a sample of Workday worker ids with Okta profile values. Verify: the full cycle completes and the sample comparison shows no mismatches

Why it happens

Workday holds several identifiers per person and different worker types expose different ones, while Okta matching needs one stable value that arrives identically on every import. When the integration sends Employee ID for staff but a different id for contingent workers, or a transform strips leading zeros, Okta sees a new or unmatchable person and the sync reports a mapping error. Rehires amplify the problem because a fresh worker record breaks the link to the existing Okta profile. A single canonical id, written by a single mapping, restores deterministic matching.

Variants and edge cases

Contingent workers fail while employees pass

Check whether the integration report filters or field set excludes contingent worker ids. Extend the report to include the contingent id mapped into the same canonical attribute instead of building a second import path.

Errors start after a Workday ID reformat

If HR renumbered workers, plan a one-time Okta attribute rewrite from the old to the new values before resuming imports, otherwise every existing profile looks like a mismatch at once.

Transfers fail but new hires pass

Transfers change cost center and manager but must never change the worker id. If the transfer feed sends a position id in the worker field, correct the report field selection and re-import the affected transfers.

Compatibility: Applies to Okta Workday profile sourcing and API-driven imports fed by Workday reports or web services. Requires Okta admin rights and Workday integration reporting access.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_X5PmBnv3aC8KoKe8CE7C9Q