HCM Data Loader migration fails for employee records with invalid lookup references

We’re migrating employee data from legacy HRMS to Oracle Fusion Cloud HCM (22D) using HCM Data Loader. Migration jobs consistently fail for approximately 1,200 employee records out of 8,500 total. Error logs indicate issues with lookup value references, but the HDL file format appears correct based on Oracle documentation.

The failed records contain employment history with job codes and location references that existed in our legacy system. We’ve validated the HDL file structure against the template, and the METADATA section matches requirements. However, errors reference “invalid lookup code” for fields like AssignmentCategory and LocationCode.

Has anyone encountered similar lookup mapping issues during HDL migrations? What’s the proper approach to identify which lookup values need to be created or mapped before the import?

Let me provide a comprehensive solution addressing all three key aspects:

HDL File Format and Validation: First, verify your HDL file structure follows the correct format. The METADATA section must declare all objects being loaded:


METADATA|Worker|SourceSystemOwner|SourceSystemId
METADATA|WorkRelationship|SourceSystemOwner|SourceSystemId|WorkerNumber
METADATA|WorkTerms|SourceSystemOwner|SourceSystemId|AssignmentCategory

Ensure your data rows reference the exact column headers defined in METADATA. Case sensitivity matters.

Lookup Value Mapping: The core issue is lookup code translation. Extract all unique values from your legacy data for fields that reference lookups (AssignmentCategory, LocationCode, JobCode, etc.). Query Fusion’s lookup tables to identify gaps:

SELECT lookup_type, lookup_code, meaning
FROM FND_LOOKUP_VALUES_VL
WHERE lookup_type IN ('EMP_ASSIGN_CATEGORY', 'LOCATION', 'JOB_CODE')
AND enabled_flag = 'Y';

Create a mapping spreadsheet with three columns: Legacy_Code, Fusion_Code, Notes. For assignment categories, map to standard Fusion values (E, C, P, N). For locations and jobs, either create the lookup values in Fusion first using Manage Common Lookups task, or map to existing similar values.

Modify your HDL extraction query to include mapping logic:

SELECT
  CASE legacy_assignment_type
    WHEN 'PT_EMP' THEN 'E'
    WHEN 'FT_EMP' THEN 'E'
    WHEN 'FT_CONTRACTOR' THEN 'C'
    ELSE 'E'
  END as AssignmentCategory
FROM legacy_employee_table;

Error Log Analysis: HDL generates detailed error logs in UCM (Content Server). Download the log file and search for patterns:

  • “Invalid lookup code” = value doesn’t exist in Fusion
  • “Invalid cross-reference” = parent record missing (e.g., Location not loaded yet)
  • “Duplicate key” = record already exists or primary key conflict

For your 1,200 failed records, extract the specific error messages and group by error type. This tells you whether it’s purely lookup issues or if there are data quality problems (null required fields, invalid dates, etc.).

Recommended Action Plan:

  1. Run the SQL query above to get all valid Fusion lookup codes for your target lookup types
  2. Create mapping logic in your ETL/extraction process - don’t try to fix 1,200 records manually
  3. For location and job codes that must be custom, use Manage Common Lookups to pre-create them in Fusion before rerunning HDL
  4. Test with a small batch (50-100 records) that previously failed
  5. Review the error log to confirm lookup issues are resolved
  6. Process the full 8,500 records once validation passes

Avoid creating custom lookup values unless absolutely necessary. Standard codes ensure compatibility with Oracle’s seeded functionality, reports, and future updates. If you must create custom values, document them thoroughly and include them in your upgrade testing scope.

The EnableDuplicateKeyMode=Y parameter mentioned earlier helps with reprocessing but won’t solve lookup validation failures - you must address the root cause through proper value mapping.


This draft is based on general Oracle Fusion Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

Classic lookup mismatch scenario. The error happens because your legacy job codes don’t exist as valid lookup values in Fusion HCM’s reference data. Run a query against FND_LOOKUP_VALUES table to see what’s actually configured in your Fusion environment versus what’s in your HDL file. The lookup type for AssignmentCategory would be ‘EMP_ASSIGN_CATEGORY’ - check if your legacy codes are there.

I dealt with this exact issue last year during our 22D migration. The problem is that HDL validation is strict about lookup references. You need to either:

  1. Pre-load the missing lookup values into Fusion before running HDL import
  2. Create a mapping table that translates legacy codes to valid Fusion lookup codes
  3. Update your HDL extract logic to map values during file generation

We went with option 3 - modified our extract queries to use CASE statements that mapped legacy codes to Fusion-compatible values. Saved us from manually creating hundreds of lookup entries. Also check your error log file carefully - it should specify the exact lookup type and invalid code for each failure.

Confirmed this resolves HDL failures—validating METADATA section column alignment and correcting lookup codes in WorkRelationship and WorkTerms objects eliminated our invalid reference errors in Oracle Fusion HCM.

Add the EnableDuplicateKeyMode parameter to your HDL properties file. Sometimes lookup validation fails even when values exist due to case sensitivity or trailing spaces. Also verify your METADATA section includes the correct object names - for Worker assignments it should be Worker.dat with proper BusinessUnit context.

Thanks for the suggestions. I extracted the error log and found that most failures are indeed lookup-related. The log shows codes like “PT_EMP” and “FT_CONTRACTOR” that don’t exist in Fusion’s EMP_ASSIGN_CATEGORY lookup. Our legacy system used custom codes that need mapping. I’m now building a crosswalk table to map these to Fusion’s standard values like “E” for Employee and “C” for Contingent Worker. Question: should I create custom lookup values in Fusion or stick to standard codes?

Strongly recommend using Fusion’s standard lookup codes rather than creating custom ones. Custom lookups can cause issues with:

  • Seeded reports and analytics that expect standard values
  • Future upgrades when Oracle modifies lookup structures
  • Integration with other Fusion modules

Map your legacy codes to standard Fusion values in your ETL layer. For assignment categories, use E=Employee, C=Contingent Worker, P=Pending Worker. This approach keeps your implementation aligned with Oracle best practices and reduces technical debt.

One more tip - use the HDL Helper tool or write a validation script before running the actual import. We created a Python script that reads the HDL file and queries Fusion lookup tables via REST API to pre-validate all lookup references. Catches these issues before you waste time on failed import jobs. The script checks FND_LOOKUP_VALUES for each lookup type referenced in your data file and flags any mismatches.