Seasonal Hire Data Load with Duplicate People
Summit Retail is loading 2,500 seasonal hires across the US, Canada, and Mexico into Oracle Cloud HCM. There are six legal employers, 18 business units, and start dates spread over three months. The first HCM Data Loader batch of 400 workers produced errors: 'business unit is not valid for legal employer', duplicate person records, missing job codes, and assignments with no payroll. Some rehires were loaded as new people, creating duplicate national IDs. The project manager wants to reload all 2,500 records at once this weekend and clean up later. Go-live is in four weeks, and the payroll team needs assignments by the first pay period. You must propose a load strategy that avoids duplicate people and preserves payroll eligibility.
1. What load order and business object components would you use, and why?
Read the worked answer
I would load in dependency order, not worker order. First, reference data: legal employers, business units, locations, jobs, grades, departments, and payroll definitions must exist and be valid for the effective dates. Then load person records, followed by work relationships and assignments. Assignment components must carry the correct legal employer, business unit, payroll relationship, and effective start date. The 'business unit not valid for legal employer' error is a reference-data and cross-validation problem, not a worker-record problem, so reloading workers first would repeat it.
I would use source keys for person, work relationship, and assignment so the loader can match existing records instead of creating duplicates. I would validate a small pilot batch from each country before scaling. For workers with no payroll, I would check whether the payroll relationship and payroll assignment were included or whether the assignment was created after the payroll cutoff. Loading all 2,500 at once would multiply errors and make reconciliation harder.
2. How should the team handle rehires and duplicate national IDs?
Read the worked answer
A rehire should not be loaded as a new person. The loader must match the existing person by the national identifier or another trusted source key, then create a new work relationship or assignment for the new period. Creating a second person record fragments history, benefits, and payroll, and it is difficult to merge later. I would extract the existing person records for all rehires, compare national IDs, and use the rehire action or a new work relationship against the existing person key.
For the duplicates already created, I would stop further loads and identify which record has the payroll and absence history. I would not delete blindly. The clean-up should merge or inactivate the duplicate according to the organization's data-governance policy, with an audit trail. I would also add a pre-load duplicate check on national ID plus date of birth and a post-load reconciliation report. The goal is to prevent new duplicates before spending time on cleanup.
3. What is your recommendation on the 'load everything at once' proposal?
Read the worked answer
I would reject it. The first 400 records already show four different error classes, and a single weekend load would make it impossible to tell whether a failure is reference data, duplicate person, payroll setup, or effective dating. It also removes the chance to correct source data before payroll needs assignments.
I would propose three controlled waves by country or legal employer, each with a pilot of 20 to 50 records, a full validation report, and a reconciliation of person, work relationship, assignment, and payroll counts. I would freeze the source file between waves and require sign-off on errors before the next wave. If time is tight, I would prioritize workers whose start dates fall in the first pay period, but still validate reference data first. Cleaning up later is not a plan; duplicate people and missing payroll assignments create pay defects that are harder to fix after go-live.