Field-by-field translation from Sage People Salesforce custom objects (Worker__c, Employment_Record__c, Salary__c, Leave_Request__c) to Oracle Fusion HCM HDL business objects. Pre-built standard mapping, configurable UDF routing.
The extract and load are mechanical. The mapping decisions — what becomes a native Fusion field, what becomes a DFF, what goes to archive only, what retires — are the project.
Sage People stores HR data in flat Salesforce custom objects. A Worker__c record holds 100+ fields covering everything from name and date-of-birth to home address to emergency contact to internal performance band to bonus eligibility. Oracle Fusion HCM normalizes the same conceptual data across multiple HDL business objects: Worker, PersonName, PersonAddress, PersonPhone, PersonEmail, PersonNationalIdentifier, WorkRelationship, WorkTerms, Assignment. The same data lives — just in a different shape.
Translating shape is mechanical. The hard part is the business decisions embedded in every field. Sage People customers added custom fields years ago to capture things the platform didn't natively support: a custom 'Pension Auto-Enrolment Opt-Out Date' on Worker__c, a custom 'Long-Service Award Anniversary Date', a custom 'Salary Sacrifice Cycle Scheme Election'. Each one is a business question: does this need to land in Fusion as native, as DFF, as archive-only, or does it retire? Multiplied across 30-80 custom fields per major object, that's 200+ decisions per Sage People migration.
Syntra ETL's Sage People data mapping engine pre-loads every decision for the standard Sage People schema (so HR teams don't argue about basics) and provides a structured workflow for the custom-field decisions: schema scan, proposed route, business owner notification, sign-off, audit log. The output is a signed Excel mapping pack AND the YAML configuration that drives the actual extraction — same artifact, single source of truth.
Every standard Sage People object has a pre-built Fusion HDL target. Customer custom fields layer on top through the four-route workflow.
Splits Worker__c into HDL Worker.dat, PersonName.dat, PersonAddress.dat, PersonPhone.dat, PersonEmail.dat, PersonNationalIdentifier.dat. Effective-dated person history preserved.
Job, position, department, location, manager, FTE, working pattern, contract type → HDL Assignment.dat with effective-dated history per worker.
Annual salary, salary basis, pay frequency, currency, effective dates, salary review reason → HDL Salary.dat with full historical chain preserved.
Annual leave, sick leave, UK statutory (SSP, SMP, SPP, ShPP) → HDL AbsenceCase.dat + AbsenceEntry.dat against configured Fusion Absence Management plans.
Position records, hierarchy, FTE budget, position attributes → HDL Position.dat with reference-data set alignment.
Sage People department and location records → HDL Department.dat + Location.dat with parent-child hierarchy validation.
Sage People public group memberships used by Apex sharing → Fusion HCM role assignments with data security alignment.
Performance goals, key results, alignment → Fusion Performance Management Goals HDL or REST API load.
Review cycles, ratings, comments, calibrations → Fusion Performance Management cycles + Performance Documents.
A six-step workflow that produces signed, audit-ready field-level mapping from Sage People to Oracle Fusion HCM.
Metadata API extract of every custom object and custom field in the Sage People org. Output: complete inventory of standard Sage People objects + customer additions, with field count, data type, and population statistics.
Syntra ETL's pre-built mapping applied automatically: Worker__c → Worker + Person*, Employment_Record__c → Assignment, Salary__c → Salary, Leave_Request__c → AbsenceCase. ~70% of fields mapped in this pass.
Engine proposes a route (MAP/FLEX/ARCHIVE/RETIRE) for each customer custom field based on field name, population rate, and historical usage pattern. ~30% of fields covered in this pass.
Field-level proposals routed to business owners (HR ops for HR fields, payroll for payroll fields, talent for talent fields) for approve/modify/escalate. Sign-off captured per field.
Salesforce picklist values aligned to Fusion lookup codes. Consolidations (merging duplicate values), retirements (obsolete values), and additions (new Fusion values) signed off.
Signed Excel mapping workbook + YAML configuration emitted. Excel goes into the audit pack. YAML drives the actual extract and transform — single source of truth, no drift.
Every customer-added custom field gets a route. Here's what each route looks like in practice.
Worker__c.Pension_Scheme__c (text) → Worker.PensionScheme (lookup, after value-mapping). Mapped because Fusion natively supports pension scheme membership tracking.
Worker__c.Long_Service_Award_Year__c (number) → Worker DFF Attribute1. Routed because the field is business-valuable but has no native Fusion equivalent.
Worker__c.Sage_People_Init_Migration_Note__c (text). Old internal migration breadcrumb — historical only, doesn't need to land in Fusion. Goes to Parquet archive.
Worker__c.Old_Manager_Cache__c (text). Field hasn't been updated in 3 years, duplicates Manager__c. Field owner signs to retire.
Sage People Employment_Status__c has 'Active', 'A', 'ACTIVE' (legacy variants from M&A). All collapse to Fusion ACTIVE in the crosswalk.
Fusion supports a Worker Status of 'On Long-Term Disability' that Sage People didn't track. Added to crosswalk + reverse-mapped from Leave_Request__c absence type.
Sage People data mapping for Oracle Fusion is the field-level translation reference that converts every Sage People Salesforce custom-object field into the corresponding Oracle Fusion HCM HDL business-object field. The mapping is non-trivial because Sage People (Salesforce-platform) and Fusion HCM use fundamentally different data models: Sage People has flat custom objects with __c suffixes (Worker__c, Employment_Record__c, Salary__c, Leave_Request__c) and custom fields, while Fusion HCM has a normalized HDL model (Worker, WorkRelationship, WorkTerms, Assignment, Salary, Element, AbsenceCase, AbsenceEntry) with strict effective-dated history requirements. Syntra ETL ships pre-built data mapping for every standard Sage People object — and a configurable extension layer for the custom fields your org has added on top of the base Sage People model.
Sage People's Worker__c is a single denormalized custom object with 100+ standard fields and typically 30-80 customer-added custom fields. Oracle Fusion HCM splits worker concept across multiple business objects: Worker (the person), PersonName, PersonAddress, PersonPhone, PersonEmail, PersonNationalIdentifier, WorkRelationship (relationship to legal employer), WorkTerms (employment terms), Assignment (specific job role). Syntra ETL's Worker__c mapping reads the Sage People record, splits Person identity attributes into HDL Worker.dat with related PersonName/PersonAddress/etc., extracts work-relationship attributes (Legal Employer, Worker Type, Service Dates) into WorkRelationship.dat, and produces WorkTerms.dat with employment type, working hours, contract type. The split is mechanical when the source is clean and complex when it isn't — which is why mapping needs governance and reconciliation.
Employment_Record__c in Sage People is the job-assignment record holding position, department, location, manager, cost centre, full-time-equivalent, working pattern, contract type, start/end dates. Oracle Fusion HCM's Assignment business object covers the same conceptual space but with stricter effective-dated history requirements. The mapping: Employment_Record__c.Position__c → Assignment.PositionCode; Employment_Record__c.Department → Assignment.DepartmentName; Employment_Record__c.Location → Assignment.LocationCode; Employment_Record__c.Manager__c → Assignment.ManagerWorkerNumber; Employment_Record__c.FTE__c → Assignment.WorkingHours / Assignment.NormalHours; Employment_Record__c.Start_Date__c → Assignment.EffectiveStartDate. History is reconstructed by walking Employment_Record__c records per worker in date order and emitting an Assignment HDL line per effective-dated change (hire, promotion, transfer, FTE change, manager change, termination).
Salary__c is Sage People's compensation custom object holding annual salary, salary basis, pay frequency, currency, effective dates, salary review reason, salary plan. Oracle Fusion HCM uses HDL Salary loaded against an Assignment with reference to a Salary Basis. The mapping: Salary__c.Annual_Salary__c → Salary.SalaryAmount with frequency conversion to Salary Basis pay frequency; Salary__c.Currency__c → Salary.CurrencyCode; Salary__c.Effective_Date__c → Salary.DateFrom; Salary__c.End_Date__c → Salary.DateTo; Salary__c.Salary_Plan__c → Salary.SalaryBasisCode (with prior alignment of basis codes between systems); Salary__c.Reason__c → Salary.ActionReasonCode. Historical salary chain is preserved by emitting HDL Salary lines per effective-dated change. Customers crossing currency boundaries get FX-conversion logic per Fusion's currency-of-record rules.
Leave_Request__c is Sage People's absence custom object covering annual leave, sick leave, statutory leave (SSP, SMP, SPP, ShPP for UK), and customer-defined absence types. Oracle Fusion HCM uses HDL AbsenceCase and AbsenceEntry against Absence Management plans. The mapping: Leave_Request__c.Worker__c → AbsenceCase.PersonNumber; Leave_Request__c.Absence_Type__c → AbsenceCase.AbsenceType (with prior alignment to Fusion absence types like 'Annual Leave', 'Sickness', 'Maternity'); Leave_Request__c.Start_Date__c + Leave_Request__c.End_Date__c → AbsenceEntry.StartDate + EndDate; Leave_Request__c.Status__c → AbsenceCase.AbsenceStatus (Approved → APPROVED, Pending → SUBMITTED, etc.); Leave_Request__c.Hours_Per_Day__c → AbsenceEntry.AbsenceDuration. Accrual balances are derived separately and loaded as opening-balance AbsenceEntitlement records against the configured Fusion Absence Plans.
Every Sage People org has customer-added custom fields beyond the standard Sage People schema — typically 30-80 per major object. The Syntra ETL data mapping engine reads the live Salesforce schema via the Metadata API, identifies every custom field on every standard Sage People object, and proposes one of four routes per field: (1) MAP — field has a clear Fusion HCM equivalent, mapped to the appropriate Fusion field; (2) FLEX — field doesn't map natively but holds business-relevant data, routed to a Fusion Descriptive Flexfield (DFF) on the appropriate business object; (3) ARCHIVE — field holds historical context with no Fusion equivalent and goes to the long-term archive only; (4) RETIRE — field is unused or duplicates other data and is dropped. Each routing decision is signed off by the business owner of the field.
Sage People uses Salesforce picklists for many controlled-value fields: Employment Status, Worker Type, Pay Frequency, Absence Type, Country. Oracle Fusion HCM uses lookup codes, value sets, and reference-data sets with strict validation. The mapping pre-step generates a picklist crosswalk per object — listing every active Salesforce picklist value alongside the proposed Fusion lookup code. HR and payroll teams review and approve the crosswalk before extract begins, eliminating downstream surprise failures. Common alignments include consolidating overlapping Sage People values (e.g. 'Part Time', 'PT', 'Part-Time' merged to single Fusion 'PT' code), retiring obsolete values, and adding Fusion values that didn't exist in Sage People. The signed crosswalk becomes part of the audit pack.
The data mapping deliverable is a multi-tab Excel workbook plus YAML configuration. Tab 1: Object-level mapping — Sage People object → Fusion HDL business object with row count, scope inclusion. Tab 2-N: Per-object field mapping — source field, source data type, destination HDL field, destination data type, transformation rule, sample value, business owner sign-off. Tab N+1: Picklist crosswalk — Sage People picklist value → Fusion lookup code. Tab N+2: UDF routing decisions. Tab N+3: Open issues and parking lot. Alongside the Excel, the engine emits a YAML configuration that drives the actual extraction and transformation — so the documentation IS the implementation, with no drift between what's signed and what runs.
Standard mapping for every Sage People object plus a structured workflow for your custom fields. Signed Excel + executable YAML, audit-ready. Book a 30-minute walkthrough.