SAP SuccessFactors · HCM · Historical
Migrate job information into SuccessFactors Employee Central, covering effective-dated job_info records, event reasons, Foundation Object references, manager assignment and historical job change sequencing.
job_info is the effective-dated heart of Employee Central. Every job change, transfer, position change, manager change and status change is a dated row, and the set of rows for a worker is their employment history.
Two rules govern the object absolutely: rows must be chronologically sequenced and non-overlapping, and every Foundation Object a row references must already exist. Employee Central rejects the whole set for a worker rather than the offending row, which makes date reconstruction the dominant task.
Scope is agreed in discovery; this is the shape of the object.
| Data area | Typical information |
|---|---|
| Job information | Effective date, event, event reason, position, job classification |
| Organisational assignment | Legal entity, business unit, division, department, location |
| Employment details | Employee class, employment type, FTE, standard hours, pay group |
| Manager | Supervisor reference, itself another worker |
| Cost assignment | Cost centre and cost distribution |
| Event history | The sequence of dated rows reconstructing the employment record |
Dependency drives load sequence: a child cannot exist before its parent.
Confirm each of these before the first migration cycle.
Production-proven means we have delivered this object from that source. Supported and custom-mapping describe capability, not delivery history.
Object-level equivalence. Field-level mapping is produced per engagement.
| Source system | Source entity | Target object |
|---|---|---|
| JD Edwards | Employee Master + history | job_info dated rows |
| PeopleSoft | JOB (effdt / effseq) | job_info dated rows |
| Workday | Staged events | job_info dated rows |
Import Employee Data — job information template
Full purge for the initial load; incremental for later cycles
Manager assignment as a second pass once the full population exists
Per worker, across the whole dated set.
Every referenced object is configured and effective at the row date.
Against the configured picklists.
Not merely currently.
job_info cannot begin before the employment record.
Where position management is in scope.
What has to exist before this object can load.
What actually fails on this object, and why.
Counts alone rarely prove this object migrated correctly.
Row count per worker compared to the source change history
Date span per worker against the agreed history depth
Current-state comparison: the latest row per worker matches the source current values
Manager coverage after the second pass
Foundation Object distribution compared to source, which surfaces crosswalk gaps
Workers rejected in full, categorised by reason
Deep job history is a strong archive candidate. Employee Central needs enough history to support HR operations and statutory reporting; decades of historical job rows inflate the instance and slow every migration cycle. Archiving the tail keeps it queryable without loading it.
Extraction, mapping, transformation, validation preparation and target load generation.
Explore DataMove →Preserves source, prepared and target states for reconciliation, lineage and audit evidence.
Explore DataVault →Migration progress, data quality, exceptions and readiness across cycles.
Explore DataLens →Source-specific guidance for moving this object.
Published case studies whose scope included job information.
Tell us your source application, target system, object scope, volume and migration timeline. We can discuss the recommended migration approach and relevant Syntra ETL project experience.