JinJin48

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

July 19, 2026 · 16 min read

SAP SF Employee Profile

Employee Profile is the aggregated read view that surfaces an individual’s biographical identity — Person, covered in SF-A04-01 — and job/contract detail — Employment, Job Information, and Compensation Information, covered in SF-A04-02 — as a single consolidated screen. It does not own a person’s identity or job placement itself; those records belong to Person and Employment respectively. What Employee Profile does own is the profile-specific data that has nowhere else to live: the Profile Header aggregation, Job Relationships (additional relationship links such as HR Rep and Matrix Manager), and Background Elements such as Work Experience and Education. It closes out Phase 3 (Employee Data): where Person opened the phase as the root biographical identity and Employment carried the operational job/contract detail, Employee Profile is the presentation and extension layer built on top of both. This article covers what Employee Profile is, its view-type and visibility variants, how it sits atop Zone E’s Person / Employment / Job Information / Compensation Information without adding a landscape node of its own, and every profile-specific field an Employee Central consultant configures across Profile Header, Job Relationships, Work Experience, and Education.

Part 1: Employee Profile — Core Concepts (All Modules)#

1.1 What Is the Employee Profile?#

Employee Profile is not an owning master record the way Person or Employment are — it is the request-time aggregation layer that assembles those records, plus its own profile-specific extensions, into the single screen a consultant, manager, or employee actually looks at. Because it has no biographical or job data of its own to maintain, it is deliberately the least “stable” object in the Employee Data zone in one sense (it re-renders every time the underlying Person or Employment data changes) and the most extensible in another (Job Relationships and Background Elements are configured and grown here, independent of Person’s and Employment’s own field sets).

1.2 Profile View Types and Visibility Scope#

Employee Profile itself carries no “type” field — what varies is which subset of the underlying Person, Employment, and Background Element data a given viewer is permitted to see, and that subset is entirely governed by RBP layered per portlet and per Background Element rather than by anything on the object itself. Getting this distinction wrong is a common source of “why can’t this manager see the field I just configured” support tickets, because a field being technically present on Person or Job Information does not mean it renders on every profile view.

Design principle: never assume a field visible on one profile view is automatically visible on another. Full Profile, Public Profile, and Manager Self-Service Profile can each show a different subset of the exact same underlying Person / Employment / Background Element data — always confirm which view type a requirement is describing before configuring field visibility.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Employee Profile has no dedicated position of its own in the tenant-level “Employee Data” zone of the SuccessFactors Master Data Landscape — it is not one of the module’s 30 Setup Flow steps. Instead, it sits conceptually above the existing Zone E structure, assembling Person, the active Employment, Job Information, Compensation Information, and User at request time, while separately attaching its own Job Relationships (on Job Information) and Background Elements (on Person):

Client (SuccessFactors Instance)
   │
   └── Person "PER_000001" — Taro Yamada, DoB 1985-04-01
          │
          ├── Employment "EMP_000001" — Full-time, hire 2020-04-01, Active
          │      │
          │      ├── Job Information "JI_001" — Sales Mgr assignment
          │      │      └── Job Relationships — HR Rep "EMP_000250", Matrix Manager "EMP_000180"
          │      │
          │      └── Compensation Information "CI_001" — Base 7.5M JPY
          │
          ├── Background Element: Work Experience "WE_001" — "XYZ Corp", Sales Associate, 2016-2020
          ├── Background Element: Education "ED_001" — Waseda University, BA Commerce, 2016
          │
          └── User "USER_tyamada" — yamada@example.com

   Employee Profile (this article)
      = the read-aggregated screen assembled from all of the above:
        Person + the active Employment's Job Information/Compensation Information
        + Person-level Background Elements + Job Information's Job Relationships
      — with no dedicated storage layer of its own beyond EmpJobRelationships
        and the Background Element entities noted above.

MANDATORY landscape verification note: the module Master.md’s Setup Flow and ER Diagram list exactly 5 objects in Phase 3 (Employee Data): Person, Employment, Job Information, Compensation Information, and User — Employee Profile is not among them, because it is a UI/read-aggregation construct rather than a maintained master record. The published SuccessFactors Master Data Landscape (sf-a01/images/04-sf-a01-master-landscape.html, Zone E) accordingly has no card for it. This is consistent with how SF-A04-01 and SF-A04-02 each describe Employee Profile — “the aggregated read view built on top of both” Person and Employment — and this article’s Section 1.3 crop reuses the identical Zone E region those two sibling articles use, rather than inventing a new node. Job Relationships (attached to Job Information, since the relevant HR Rep / Matrix Manager can change with a job change) and Background Elements (attached to Person, since Work Experience and Education are biographical and follow the individual across Employments) are genuine Employee-Profile-owned extensions, but because they are configuration-level additions rather than Setup Flow objects, they are not drawn as separate landscape cards either — they are called out in the tree above as attachment points on the existing Zone E nodes.

Design principle: because Employee Profile aggregates rather than owns the identity and job data it displays, any correction to Person or Employment (SF-A04-01, SF-A04-02) is immediately reflected on Employee Profile with no separate update step — but a correction to a Background Element or Job Relationship must be made directly on Employee Profile’s own data, since neither Person’s nor Employment’s field tables contain it.

1.4 Integration with Other Master Data Objects#

Employee Profile does not stand alone: every field it shows is either sourced directly from Person or Employment, sourced indirectly through Employment’s own child records, or dependent on User for the viewer to reach it at all.

Part 2: SF-Specific Field Details#

2.0 Scope of SF Ownership#

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

2.1 Profile Header (Aggregated Snapshot)#

Profile Header is the summary card every viewer sees first — it deliberately carries no field of its own that isn’t already sourced from Person or Job Information, with the single exception of Profile Photo.

2.2 Job Relationships (Additional Relationships)#

Job Relationships is a configurable block attached to Job Information that captures reporting-line-style connections beyond the single primary Manager field — this is genuinely Employee Profile’s own data, not a restatement of anything already covered on Person or Employment.

2.3 Background Elements — Work Experience#

Work Experience is a repeating Background Element attached to Person — the same individual’s Work Experience rows persist across a rehire or a Global Assignment, since they are not tied to any single Employment.

2.4 Background Elements — Education#

Education is a second repeating Background Element attached to Person, structured similarly to Work Experience but with its own field set tailored to academic history.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction