Sage People to Oracle Fusion Mapping — Field-by-Field Reference

Sage people to oracle fusion mapping is the per-field translation table that determines how each Sage People custom-object field becomes an Oracle Fusion HCM HDL business object attribute. Worker__c.Name → HDL Worker.LastName + FirstName decomposition. Employment_Record__c.Effective_Date__c → HDL Assignment.EffectiveStartDate. Salary__c.Annual_Salary__c → HDL Salary.SalaryAmount. Leave_Request__c.Start_Date__c → HDL AbsenceEntries.StartDate. Without an explicit mapping for every field in scope, the migration cannot generate a valid HDL bundle. Syntra ETL ships the mapping for every standard Sage People field pre-built; customer-specific custom fields are added through configuration during the design phase.

Worker__c is the root Sage People object representing a person in the workforce — it carries name, contact, person-type, primary employment reference, and a flag indicating whether the worker is active. HDL HcmWorker (the Worker.dat HDL business object) is the Fusion equivalent — same conceptual role but with Fusion's effective-dated, person/work-relationship-separated model. The mapping decomposes Worker__c into HDL Worker (the person attributes) and HDL WorkRelationship (the relationship to the legal employer). Sage People's single Worker__c becomes two HDL files when loaded, with the cross-reference key being the persistent worker identifier carried through both.

Employment_Record__c is the Sage People object that holds the employment relationship: which position, in which department, in which location, on what cost centre, reporting to which manager, on what effective dates. HDL Assignment is the equivalent in Fusion — the assignment record that links a Worker to a job, position, department, location, grade, and pay basis on an effective date. The mapping is mostly direct: Employment_Record__c.Position__c → HDL Assignment.PositionCode; Employment_Record__c.Department__c → HDL Assignment.DepartmentName; Employment_Record__c.Cost_Centre__c → HDL Assignment.DefaultExpenseAccount; Employment_Record__c.Manager__c → HDL Assignment.SupervisorPersonNumber. The two structural differences worth noting: HDL Assignment is strictly effective-dated where Sage People uses start/end pairs, and HDL Assignment requires explicit BU code where Sage People infers it.

Salary__c carries the Sage People salary record: amount, currency, frequency, effective dates, pay components. HDL Salary is the Fusion target: SalaryAmount, SalaryBasis (which determines frequency), DateFrom / DateTo, plus an attached element entries breakdown for pay components. The mapping: Salary__c.Annual_Salary__c → HDL Salary.SalaryAmount; Salary__c.Currency__c → HDL Salary.Currency; Salary__c.Effective_Date__c → HDL Salary.DateFrom; Salary__c.Pay_Frequency__c → HDL Salary.SalaryBasis (with a lookup table that translates Sage People's frequency values into Fusion's pre-configured salary basis codes). Pay components nested on Salary__c (allowances, bonuses, deductions) decompose into separate HDL Element entries linked back to the salary via the worker-assignment-salary key chain.

Leave_Request__c is the Sage People absence record — type of leave, start date, end date, hours, approval status, accrual impact. HDL AbsenceCase (the Fusion absence object) carries the same concept but split across two HDL files: AbsenceCase.dat for the case header and AbsenceEntries.dat for the day-by-day or block-by-block entries. The mapping: Leave_Request__c.Leave_Type__c → HDL AbsenceCase.AbsenceType (with a lookup translating Sage People's absence types into Fusion's pre-configured absence type codes); Leave_Request__c.Start_Date__c → HDL AbsenceEntries.StartDate; Leave_Request__c.End_Date__c → HDL AbsenceEntries.EndDate; Leave_Request__c.Approval_Status__c → HDL AbsenceCase.ApprovalStatus. UK statutory leaves (SSP, SMP, SPP) carry additional fields that map to Fusion's UK-specific absence attributes for HMRC reporting.

Standard Sage People ships with a defined set of custom objects and fields — but every customer extends the model. Custom fields added to Worker__c (e.g., Onboarding_Buddy__c, Visa_Status__c, Internal_Job_Family__c) need an explicit mapping decision: do they go into Fusion as native HCM attributes, as Person Extra Information Types (EIT), as Assignment EIT, or get dropped because Fusion handles the underlying concept natively. Syntra ETL's mapping phase produces a custom-field inventory pulled from the Salesforce Metadata API and walks each one through a four-option decision: native Fusion attribute, EIT, retire, or archive-only. The output is a per-field decision sheet signed off by HR, payroll, and the data owner.

Sage People uses standard reference data inside the Salesforce platform: Department records linked parent-child via custom relationship fields, Location records, Cost_Centre__c records, Position__c records, Job__c records. Fusion's HCM has its own reference data taxonomy: HDL Department, HDL Location, HDL Job, HDL Grade, HDL Position, HDL DepartmentTree (for the hierarchy), each loaded via separate HDL business objects with reference-data set codes determining which BU sees them. The mapping translates Sage People's flat-with-parent-link model into Fusion's explicit hierarchy + reference data set model, preserving every parent-child link and producing the tree-version HDL files Fusion needs to render the org chart correctly post-load.

Yes. Sage People customers in the UK populate fields specific to HMRC RTI, P11D, P45, P60, auto-enrolment pensions, and TPR reporting — National_Insurance_Number__c on Worker__c, Tax_Code__c on Employment_Record__c, Pension_Scheme__c with auto-enrolment flags, P11D benefit value fields on Allowance__c. The sage people to oracle fusion mapping for UK customers includes a dedicated section for these: Worker__c.National_Insurance_Number__c → HDL Worker.NationalIdentifier with type 'NI'; Employment_Record__c.Tax_Code__c → HDL Element entry for UK PAYE configuration; Allowance__c.P11D_Value__c → HDL Element for taxable benefits. These mappings are pre-built and validated against current HMRC tax-year schemas (currently 2026–27).