JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 19, 2026 · 15 min read

SAP SF Employment

Employment is the master data object that represents the job or contract relationship an individual holds with a Legal Entity — distinct from Person, which represents the individual’s global, biographical identity (covered in SF-A04-01), and distinct from Employee Profile, the aggregated read view built on top of both (SF-A04-03). Where Person is deliberately shallow and stable, Employment is where the operational detail lives: it is the record that carries Hire Date, Employment Type, and Employment Status, and it is the direct parent of Job Information (org placement — position, job code, manager, location) and Compensation Information (pay — pay grade, base salary, currency). This article covers what an Employment record is, its type and status-lifecycle variants, how it sits directly beneath Person in the Employee Data landscape zone while owning Job Information and Compensation Information as its own children, and every field an Employee Central consultant configures across all three.

Part 1: Employment — Core Concepts (All Modules)#

1.1 What Is the Employment?#

Employment is a per-contract record — one Person can hold one Employment (the common case) or several concurrent Employments (a Global Assignment, where a home and a host Employment exist side by side), and a Person who leaves and later returns typically gets a new Employment on the same Person rather than a new Person. Because it is the object where “who employs this individual, since when, in what capacity, and in what state” is actually recorded, it is also the object every Job Information and Compensation Information record is effective-dated and versioned against — a promotion or a pay change creates a new dated row under the same Employment, it does not create a new Employment.

1.2 Employment Type and Status Lifecycle#

Where a Person record carries no “type” field of its own (Section 1.2 of SF-A04-01), Employment is exactly where that field lives — Employment Type and Employment Status are both native Employment attributes, and getting the status lifecycle wrong (for example, not distinguishing Terminated from a Leave-of-Absence) is a routine source of broken eligibility logic downstream in Compensation and Benefits.

Design principle: because Employment Status — not the existence of the record itself — is what most integrations and eligibility rules actually filter on, never assume “Employment exists” means “Employment is active.” A Terminated Employment remains in the system indefinitely for history; every downstream query (payroll extract, benefits eligibility, headcount report) must filter on Employment Status explicitly rather than on record presence alone.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Employment sits one level below Person in the tenant-level “Employee Data” zone of the SuccessFactors Master Data Landscape — it is owned by Person (N Employments can exist per Person), and it in turn owns Job Information and Compensation Information as its own child records:

Client (SuccessFactors Instance)
   │
   └── Person "PER_000001" — Taro Yamada, DoB 1985-04-01     (1 Person : N Employments)
          │
          ├── Employment "EMP_000001" — Full-time, hire 2020-04-01, Active   ◄── this article
          │      │
          │      ├── assigned to ──> Legal Entity "LE_JP01" — Japan legal entity, Company Code JP01
          │      │
          │      ├── Job Information "JI_001" — Sales Mgr assignment   (1:1 current, effective-dated history)
          │      │      ├── assigned to ──> Position "POS_SalesMgr01" — Sales Manager seat
          │      │      └── assigned to ──> Job Code "JC_SalesRep" — Sales Rep
          │      │
          │      └── Compensation Information "CI_001" — Base 7.5M JPY   (1:1 current, effective-dated history)
          │             └── assigned to ──> Pay Grade "PG_M1" — Manager L1, 6M-9M JPY
          │
          └── Employment "EMP_000002" — Global Assignment (host), hire 2024-01-01, Active
                 │
                 ├── assigned to ──> Legal Entity "LE_US01" — US legal entity, Company Code US01
                 │
                 ├── Job Information "JI_002" — Host-country assignment role
                 │
                 └── Compensation Information "CI_002" — Host-country pay component

MANDATORY landscape verification note: the module Master.md’s ER Diagram draws Person 1:N Employment ←── Legal Entity, then Employment 1:1 Job Information and Employment 1:1 Compensation Information. The published SuccessFactors Master Data Landscape (sf-a01/images/04-sf-a01-master-landscape.html, Zone E) resolves this into two solid parent-child bus lines — Person → Employment/User at y=1825, and Employment → Job Information/Compensation Information at y=2005 — plus a separate ↗ LE_JP01 reference chip on the Employment card pointing into Zone A. This is the same solid-vs-chip convention documented in SF-A04-01: solid bus lines are true containment (Person owns Employment; Employment owns Job Information and Compensation Information), while chip references (↗ LE_JP01 for Employment, ↗ POS_SalesMgr01 / ↗ JC_SalesRep for Job Information, ↗ PG_M1 for Compensation Information) are cross-zone pointers, not ownership. The “1:1” on the ER diagram describes the current Job Information / Compensation Information row per Employment — both objects are in fact effective-dated, so a single Employment accumulates a full history of dated Job Information and Compensation Information rows over time (promotions, transfers, pay changes), with exactly one row active as of any given date.

Design principle: Employment is the level at which “which Legal Entity, since when, in what capacity” is recorded, but it deliberately does not carry org-placement or pay detail itself — that lives one level further down, on Job Information and Compensation Information, precisely so that a promotion or pay change can be recorded as a new dated child row without touching the Employment record (or the Person record above it) at all.

1.4 Integration with Other Master Data Objects#

Employment does not stand alone: it is owned by exactly one Person, it is bound to exactly one Legal Entity, and it is the parent of Job Information and Compensation Information — the two objects that carry the field-level detail most consultants think of as “an employee’s record.”

Part 2: SF-Specific Field Details#

2.0 Scope of SF Ownership#

Legend: ◎ = Owner / Critical, ○ = Direct involvement

2.1 Employment Details (Core)#

Employment Details is the minimum record an Employment needs to exist — it identifies which Person it belongs to, which Legal Entity it is bound to, and when the relationship began.

2.2 Employment Status and Lifecycle#

Employment Status and Lifecycle fields track where this specific Employment sits in its own timeline, independent of the Person’s overall history — a Person with two concurrent Employments can have one Active and one Pending Hire at the same time.

2.3 Job Information#

Job Information is Employment’s own effective-dated child record for org placement — every promotion, transfer, or reorg is recorded as a new dated Job Information row under the same Employment, never as a change to the Employment record itself.

2.4 Compensation Information#

Compensation Information is Employment’s own effective-dated child record for pay — kept structurally separate from Job Information so that a pure salary review (no change in role) doesn’t require touching the org-placement record at all.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction