6.1 The Four Employee Central Data Models, DTDs, and Upload Sequence

6.1 The Four Employee Central Data Models, DTDs, and Upload Sequence

Quick Answer: Employee Central is defined by four data models. The Corporate Data Model (XML-based foundation objects) and its country-specific version, and the Succession Data Model (HRIS elements for person and employment data) and its country-specific version. An implementation uploads them in Provisioning in the order Corporate → CSF Corporate → Succession → CSF Succession.

The Employee Central Core Structure

An HR information system stores employee data and organizational data. In SAP SuccessFactors, organizational details such as department, division, and legal entity are Foundation Objects. Some foundation objects are MDF objects configured in Configure Object Definitions. Others are XML-based and maintained in the Corporate Data Model. Employee-specific details, such as date of birth, national ID, job title, and salary, live in HR objects. Access is controlled by RBP, and self-service lets employees and managers maintain their own data.

What a Data Model Controls

Data models describe how data elements are structured, their properties, and their relationships. When configuring them you can:

• set the visibility of a field (THR81's example hides Date of Death in personInfo)
• define custom labels and fields (for example relabeling Place of Birth as City of Birth)
• define relationships among foundation objects
• set the order of fields
• set a picklist for a field

Every change must comply with the Document Type Definition (DTD). You cannot add an element, field, or attribute the DTD does not define. SAP recommends hiding a field rather than deleting it. If a field must be deleted, set its visibility to "none" before deleting it.

The Four Data Models

Corporate data falls into four categories: organization-related, pay-related, job-related, and others. THR81 files the workflow configuration object under Others.

Where Each Model Is Imported and Exported

Customer administrators without Provisioning access manage Succession Data Model elements through Manage Business Configuration instead of XML. Both import paths offer backup versioning. You can enter a comment for each uploaded version, see the date, operator, and comment of previous versions, download earlier versions, and restore one.

Linking a Data Model to Its DTD

To validate a model in an XML editor, replace the SAP-internal repository URL in the DOCTYPE line with the local DTD file name, stored in the same folder:

For real projects, download the standard data models and DTDs from the SAP Software Download Center. The course files are abridged versions.

The Upload Sequence

In Provisioning > Succession Management, upload the four models in this order:

1. Corporate Data Model (Import/Export Corporate Data Model XML)
2. CSF Corporate Data Model (Import/Export Country/Region Specific XML for Corporate Data Model)
3. Succession Data Model (Import/Export Data Model)
4. CSF Succession Data Model (Import/Export Country/Region Specific XML for Succession Data Model)

Enter a comment for versioning each time. The Corporate models may also be uploaded from Admin Center if the administrator has the right permissions. If an upload shows "An application error occurred", log out of Provisioning, clear the browser cache, and check whether the model was uploaded despite the error before trying again.

Uploading the models also makes related permissions appear. For example, Employee Central Effective Dated Entities becomes available once the Succession Data Models are uploaded, and Manage Foundation Object Types once the Corporate Data Models are uploaded (Section 7.5).

Worked Example: Deconstructing a Data Model Change

THR81's first data model interaction uses the personInfo (Biographical Information) element:

• Date of Death is not visible, so its field has visibility set to none.
• Place of Birth is relabeled City of Birth by changing the field's label.
• The same file could attach a picklist, reorder fields, or add a custom field, but only elements and attributes that the DTD allows.

Exam Tips

• If a task needs a new Location field, it is a Corporate Data Model change, possible from Admin Center. If it needs a new Job Information field, it is a Succession Data Model change: use BCUI in the instance, or Provisioning for XML.
• Never edit IDs of HRIS elements or fields. Change labels, visibility, and required flags.
• After enabling any new field, grant its RBP permission or nobody will see it.