What causes the HDL 'Worker assignment not found' error?

The HDL 'Worker assignment not found' error occurs when the Assignment record in your .dat file references a Worker (PersonId or SourceSystemId) that either doesn't exist in Oracle HCM, hasn't been committed yet in the same load, or whose identifier doesn't match the system of record. The most common causes are SourceSystemId mismatch, wrong PersonId, or loading assignments before the parent Worker record is committed.

Can I use SourceSystemId instead of PersonId in HDL?

Yes. If you loaded the Worker using a SourceSystemId and SourceSystemOwner in your original Worker .dat file, you can use those same values in the Assignment file instead of PersonId. The key is consistency — use the same system of record across both objects.

Why does my HDL load fail even though the worker exists?

If the worker exists but the assignment fails, check: (1) Are you using the correct identifier type (PersonId vs SourceSystemId)? (2) Is the EffectiveStartDate in your Assignment record within the worker's effective date range? (3) Is the LegalEntityId or BusinessUnitId valid? (4) Is ActionCode and ActionReasonCode a valid combination?

HDL / Data Loader

HDL Error: Worker Assignment Not Found — Root Cause & Fix

Q: How do I find the PersonId for a worker in Oracle HCM?

Query PER_ALL_PEOPLE_F with: SELECT PERSON_ID, PERSON_NUMBER, FULL_NAME FROM PER_ALL_PEOPLE_F WHERE TRUNC(SYSDATE) BETWEEN EFFECTIVE_START_DATE AND EFFECTIVE_END_DATE AND PERSON_NUMBER = '<your_number>'. The PERSON_ID is the internal Oracle ID used by HDL.

March 28, 2026 · 1,400 words

Advance Your Oracle HCM Career

Structured courses trusted by HCM professionals worldwide.

Udemy Oracle Fusion HCM Cloud — Complete Training Browse Courses → Pluralsight Oracle HCM Cloud Learning Path Start Free Trial →

You're loading assignment data through Oracle HCM Data Loader (HDL) and hit this error mid-run:

HDL Error: Worker assignment not found for the given identifier.
Object: WorkerAssignment | Line: [N]

The process aborts, your assignment records don't commit, and now you need to figure out which of several possible root causes is actually the problem. This guide walks through every cause in priority order so you can fix it in one pass.

How HDL Resolves Assignment Records

When HDL processes a WorkerAssignment object, it needs to link the assignment to a parent Worker. It does this by looking up the worker via one of three identifier paths:

PersonId — Oracle's internal numeric ID for the person
PersonNumber — The human-readable employee number
SourceSystemId + SourceSystemOwner — Your external system's identifier (e.g., the ID from your HRIS)

If none of these resolve to an existing, active worker record, you get "Worker assignment not found." The error message is the same regardless of which identifier failed — which is why it's so frustrating to debug.

Root Cause #1: PersonId or PersonNumber Mismatch

The most common cause. Your .dat file contains a PersonId or PersonNumber that doesn't exist in Oracle HCM, or was typed incorrectly.

Validate with this SQL before loading:

-- Verify the worker exists and is active
SELECT
  PERSON_ID,
  PERSON_NUMBER,
  FULL_NAME,
  EFFECTIVE_START_DATE,
  EFFECTIVE_END_DATE
FROM PER_ALL_PEOPLE_F
WHERE PERSON_NUMBER = '<your_person_number>'
  AND TRUNC(SYSDATE) BETWEEN EFFECTIVE_START_DATE AND EFFECTIVE_END_DATE;
      

If this returns no rows, the worker either doesn't exist, isn't active as of today, or the person number is wrong. Check your source data.

Tip: HDL is case-sensitive for PersonNumber. "EMP001" and "emp001" are different identifiers. Always match the exact casing from Oracle.

Root Cause #2: SourceSystemId Mismatch

If you originally loaded workers using SourceSystemId and SourceSystemOwner, you must use the same values in your assignment .dat file. A common mistake is switching from SourceSystemId to PersonId between loads — HDL can't automatically cross-reference them.

Verify the SourceSystemId mapping:

-- Check if SourceSystemId is mapped in HRC_SOURCE_SYSTEM_OWNER
SELECT
  SOURCE_SYSTEM_ID,
  SOURCE_SYSTEM_OWNER,
  OBJECT_TYPE,
  OBJECT_ID
FROM HRC_SOURCE_SYSTEM_OWNER
WHERE SOURCE_SYSTEM_ID = '<your_source_id>'
  AND SOURCE_SYSTEM_OWNER = '<your_source_system>'
  AND OBJECT_TYPE = 'PERSON';
      

If no row is returned, the SourceSystemId was never registered, or was registered under a different SourceSystemOwner. You'll need to either use the PersonId directly, or re-register the source mapping.

Root Cause #3: Loading Order — Assignment Before Worker

HDL processes objects within a single load file in sequence. If your Worker record and Assignment record are in the same HDL .zip file but your Assignment rows appear before the Worker rows in the file ordering, the assignment will fail validation because the parent worker hasn't been committed yet.

Common scenario: You have a single Worker.dat and WorkerAssignment.dat in the same zip. HDL processes them alphabetically. "Worker.dat" comes after "WorkerAssignment.dat" alphabetically — so assignments are processed first.

Fix: Rename files to enforce order. Prefix with numbers:
01_Worker.dat
02_WorkerAssignment.dat

HDL processes .dat files in the order they appear in the zip. Numeric prefixes guarantee correct sequencing.

Root Cause #4: EffectiveStartDate Outside Worker's Date Range

Even if the PersonId is correct, if your assignment's EffectiveStartDate falls before the worker's earliest effective date or after their termination date, Oracle will reject the assignment as "not found" — because no valid worker record exists at that point in time.

-- Check the worker's full date range
SELECT
  PERSON_ID,
  FULL_NAME,
  MIN(EFFECTIVE_START_DATE) AS EARLIEST_DATE,
  MAX(EFFECTIVE_END_DATE) AS LATEST_DATE
FROM PER_ALL_PEOPLE_F
WHERE PERSON_NUMBER = '<your_person_number>'
GROUP BY PERSON_ID, FULL_NAME;
      

Your assignment's EffectiveStartDate must fall within this window. If the worker was terminated before your assignment date, you'll need to either correct the date or rehire the worker first.

Root Cause #5: Wrong LegalEntityId or BusinessUnitId

A less obvious cause: the LegalEntityId or BusinessUnitId in your assignment record doesn't exist or isn't active. Oracle validates these reference data IDs during assignment creation, and the error message is often misleading — it says "assignment not found" when the actual issue is an invalid org reference.

-- Validate LegalEntityId
SELECT
  ORGANIZATION_ID,
  NAME,
  INTERNAL_EXTERNAL_FLAG
FROM HR_ORGANIZATION_UNITS_F_TL
WHERE ORGANIZATION_ID = <your_legal_entity_id>
  AND TRUNC(SYSDATE) BETWEEN EFFECTIVE_START_DATE AND EFFECTIVE_END_DATE
  AND LANGUAGE = 'US';
      

Diagnostic Checklist

Work through this table in order. The first failed check is usually your root cause:

#	Check	How to Verify	Fix
1	Worker exists in Oracle HCM	Query PER_ALL_PEOPLE_F by PersonNumber	Correct PersonNumber or load worker first
2	PersonId or SourceSystemId matches exactly	Query HRC_SOURCE_SYSTEM_OWNER	Use consistent identifier type across all .dat files
3	Load file ordering is correct	Inspect .zip file contents	Rename files with numeric prefixes (01_, 02_)
4	EffectiveStartDate within worker date range	Query MIN/MAX effective dates from PER_ALL_PEOPLE_F	Correct the assignment date or rehire the worker
5	LegalEntityId and BusinessUnitId are valid	Query HR_ORGANIZATION_UNITS_F_TL	Correct org IDs to match active Oracle references
6	ActionCode + ActionReasonCode combination is valid	Query HR_LOOKUPS for LOOKUP_TYPE = 'EMP_ACTION'	Use a valid ActionCode/ActionReasonCode pair for the assignment type

Sample HDL WorkerAssignment .dat Structure

Here's a minimal, correct WorkerAssignment .dat file that avoids the most common errors:

METADATA|WorkerAssignment|SourceSystemOwner|SourceSystemId|PersonId|AssignmentNumber|EffectiveStartDate|EffectiveEndDate|AssignmentType|ActionCode|LegalEntityId|BusinessUnitId|GradeId|JobId|LocationId

MERGE|WorkerAssignment|LEGACY_HRIS|ASSIGN-00001||E-10023|2024-01-01|4712-12-31|E|HIRE|300000001234567|300000001234568|300000001234569|300000001234570|300000001234571

Note: In this example, PersonId is left blank and SourceSystemId is used instead. Pick one identifier type and leave the other blank — don't try to supply both.

HDL Error Log Locations

To find the exact error for a failed load:

Go to HCM > Data Exchange > Import and Load Data
Find your load in the list — click the load set name
Click View Error Report in the Actions menu
The error log will show the exact line number and error code for each failed record

The detailed error report often includes the actual identifier Oracle tried to look up, which makes it much easier to spot the mismatch versus checking your .dat file manually.

Need to Look Up Oracle HCM Table Structures?

Search our database of 35,000+ Oracle Fusion Cloud tables. Find exact column names, data types, and relationships for PER_ALL_PEOPLE_F, PER_ALL_ASSIGNMENTS_M, and every HCM table in the schema.

Search Oracle HCM Tables →

Summary

The HDL "Worker assignment not found" error always traces back to one of six root causes, ranked by frequency:

Wrong PersonId or PersonNumber — validate against PER_ALL_PEOPLE_F
SourceSystemId mismatch — verify via HRC_SOURCE_SYSTEM_OWNER
Wrong file load order — rename files with numeric prefixes
EffectiveStartDate out of range — check worker's date window
Invalid LegalEntityId or BusinessUnitId — validate org IDs
Invalid ActionCode combination — check HR_LOOKUPS

Run the validation SQL queries before submitting a load, and you'll catch most of these errors before HDL ever processes the file.