Employee Central Foundations: Purpose and Core Data Model
Understand why Employee Central exists as the cloud system of record for HR and learn the core building blocks of its data model: foundation objects, person/employment data, and generic objects.
Explanation
Employee Central (EC) is SAP SuccessFactors' core HR module and acts as the master system of record for workforce data in a cloud HCM landscape. Organizations adopt EC to replace or complement on-premise HR systems (classic SAP HCM/ECC Personnel Administration and Organizational Management) with a cloud-native, configurable, globally deployable HR core that other SuccessFactors modules (Recruiting, Onboarding, Performance & Goals, Compensation, Learning) and payroll/time solutions read from and write to. At the heart of EC is a layered data model. The first layer is Foundation Objects (FO): these are structural, relatively stable entities such as Company, Business Unit, Division, Department, Location, Job Classification, Pay Grade, and Cost Center. Foundation objects define the organizational and job architecture that employee records point to. They are typically loaded and maintained centrally, often via import templates, and changes to them can cascade broadly (e.g., renaming a department affects every employee assigned to it). The second layer is person and employment data. EC deliberately separates 'Person' information (biographical, National ID, personal data that stays with the human being) from 'Employment' information (job, compensation, organizational assignment tied to a specific work relationship). This person/employment split matters because one person can have multiple concurrent employments (e.g., a global assignment or a rehire), and EC's model is built to support that without corrupting historical records. Within employment data, EC further separates Job Information (position, department, manager, employment status), Compensation Information (pay components, pay grades), and Job Relationships (matrix managers, HR business partners) as distinct effective-dated portlets. Effective dating is a foundational concept beginners must internalize: almost every EC record carries a start date and is versioned over time rather than overwritten. A promotion does not delete the old job record; it inserts a new effective-dated record, preserving full history for reporting, audit, and payroll retro-calculation purposes. This differs fundamentally from many on-premise infotype models only in cloud tooling, but conceptually it echoes SAP HCM's infotype effective-dating approach, so consultants familiar with classic HCM will recognize the pattern even though the underlying technology (MDF, OData, cloud UI) is completely different. The third data layer is Generic Objects, built on the Metadata Framework (MDF). Unlike legacy foundation objects (which use an older object model), MDF-based generic objects are the strategic direction for extensibility: you can define custom objects, fields, associations, and business rules without core code changes. Many newer foundation object types and most custom configurations (e.g., custom pay component groups, custom association tables) are built as MDF objects. For a beginner, the practical takeaway is: before touching configuration, you must understand which employees are affected by a change (person vs. employment scope), when a change takes effect (effective date), and whether the object you are modifying is a legacy foundation object or an MDF generic object, because the maintenance tools, permission model, and rule framework differ between them. Misunderstanding this model is the single most common source of early-project confusion, because incorrect assumptions here lead to broken imports, incorrect effective-dated history, and downstream payroll or reporting errors that are expensive to correct once employees are live in production.
Real project scenario
A mid-size manufacturing company is implementing Employee Central as its single HR system of record globally, replacing a mix of regional HR systems. During data model design workshops, the implementation team must decide how many concurrent employments a shared-services employee can have (e.g., an employee working part-time in two countries) and how the Department, Division, and Cost Center foundation objects will be structured to support both legal reporting per country and matrix management reporting for global functions. Getting the foundation object hierarchy wrong at this stage causes rework in every downstream module that reads organizational assignment, including compensation planning and time off eligibility.
Common mistakes
• Treating foundation objects and generic (MDF) objects as interchangeable when they have different maintenance tools and rule engines • Overwriting effective-dated records instead of inserting new effective-dated rows, which destroys historical data needed for payroll retro and audit • Modeling all organizational hierarchy in Department alone instead of using the full Business Unit/Division/Department/Cost Center layering, causing reporting limitations later • Confusing Person-level data (National ID, biographical data) with Employment-level data (job, compensation), leading to incorrect data scoping in permission roles • Not planning for concurrent employment scenarios early, resulting in a data model that cannot support global assignments or rehires cleanly
Best practices
• Map the full foundation object hierarchy (Company, Business Unit, Division, Department, Cost Center, Location, Job Classification) before configuring any employee data • Always use effective-dated inserts for changes; never manually edit historical records • Clarify person vs. employment scope explicitly in every requirement and permission role design • Plan for concurrent employment and global assignments during initial data model design, not as an afterthought • Prefer MDF-based generic objects for any new custom object to align with SAP's strategic direction and get access to business rules and workflows
Interview angle
Interviewers commonly probe whether a candidate understands the person/employment split and effective dating, since these concepts drive almost every configuration decision in EC. Be ready to explain, with a concrete example, how a promotion or transfer is recorded without losing history, and why concurrent employment requires careful foundation object design. Also expect questions distinguishing legacy foundation objects from MDF-based generic objects and why SAP's strategic direction favors MDF for new object types.