JinJin48

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

July 19, 2026 · 6 min read

SAP SF Person

Person is the master data object that represents one individual’s global, biographical identity in SuccessFactors Employee Central — distinct from Employment, which represents the job or contract relationship an individual holds with a Legal Entity, and distinct from Employee Profile, which is the aggregated read view built on top of both (covered in SF-A04-03). It opens Phase 3 (Employee Data): where Phase 1’s Legal Entity through Position chain builds the organizational scaffolding and Phase 2’s Permission Group through Compensation Plan chain builds the access-control and process scaffolding, Person is where an actual human being enters the system for the first time. This article covers what a Person record is, its worker-category and lifecycle-state variants, how it sits at the top of the Employee Data landscape zone alongside Employment and User, and every field an Employee Central consultant configures for it.

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

1.1 What Is the Person?#

Person is a client-level (tenant-level) root object that carries an individual’s biographical and personal-contact data but no job, org-placement, or pay information of its own — that detail lives one level down, on the Employment record(s) attached to it. Because it is the identity every other employee-data object ultimately points back to, it is deliberately the shallowest, most stable object in the Employee Data zone: names, birth dates, and national IDs change rarely, while the Employment records hanging off a Person change constantly as the individual is hired, promoted, transferred, or given a global assignment.

1.2 Worker Type and Lifecycle State#

A Person record itself carries no “type” field, but the Employment record(s) attached to it determine what kind of worker the individual is and where they sit in their lifecycle — getting this distinction wrong is a routine source of confusion for consultants new to the platform, since it is easy to assume “worker type” lives on Person when it actually lives one level down.

Design principle: because Person — not Employment — is the identity that gets reused across rehires and concurrent or global assignments, always search for an existing Person record before creating a new one. Creating a duplicate Person for a rehire fragments that individual’s history across two identities and breaks tenure, seniority, and historical-reporting calculations that assume one Person equals one continuous history.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Person sits at the top of the tenant-level “Employee Data” zone of the SuccessFactors Master Data Landscape — the hub node that Employment and User both hang off of directly, with Employment in turn owning Job Information and Compensation Information as its own child records:

Client (SuccessFactors Instance)
   │
   └── Person "PER_000001" — Taro Yamada, DoB 1985-04-01
          │
          ├── Employment "EMP_000001" — Full-time, hire 2020-04-01  (1:N — home + Global Assignment records)
          │      │
          │      ├── assigned to ──> Legal Entity "LE_JP01" — Japan legal entity, Company Code JP01
          │      │
          │      ├── Job Information "JI_001" — Sales Mgr assignment
          │      │      ├── assigned to ──> Position "POS_SalesMgr01" — Sales Manager seat
          │      │      └── assigned to ──> Job Code "JC_SalesRep" — Sales Rep
          │      │
          │      └── Compensation Information "CI_001" — Base 7.5M JPY
          │             └── assigned to ──> Pay Grade "PG_M1" — Manager L1, 6M-9M JPY
          │
          └── User "USER_tyamada" — yamada@example.com  (1:1)
                 └── assigned to ──> Permission Role "PR_ESS" — Employee Self-Service

MANDATORY landscape verification note: the module Master.md’s ER Diagram draws User ←── Person + Permission Role, listing both as inputs to User on the same line. The published SuccessFactors Master Data Landscape (sf-a01/images/04-sf-a01-master-landscape.html, Zone E) resolves this into two different connector types: a solid parent-child bus line from Person to User (Person owns/contains its User record, 1:1 per the source Notes table — “Person 1名に対して1ユーザー”), and a separate ↗ PR_ESS reference chip on the User card pointing into Zone C. This is not a contradiction — it is the landscape distinguishing true containment (Person owns User) from cross-zone reference (User points at a Permission Role for RBP purposes), exactly the same solid-vs-chip convention used for Employment’s ↗ LE_JP01 reference into Zone A and Job Information’s ↗ POS_SalesMgr01 / ↗ JC_SalesRep references into Zone B.

Design principle: Person is intentionally the shallowest, most stable node in the Employee Data zone — it owns Employment and User directly, but every further reference outward (Legal Entity, Position, Job Code, Pay Grade, Permission Role) is resolved one or two levels down, never directly off Person itself. This keeps identity stable even as an individual’s job, org placement, and access change many times over a career.

1.4 Integration with Other Master Data Objects#

Person does not stand alone: it is the landing point for an individual entering the system from Recruiting or Onboarding, and it is the object every Employment, User, and access-control resolution downstream ultimately depends on.

Part 2: SF-Specific Field Details#

2.0 Scope of SF Ownership#

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

2.1 Biographical Information (Core Identification)#

Biographical Information is the minimum record a Person needs to exist — it is what every Employment, every User, and every group picker across the system resolves back to.

2.2 National ID Information#

National ID Information is a repeating sub-record — a single Person can carry more than one National ID (e.g. a home-country passport plus a host-country resident registration for a Global Assignment Person).

2.3 Personal Contact Information#

Personal Contact Information is deliberately kept separate from any org-placement or work-contact data (which lives on Job Information under Employment, see SF-A04-02) — this section is the individual’s own reachability data, independent of which Employment is currently active.

2.4 Global Information (Country-Specific Extension)#

Global Information is not a fixed field list the way the other three sections are — it is an extension mechanism that adds country-specific personal fields on top of the core Person object, only for the countries where a given field is legally required.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction