COmplete SAP SF Guide

CONFIDENTIAL
Document Version: 1H 2022 – 2022-08-19
SAP SuccessFactors Data Model Reference Guide

© 2022 SAP SE or an SAP affiliate company. All rights reserved.
THE BEST RUN

Content
1 Data Models in SAP SuccessFactors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

1.1 Exporting Succession Data Model and Country/Region-Specific Succession Data Model. . . . . . . . . . . . . .8
1.2 Working with Data Model Files in Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Working with Corporate Data Model and Country/Region-Specific Corporate Data Model in Admin
Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Data Model Definitions (DTDs) for SAP SuccessFactors Data Models. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Adding Picklists to Fields in the Data Model XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Introduction to Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

2.1 Characteristics of Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
2.2 MDF vs. Legacy Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Requirements for Legacy Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Deleting a Foundation Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Corporate Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Components of Corporate Data Model XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Predelivered Foundation Objects in Corporate Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Creating Customer-Specific Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 List of HRIS XML Elements and Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
3.5 Modifying HRIS Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Associations in the Corporate Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6 Deleting HRIS Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7 Modifying HRIS Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.8 Mandatory HRIS Fields for the HRIS Elements in the Corporate Data Model. . . . . . . . . . . . . . . . . . . . . . 41
3.9 Dependencies of Corporate Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
The Corporate Data Model XML for Requisitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Determining Pay Ranges in Calculations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Creating a Dynamic Role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4 Succession Data Model (SDM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.1 Components of Succession Data Model XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Standard Elements in the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
User Info Elements in the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Background Elements in the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Tab Elements in the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
HRIS Elements in the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Custom Filters in the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
HRIS Action (hris-action) in the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

2 CONFIDENTIAL Content
Element-Permission in the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Adding Dynamic Group Filters in the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
View Templates and Edit Templates in the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . 90
Configuring HRIS Sync Mappings (hris-sync-mappings) in the Succession Data Model. . . . . . . . 93
Configuring Read Audit in Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.2 Succession Data Model and User Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Succession Data Model and User Data File (UDF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Configuring the Talent Card Extended Information Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.3 Dependencies of Succession Data Model Across Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Succession and Development and the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Compensation and Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
People Profile and the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Recruiting and Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Talent Management and the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Employee Central and the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Learning and Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Onboarding and the Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Data Models and Other Integrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
5 Country/Region-Specific Data Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

5.1 Adjusting the Data Model for Country/Region-Specific Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Country/Region-Specific Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Country/Region-Specific Formats for Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Influencing the Field Order on the UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
5.2 Setting Up Country/Region-Specific Picklists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176
Modify the Country/Region-Specific Succession Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Define the Picklists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Set Permissions for the Job Information Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Update the Business Rule for Propagation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Validate the Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Content CONFIDENTIAL 3
Change History
Learn about changes to the documentation for SAP SuccessFactors Data Model Reference Guide in recent
releases.
2H 2021
Type of Change Description More Info
Changed We specified all file types of attachments Background Element - Data Field Defini-
you can define for the field <file-
tion [page 65]
formats> and the supported file types if
you don't define this field or set the field Background Element - Rating Field Defi-
blank. nition [page 68]
Added A new standard element, learningLicen Standard Element Field IDs in the Suc
seUserType, is now available. cession Data Model [page 53]
Changed Updated a topic about viewing all up Working with Corporate Data Model and
loaded versions of the Corporate Data Country/Region-Specific Corporate
Model and Country/Region-Specific Data Model in Admin Center [page 12]
Corporate Data Model in Admin Center.
Changed The MP4 file format is not supported for Background Element - Rating Field Defi-
the Rating Field. Updated file formats sec nition [page 68]
tion of the table.
Changed You cannot configure the same values for Background Element - Data Field Defini-
the Data Field ID and Background Ele tion [page 65]
ment ID. Added a note in the ID section of
the table.
Changed You can't use the same ID for a Back Background Element Definition [page
ground Element. While uploading the data 64]
model upper and lowercase letters are
considered as the same string values.
Added a note in the ID section of the table.

4 CONFIDENTIAL Change History
1H 2021
Type of Change Description More Info
Added Added a note that for now, the setting of Initializing New Entry Date Fields in Ex
Leave of Absence Start Date and Leave of isting Job Info Records [page 151]
Absence Return date fields only works
with the "old" LOA/RLOA application, and
not with Time Off/LOA.
New Added a note about accessing previous Exporting Succession Data Model and
versions of the Country/Region-Specific Country/Region-Specific Succession
Succession Data Model in Admin Center Data Model [page 8]
and Provisioning
New Added a topic about exporting Succession Exporting Succession Data Model and
Data Model and Country/Region-Specific Country/Region-Specific Succession
Succession Data Model from Admin Cen Data Model [page 8]
ter and Provisioning

Change History CONFIDENTIAL 5
1 Data Models in SAP SuccessFactors
This topic is your introduction to the data models used in SAP SuccessFactors HXM Suite.
Data Models describe how data elements are structured in a database. They also define the properties these
elements possess and their relationships to each other.
SAP SuccessFactors defines its data using a number of data models. These data elements have impact on all of the
modules of the application as well as the company and employee data stored in the system. Initial set up of the
data models is done through provisioning.
The SAP SuccessFactors Data Models use XML. You can download these XML files from provisioning. You then
work with files in an XML editor of your choice and edit them offline. You upload these modified files back to the
company instance you’re working with in provisioning.
 Remember
As a customer, you don't have access to Provisioning. To complete tasks in Provisioning, contact your
implementation partner or Account Executive. For any non-implementation tasks, contact Product Support.
 Note
Once the initial implementation is complete, you can also modify the data model files from Admin Center using
the Business Configuration UI or BCUI.
Data for any company is of two kinds.
Employee Data This data is employee-related data such as name, date of birth, nationality, as well as
employment data such as job title or compensation.
Organization Data Organization-related data such as Department, Division, Legal Entities. This data also includes
Job and Pay Structure. The organization-related data objects are also described as
Foundation Objects.
SAP SuccessFactors defines this data using the following Data Models:
Corporate Data Corporate Data Model defines the organization-related data in XML, which are also the
Model Foundation Objects. Some of these Foundation Objects can also be defined as MDF Objects.
MDF Objects aren’t in scope for this document. This Data Model also has relationship
between the foundation objects configured in it.
Country/Region The foundation objects from Corporate Data Model that need to be localized based on the
Specific country/region are configured in this data model. In case the configuration for a particular
Corporate Data country/region is missing, the definition in the Corporate Data Model is used.
Model
Succession Data This Data Model is the basis for People Profile and Employee Central. Fields needed to define
Model employee's data are configured in this data model. The elements defined here are used or
referenced in People Profile, Matrix Grid reports, Succession Org Chart, Employee Directory,
and Employee Scorecard. These fields are also used in Performance Management,
Compensation, Recruiting Management, and for user management in a company instance.

6 CONFIDENTIAL Data Models in SAP SuccessFactors
Country/Region Any fields from the Succession Data Model that need to be localized are defined in this data
Specific model. Also, any fields that are specific to a country/region are configured here. In case,
Succession Data there’s no configuration pertaining to a certain country/region in this data model, the field as
Model defined in the Succession Data Model is used.
 Note
Employee Central is required for some of these data elements and data models.
 Note
All configuration files for Employee Central, for example, master data models, master picklists, as well as
country/region-specific files, have moved from the SAP Help Portal to the Software Download Center .
Exporting Succession Data Model and Country/Region-Specific Succession Data Model [page 8]
Succession Data Model and Country/Region-Specific Succession Data Model use XML. You can download
these XML files from Admin Center and Provisioning. You then work with files in an XML editor of your
choice and edit them offline.
Working with Data Model Files in Provisioning [page 9]

Learn how to begin working with your data model files.
Working with Corporate Data Model and Country/Region-Specific Corporate Data Model in Admin Center
[page 12]
Corporate Data Model and Country/Region-Specific Corporate Data Model use XML. You can download
these XML files from Admin Center. You then work with files in an XML editor of your choice and edit them
offline. You upload these modified files back to the company instance you’re working using Admin Center.
Data Model Definitions (DTDs) for SAP SuccessFactors Data Models [page 14]
Where can you find the Data Model Definition (DTD) files used by the SAP SuccessFactors HXM Suite?
Adding Picklists to Fields in the Data Model XML [page 15]

Picklists are defined in the Picklist Center. The picklist ID is referred to in the data model configuration. The
fields with picklists IDs then appear as drop down lists on the UI.
Related Information
Corporate Data Model [page 23]

Succession Data Model (SDM) [page 50]
Country/Region-Specific Data Models [page 171]

Data Models in SAP SuccessFactors CONFIDENTIAL 7
1.1 Exporting Succession Data Model and Country/Region-
Specific Succession Data Model
Succession Data Model and Country/Region-Specific Succession Data Model use XML. You can download these
XML files from Admin Center and Provisioning. You then work with files in an XML editor of your choice and edit
them offline.
Prerequisites
It’s important to enable the required role-based permissions. To get started ensure, you enable Administrator
Permissions Admin Center Permissions Export Succession Data Model or Export Country- Specific
Succession Data Model .
Context
You can export Succession Data Model and Country/Region-Specific Succession Data Model in Admin Center.
 Tip
Even if you’ve already downloaded a file from an instance, before beginning work on a data model XML file,
always download a new version of the file. It’s possible that there have been changes to the file since you last
worked on it.
Procedure
1. Go to Admin Center Employee Files .

2. Choose the relevant link to work with the desired data model file.
To work with... Select Link
Succession Data Model (SDM) Export Succession Data Model
Country/Region Specific (SDM) Export Country-Specific Succession Data Model
3. Export the XML file.

a. To export the xml file, select Export Succession Data Model or Export Country- Specific Succession Data
Model.
b. Save the exported file as a new file so you have a backup.

 Note
All previous versions of Country/Region-Specific Succession Data Model are now available in Admin Center
and Provisioning.
You now have the option to access previous versions of the Country/Region-Specific Succession Data
Model in Admin Center and Provisioning, and restore a version for your environment. Every time you import
the Country/Region-Specific Succession Data Model in Provisioning, the system automatically saves the
import file as a new version. You can restore the data model to a specific version from the list. The version
list can now store and display up to 100 previous versions. Earlier versions are deleted when the limit is
reached.
 Remember
implementation partner or Account Executive. For any non-implementation tasks, contact Product
Support.
Results
The XML file is successfully downloaded to perform your edits.
Task overview: Data Models in SAP SuccessFactors [page 6]
Related Information

Working with Corporate Data Model and Country/Region-Specific Corporate Data Model in Admin Center [page
12]
1.2 Working with Data Model Files in Provisioning
Learn how to begin working with your data model files.
Prerequisites
You have access to Provisioning for your company instance.

 Remember
Context
All SAP SuccessFactors instances are created as a clone of a master instance and have basic data models. If the
out of the box data models don’t work for you, you can then download and modify the data model files in your
favorite XML editor.
 Tip
Even if you’ve already downloaded a file from an instance, before beginning work on a data model xml file,
worked on it.
Procedure
1. Log in to provisioning
2. Click on your instance in provisioning
3. Scroll down to the Succession Management Section.
To work with... Select Link Notes
Succession Data Model (SDM) Import/Export Data Model System now does version control for
you when it comes to Succession Data
Model. When importing, you’re required
to comment on the changes made. Pre
vious versions of the data model are
stored in system.
Country/Region Specific SDM Import/Export Country/Region Specific

XML for Succession Data Model
Corporate Data Model (CDM) Import/Export Corporate Data Model The first data model you would set up if
XML starting with a new instance
Country/Region Specific CDM Import/Export Country/Region Specific

XML for Corporate Data Model
 Note
Corporate Data Model is the first data model you would set up in an instance.

 Caution
We recommend that when uploading the country/region specific data models, you remove any countries/
regions and fields that you don’t need before uploading the XML for the first time. If you upload the
complete data model, the upload takes longer due to the number of countries in the XML file.
 Remember
When uploading a data model that contains references to rules which doesn’t exist in the system, your
business rule will not sync to BCUI. To solve this issue, we recommend that once you’ve created rules in the
system that are referenced in Succession data model, either run Synchronize Business Configuration job or
re-upload the data model.
5. Export or Import the XML file.

○ To export the xml file, use the radio button by Export. Click Submit
○ Save the exported file as a new file so you have a backup.
○ To import, use the radio button by Import. Use Browse to find the file on your local machine and then click
Submit.
Related Information
Working with Corporate Data Model and Country/Region-Specific Corporate Data Model in Admin Center [page
12]

1.3 Working with Corporate Data Model and Country/Region-
Specific Corporate Data Model in Admin Center
Corporate Data Model and Country/Region-Specific Corporate Data Model use XML. You can download these XML
files from Admin Center. You then work with files in an XML editor of your choice and edit them offline. You upload
these modified files back to the company instance you’re working using Admin Center.
Prerequisites
It’s important to enable the required role-based permissions. To get started ensure, you enable Manage
Foundation Objects Import/Export Corporate Data Model or Import/Export Country/Region Specific XML for
Corporate Data Model
Context
You can import or export Corporate Data Model and Country/Region-Specific Corporate Data Model in Admin
Center.
 Tip
Even if you’ve already downloaded a file from an instance, before beginning work on a data model XML file,
worked on it.
Procedure
1. Go to Admin Center Foundation Object Configuration .

2. Choose either Import/Export Corporate Data Model or Import/Export Country/Region Specific XML for
Corporate Data Model.
Corporate Data Model (CDM) Import/Export Corporate Data Model XML
Country/Region-Specific CDM Import/Export Country/Region Specific XML for Corporate

Data Model

 Caution
We recommend that when uploading the country/region-specific data models, you remove any country/
region-specific fields that you don’t need before uploading the XML for the first time. If you upload the
complete standard data model, the upload takes longer due to the number of countries in the XML file.
3. Import XML file.

a. From the Select the action you want to perform drop-down select Import.
b. Browse for the required XML file.
c. In the Comment field add you comments regarding the data model and choose Import.
4. Export the XML file.
a. From the Select the action you want to perform drop-down choose Export.
b. Choose Export and save the exported file as a new file so you have a backup.
 Note
You can view all your uploaded versions of the Corporate Data Model and Country/Region-Specific
Corporate Data Model in Admin Center and Provisioning.
You now have the option to access previous versions of the Corporate Data Model and Country/Region-
Specific Corporate Data Model in Admin Center and Provisioning, and restore a version for your
environment. Every time you import the Corporate Data Model and Country/Region-Specific Corporate Data
Model in Provisioning, the system automatically saves the import file as a new version. You can export any
of the previous version of the data model and then re-import the data model to restore the old version. The
version list can now store and display up to 100 previous versions. Earlier versions are deleted when the
limit is reached.
 Remember
Support.
Results
A success message displays to inform you that the import or export task is done.
Related Information

1.4 Data Model Definitions (DTDs) for SAP SuccessFactors

Data Models
Where can you find the Data Model Definition (DTD) files used by the SAP SuccessFactors HXM Suite?
Data Models in Scope of This Guide and Their DTDs

Data Model DTD
Succession Data Model (SDM) sf-form.dtd
Country/Region Specific Succession Data Model (CSFSDM) country-specific-fields.dtd
Corporate Data Model (CDM) corporate-datamodel.dtd
Country/Region Specific Corporate Data Model (CSFCDM) country-specific-fields.dtd
 Note
sf-form.dtd is also used by other modules in SAP SuccessFactors.
Parent topic: Data Models in SAP SuccessFactors [page 6]
Related Information
Working with Corporate Data Model and Country/Region-Specific Corporate Data Model in Admin Center [page 12]

1.5 Adding Picklists to Fields in the Data Model XML
Picklists are defined in the Picklist Center. The picklist ID is referred to in the data model configuration. The fields
with picklists IDs then appear as drop down lists on the UI.
Prerequisites
● You’ve created the picklist.

● You’ve downloaded the data model and have the file open for editing in an XML editor.
 Remember
Support.
Context
Userinfo elements, background element fields and HRIS element fields, and some standard elements, can have
picklists associated with them.
 Note
The data fields can be in the Succession Data Model, Corporate Data Model, or the Country Specific Data
Models.
Procedure
1. Note the Code for the picklist that you’ve created.

2. Find the id of the element or field you’re to modify.
The id can be from:

○ a standard-element
○ a userinfo-element
○ a data-field of a background-element
○ a rating-field of a background-element
○ an hris-field of an hris-element
3. Add the id to the element or the field

 Caution
Some legacy standard fields can’t have picklist IDs associated with them
Find the end tag of the element or field and add the reference to the picklist before the end tag as in the code
sample.
 Sample Code
<hris-field max-length="128" id="suffix" visibility="none">

<label>Suffix</label>
<picklist id="namesuffix"/>
</hris-field>
If you have configured cascading picklists, a parent child relationship is created between the data fields using
the cascading picklists. You use the parent-field-id tag to refer to the parent data field to configure this
relationship. Consider the code sample. Here picklist IDs language and variant have a cascading relationship in
the system. When configuring the background element, the parent data-field ID language is used for data-
field variant. This configuration ensures that when a Language is chosen while entering data for Language
Skills on the user interface, the Language Variant choices you see are those associated with the language
chosen from the dropdown.
 Note
The data-field and the picklist id aren’t required to be the same.
 Sample Code
<background-element id="languages" type-id="11">

<label>Language Skills</label>
<data-field id="language" field-name="vfld1" max-length="4000" max-file-
size-KB="1000">
<label>Language</label>
<picklist id="language"/>
</data-field>
<data-field id="variant" field-name="vfld5" max-length="4000" max-file-
size-KB="1000">
<label>Language Variant</label>
<picklist id="variant" parent-field-id="language"/>
</data-field>
</background-element>
Related Information
Working with Corporate Data Model and Country/Region-Specific Corporate Data Model in Admin Center [page 12]

2 Introduction to Foundation Objects
Foundation objects are used to set up data that can be shared across the entire company, such as job codes,
departments, or business units. Foundation objects are sometimes referred to as “foundation tables”.
Foundation objects are the first objects you should load because some of the lists of values proposed in
employment information come from the Foundation Objects.
You can use Foundation Objects to populate data at the employee level. For example, if you assign a job code to an
employee, that employee’s record is then populated with all information based on the attributes of the job code.
Additionally, the relationships that are configured between the Foundation Objects can be used to filter the lists of
values in Employment Information. For example, the list of pay components that are selectable on an employee’s
record can be filtered based on the country the employee is associated with as determined by the employee’s Legal
Entity.
Some Foundation Objects are predelivered for you in the Corporate Data Model. For a list of these object, refer to
Predelivered Foundation Objects in Corporate Data Model in the SAP SuccessFactors Data Model Reference Guide
on the SAP Help Portal.
Importing Foundation Objects
You need to import the data into the system using different methods and in a specific order. The import methods
are as follows:
● Foundation Data Imports

○ Managed through the Corporate Data Model using the Import Foundation Data page
○ Managed through MDF using the Import and Export Data Import Data page
● Position Management Imports
● Employee Data Imports
The order of imports into Employee Central is critical. The Basic Import gets the employee started in the
system and each of the subsequent imports populate a different block in the employee’s file. For example, the
third import, Employment Details Import, populates the Employment Details block. At minimum you have to
import the six following files:
1. Basic Import
2. Biographical Information Import
3. Employee Details Import
4. Job History Import
5. Compensation Information Import
6. Personal Information Import

Introduction to Foundation Objects CONFIDENTIAL 17
Accessing Foundation Objects
● You create and update MDF Foundation Objects in the Corporate Data Model. To manage Legacy Foundation
Object data, choose Admin Center Manage Organization, Pay, and Job Structures .
● You create and update MDF Foundation Objects using Admin Center Configure Object Definitions . To
manage MDF Foundation Object data, choose Admin Center Manage Data .
● Ad-hoc reports work based on both the migrated and Legacy Foundation Objects. For Advanced Reporting
(ODS), the reports will be migrated when you first invoke the reports after migration.
Related Information
Importing Foundation Data

Employee Data Import Process
2.1 Characteristics of Foundation Objects
Here's a summary of the features available in foundation objects.
Features
● Each foundation object consists of one or more fields. Some of them are required if you use the relevant object.
● Each foundation object has a technical ID, called an hris-element-id. You cannot change this.
● For each foundation object, you must enter an external code. This is a short unique identifier.
 Note
Once you've entered the external code, do not change it, as this can lead to data inconsistencies.
● Each standard field within a foundation object also has a technical field ID. You cannot change this.
● However, you can change the labels of the foundation objects and the fields each object contains. The label is
the descriptor that appears on the user interface (UI).
● The order in which the fields are displayed on the UI is the same as the order in which you list them in the setup
of the foundation object.
For Legacy FOs only: The start date will always appear at the top of the screen.
● You can decide whether a field actually appears on the UI and, if so, whether:
○ It is required or optional
○ It is read-only or whether users can change or edit it
● Every foundation object contains custom fields. These are empty fields you can use to handle data not covered
by the standard fields.

18 CONFIDENTIAL Introduction to Foundation Objects
● Many, but not all foundation objects, are “effective dated”.
● For each foundation object, you can determine the relationship to other foundation objects through the use of
“associations”.
● The use of onChange business rules isn't supported for foundation objects.
● The search criteria for foundation objects can only be string texts. They cannot be picklists or generic objects.
 Note
For example, if you configure the city field in the Corporate Data Model as a picklist for a country/region X,
you can’t use city in the search criteria for location. If you do, you won’t be able to search locations by city
for country/region X.
2.2 MDF vs. Legacy Foundation Objects
There are many similarities between MDF Foundation Objects and Legacy Foundation Objects. Both serve to
provide foundational data that organizations can use to structure their companies. Both provide the ability to store
attributes on the object level that can be referenced or propagated to the employee’s job and compensation
records.
However, MDF and Legacy Foundation Objects are built on two separate platforms, which result in different ways of
accessing, configuring, and managing the objects and corresponding data. Below is a table which summarizes the
key differences between the two object types.
Legacy Foundation Object MDF Foundation Object
Configuring the Object Provisioning Corporate Data Model Admin Center Configure Object
and CSF Corporate Data Model Definitions
 Remember
As a customer, you don't have ac
cess to Provisioning. To complete
tasks in Provisioning, contact your
implementation partner or Account
Executive. For any non-implementa
tion tasks, contact Product Support.
Managing the Object Values/Data Admin Center Manage Admin Center Manage Data
Organization, Pay, and Job Structures
Importing Object Values/Data Admin Center Import Foundation Admin Center Import and Export
Data Data

Legacy Foundation Object MDF Foundation Object
Exporting Object Values/Data Ad Hoc Report Report Definition Admin Center Import and Export
Type “Foundation Objects” Data
Mass Deleting Object Values/Data Manual deletion only using Admin Admin Center Import and Export
Center Manage Organization, Pay, and Data
Job Structures Use the “Operation” column to indicate
Alternatively, you can import the founda which data should be deleted upon im
tion data and switch the “status” from port.
“Active” to “Inactive”
Permissions for the objects and data Manage Foundation Object Types MDF Foundation Objects
Custom Fields You are limited to 20 of each type: There is no limit to the number of custom
fields you can create for MDF objects. In
● String
addition to the data types supported for
● Date
Legacy FOs, there are additional field
● Decimal
types available.
● Long
For more information, refer to the Imple
● Number
menting the Metadata Framework guide
on the SAP Help Portal.
In addition to the differences in maintaining the tables and data, there are vast differences in the supported
functionality and capabilities of the two object types. All functionality that is supported for Legacy Foundation
Objects is supported for MDF Objects (associations, field-level configuration, picklists, and so on). However, the
opposite is not true – all functionality that is supported for MDF Objects is NOT supported for Legacy Foundation
Objects. MDF Objects contain a plethora of additional supported capabilities, including the support of business
rules, field-level permissions, and more. MDF Foundation Objects and MDF Generic Objects are created and
maintained under the overall MDF platform.
Related Information
Implementing the Metadata Framework (MDF)

Migrating to MDF Foundation Objects
2.3 Requirements for Legacy Foundation Objects
Here are the requirements for the use of legacy foundation objects.
With Employee Central

To enable legacy foundation objects in your system, do the following:

● In Provisioning,
○ Enable Employee Central Foundation Objects
○ Activate the Enable Translation of Employee Central Foundation Objects setting
 Remember
Support.
● Import the Corporate Data Model. If you've enabled Employee Central, foundation objects such as Location
are predelivered in the Corporate Data Model.
● Enable the role-based permissions for the foundation objects.
○ Admin Permissions Manage Foundation Objects
○ Admin Permissions Manage Foundation Object Types
As an administrator, you can control access of a user to managing the foundation objects, under User
Permission Settings Permissions... Manage Foundation Objects , Access Manage Organization, Pay and
Job Structures page.
Without Employee Central

If you haven't enabled Employee Central, you can still use legacy foundation objects by following the preceding
steps.
 Remember
To use foundation objects without Employee Central, you must configure foundation objects, for example,
Location, in the Corporate Data Model.
Related Information
Introduction to Foundation Objects [page 17]
2.4 Deleting a Foundation Object
To correct an error, you may need to delete a foundation object or a foundation object value at some point.
Context
If a Foundation Object value is required to be removed from the UI, it is vital to consider the following points:
● Do not delete a Foundation Object value that at some stage has been used in an employee’s data. If a value
should be removed from the UI, it is recommended to set the “Status” of the value to “Inactive” rather than

delete it from the system. This allows for a proper audit of the data to be maintained in the system, and
eliminates the risk of unexpected system behavior.
● If a value needs to be deleted from the system, first run a Person and Employment Export Ad Hoc report to
determine if any users have the value associated with their Employee Central data. Certain objects, such as the
Pay Component FO, will not allow for deletion of values if they have been added to employee data (both current
and historical records).
 Note
SAP SuccessFactors does not support mass deletion of Legacy Foundation Objects. Legacy Foundation Objects
must be deleted individually on the User Interface or mass-inactivated through import.
Procedure
1. To manually delete a foundation object value, complete the following:
a. Go to Admin Center Manage Data .

b. Search for the object and select it.
c. Under Take Action, select Permanently Delete Entry.
2. To mass delete MDF Foundation Objects, use the Import and Export Data tool.
a. Go to Admin Center Import and Export Data .

b. Choose Export Data, then select the object. Remove all values that do not need to be deleted.
c. Select Export.
d. For any remaining values that need to be mass-deleted, insert the key “Delete” in the [OPERATOR] column.
e. Validate the data and then import the data back to the system.

3 Corporate Data Model
Corporate Data Model defines the organization-related data in XML, which are also Foundation Objects. Some of
these Foundation Objects can also be defined as MDF Objects. MDF Objects aren’t in scope for this document. This
data model also has relationship between the foundation objects configured in it.
When beginning work on a new instance, Corporate Data Model is the first data model you would set up.
Corporate Data Model is where you define how the organization, pay, and job structures that define the company
are reflected in the system. For example, a Job Code can be associated with multiple countries. For such cases,
allow a single job code to be assigned to multiple countries. You set up the job code by defining foundation objects
in the Corporate Data Model and define the relationships between them by creating associations in the XML file for
the data model. You also define what fields are used on the UI, what they’re called, and which fields are hidden. You
can also add customer-specific fields.
Starting with the November 2014 release, organization structures are being migrated to MDF objects in a phased
manner. MDF Foundation Objects are configured using the Configure Object Definition page and are managed using
the Manage Data page in the Admin Center.
You can maintain associations between a Foundation Object and an MDF Foundation Object by configuring the
associations using the Configure Object Definition page or the Corporate Data Model xml, depending on the
scenario.
3.1 Components of Corporate Data Model XML
Corporate Data Model xml file contains elements, fields, associations, and search criteria.
These Corporate Data Model XML components... ...define the following
hris-element Foundation object for organization-related data in your in

stance
hris-field Foundation fields for each foundation object for the default
country
hris-associations Relationship among the tables
trigger-rule Rules to influence behavior of elements and fields on the UI
search-criteria Search field for the foundation object
Related Information

Modifying HRIS Elements [page 36]

Corporate Data Model CONFIDENTIAL 23
Deleting HRIS Elements [page 38]
Modifying HRIS Fields [page 39]
Mandatory HRIS Fields for the HRIS Elements in the Corporate Data Model [page 41]
3.2 Predelivered Foundation Objects in Corporate Data Model
The master Corporate Data Model that you download from the help portal includes the foundation objects listed
here.
Foundation Objects Predelivered in the SAP SuccessFactors Master Corporate Data Model
HRIS-element ID (Don’t Standard Label (Visible on Data Object Type Subtype
Change) the UI)
locationGroup Location Group Foundation object Organization structure
geozone Geo Zone Foundation object Organization structure
location Location Foundation object Organization structure
payRange Pay Range Foundation object Pay structure
payGrade Pay Grade Foundation object Pay structure
payComponent Pay Component Foundation object Pay structure
payComponentGroup Pay Component Group Foundation object Pay structure
frequency Frequency Foundation object Pay structure
corporateAddress — Part of foundation object loca Organization structure

tion
dynamicRole Dynamic Role Foundation object Dynamic Role
dynamicRoleAssignment — Part of foundation object dy Dynamic Role

namicRole
wfConfig Workflow Foundation object Workflow
wfConfigStep — Part of foundation object Workflow

wfConfig
wfStepApprover — Part of foundation object Workflow

wfConfig
wfConfigContributor Contributor Type Part of foundation object Workflow

wfConfig
wfConfigCC Cloud credit(s) Role Type Part of foundation object Workflow

wfConfig
eventReason Event Reason Foundation object Event reason
 Note
The fields for the foundation object jobClassLocal are defined in the Country/Region-Specific Corporate
Data Model. Additionally, the country/region-specific address for the location Foundation Object is also
defined here.

24 CONFIDENTIAL Corporate Data Model
3.3 Creating Customer-Specific Foundation Objects
You can create additional foundation objects (HRIS Elements) to fit your business needs if the predelivered objects
don’t fit them. For example, your organization has levels in your organizational hierarchy such that you need a new
foundation object “Sub-Department”.
Prerequisites
You’ve downloaded the Corporate or Succession Data Model and have the file open for editing in an XML editor.
You've created a generic object in your instance
 Note
For information on how to create a generic object, see the Implementing the Metadata Framework guide on the
SAP Help Portal.
 Remember
Procedure
1. Assign the Generic Object you’ve created to the relevant data model.
a. If assigning the Generic Object to a Legacy Foundation Object
1. In the Corporate Data Model, add a customer-specific field as a custom-string and add the type
attribute referencing the external code of the generic object.
<hris-element id="jobInfo">
<label>Job Information</label>
<hris-field max-length="256" id="custom-string5" visibility="both"
type="GO_Building" >
<label>Building</label>
</hris-field>
 Note
Use only a custom-string as customer-specific field when you use the type attribute with generic
objects.
1. Save your changes and upload the data model in Provisioning.

b. If assigning the Generic Object to an MDF Foundation Object or other Generic Object
1. Navigate to the Configure Object Definition page and search for the destination object.
2. Make a Correction, and add a new custom field. In the Details link, at a minimum, fill out the following
fields:

○ Data Type = Generic Object
○ Valid Values Source = the ID of the Generic Object
c. If assigning the Generic Object to the Succession Data Model
1. Navigate to Manage Business Configuration, and select the relevant HRIS Element.
2. Create a new custom string field and fill out the required information.
3. Open the Details of the field, and update the following fields:
4. ○ Type of Reference Object = Foundation Object
○ Reference Object = the ID of the Generic Object
○ Visibility = View or Edit
2. Save your changes.
3. Assign role-based permissions for the custom field you’ve added.
3.4 List of HRIS XML Elements and Attributes
Here is an overview of the HRIS XML elements and attributes that are most commonly used in the data models.
 Note
● XML elements can contain other XML elements nested inside them. For example, the hris-element XML
element can contain label and hris-field XML elements:
<hris-element id=”location”>
<label>Location</label>
<hris-field max-length="32" id="externalCode" visibility="both"
required="true" pii="false" showTrailingZeros="false" >
<label>Code</label>
</hris-field>
<hris-associations>
<association id=”id” multiplicity=”ONE_TO_ONE” destination-
entity=”geozone” required=”false” />
</hris-associations>
<search-criteria>
<search-field id=”corporateAddress.city” />
</search-criteria>
</hris-element>
● XML elements can contain several attributes, for example, the XML element hris-field contains the
attributes max-length and id:
<hris-field max-length=”256” id=”amount”>
● Attributes are name-value pairs; it’s predefined which values can be entered for which attributes. In the
following example, the attribute with the name max-length can have a number as a value:
max-length=”256”

<hris-element>
You can include these XML elements or attributes: How to use this XML element or attrib
ute:
Attribute id This is the identifier for an HRIS element,

which represents one foundation object,
or one person or employment object.
This ID can’t be changed. To get the hris-
element id of an object, refer to the Data
Object Tables Reference.
Element description This is where you enter a text that de

scribes an XML element, or what the
data model is used for, for example. This
description doesn’t appear on the UI.
Element label This is the text that is shown on the UI.

You can change it if the customer wants
to use a different naming. This text is also
translatable.
Element trigger-rule This is used to assign a configurable rule

the customer has created to a user ac
tion on the user interface. For example,
when a page is loaded or saved, a specific
system behavior defined in the configu-
rable rule is triggered.
Element hris-field With hris-field, you define each in

dividual field within this HRIS element.
Element hris-associations Associations define the relationship be

tween foundation objects.
 Note
Associations can only be defined in
the Corporate Data Model.
Element search-criteria Search criteria define what fields can be

used to search this HRIS element.

<hris-field>
You can include these XML elements or attributes: These are possible attribute How to use this XML element
values: or attribute:
Attribute max-length 256 This defines the maximum

length of this field on the UI.
For boolean fields, you can

leave out this attribute.
Attribute id start-date This is the identifier for a field

within an HRIS element.
This ID can’t be changed. To

get the hris-element id of an
object, refer to the Data Object
Tables Reference.
Attribute visibility ● none The visibility defines if this

● view field is visible on the UI:
● both ● “none”: Field is hidden.

You can’t import data for
this field via CSV files.
● “view”: Field is read-
only. You can’t import
data for this field via CSV
files.
● “both”: Field is visible
on the UI and can be
edited.
Attribute required ● true If this is set to “true”, the

● false field becomes mandatory —
that means a user entry is re
quired — and is marked as
such on the UI.

Attribute pii ● true If this setting is true

● false (pii=”true”), it defines
that the field is a sensitive
field; as such, it is masked on
the screen for security rea
sons. This is a setting used for
password fields, for example.
When the user enters their
data, only asterisks or similar
symbols are shown on the UI
instead of the actual data en
tered. This is done to prevent
over-the-shoulder snooping
for the user's password.

Attribute maximumFractionDigit Possible values are 0–5: With this XML attribute, you
s define how many decimal dig
● 0
its are shown after the decimal
● 1
point. Depending on the num
● 2 ber of decimal digits you indi
● 3 cate here, the numbers dis
● 4 played in the system get
rounded up or down.
● 5
You can use this property only
for HRIS fields with the data
type DOUBLE, and you can
define up to 5 decimal places.
If you don’t use this attribute
for a DOUBLE data type, the
number is rounded to three
decimal places by default. If
you define a value higher than
5, the system uses the maxi
mum value, which is 5. If you
define a negative value, for ex
ample, -1, the default value of
3 decimal places is used. Ex
ample:
maximumFractionDigit
s=”2”
If the user enters 4.394 on the

UI and the
s have been defined to 2, the
system reduces the decimal
digits from 3 to 2 as defined in
the data model and rounds
down the value to show the
following:
4.39
 Note
Make sure that the follow
ing HRIS fields use the
same

maximumFractionDi
gits value:
● payComponentVa
lue of HRIS element
payComponent
● paycompvalue of
HRIS element
payComponentRe
curring
● value of HRIS ele
ment
payComponentNo
nRecurring
The pay component value

field of the pay compo
nent foundation object is
reused in the compensa
tion information. If you
then choose to override
this field and the value of
the
maximumFractionDi
gits attribute is different
for the fields, it leads to an
error.

Attribute showTrailingZeros ● true With this XML attribute you

● false define if trailing zeros after a
decimal number are dis
played, and how many. You
can use this attribute only for
HRIS fields with the data type
DOUBLE. If you don’t use this
attribute for a DOUBLE data
type in the XML file, by default
no trailing zeros are shown.
If
s is set to 4 and
showTrailingZeros is
set to “true”, and the user
enters 1.3 on the UI, the value
is displayed as follows:
1.3000.
Element label — This is the text that is shown

on the UI. You can change it if
the customer wants to use a
different naming. This text is
also translatable.
Element trigger-rule — This is used to assign rules the

customer has created in the
rules engine to a user action
on the user interface. When a
field is changed, a specific
system behavior defined in the
rule is triggered.
Element picklist — If the value of this HRIS field

comes from a picklist, define
the associated picklist infor
mation.

<hris-associations> (Only Valid for Corporate Data Model)
Element association — Associations define relation

ships between foundation ob
jects, or between a foundation
object and a generic object.
Attribute id The only possible value is: This is the identifier for an as
sociation between this foun
id
dation object and another ob
ject; don’t change this value.
Attribute multiplicity ● ONE_TO_ONE Multiplicity defines whether

● ONE_TO_MANY this relationship is
ONE_TO_ONE or
ONE_TO_MANY. If you create
new associations, define the
multiplicity as
ONE_TO_MANY.
Attribute destination-entity ● division This is where you define the

● company other foundation object or ge
● Generic_Object_Bu neric object that this object

has a relationship with. You
ilding
enter the HRIS-element ID of
that foundation object or the
external code of the generic
object as attribute value. The
destination entity is the con
trolling object of the associa
tion.
Attribute required ● true If this is set to “true”, the

● false field becomes mandatory —
that means a user entry is re
quired — and is marked as
such on the UI.

<search-criteria>
You can include these XML elements or attributes: How to use this XML element or attrib
ute:
Element search-field This defines a searchable field of this

HRIS element.
You can define search criteria that are

used to find an entry in the system. In the
following example, you define that you
can search for a location by entering a
city or a country/region. The system then
tries to find a match with the information
stored in the corporate address and
shows the corresponding result.
Attribute id This is the ID that the system is searching

for. You use the HRIS-element ID followed
by the HRIS-field ID, separated by a pe
riod.
<label>
Attribute xml:lang ● en-GB The label that appears on the

● fr-CA UI can also be translated into
● it-IT other languages using the

xml:lang attribute and the
corresponding language code.
The corresponding transla
tions are stored in the XML file
for the data model.
If the system doesn’t find a

corresponding label for the
system language, it applies
what the language it comes
across first (in the following
order): (1) Locale of the user
logged in, (2) company's de
fault locale, (3) label config-
ured without xml: lang and (4)
if none of these exist, it uses
the default system label.

<trigger-rule>
Attribute event For hris-elements: This is the event on the user

interface that triggers the exe
● onInit
cution of the rule. Possible val
● onSave
ues are:
● onView
● onInit: Rule is trig
● onEdit
gered when the page is
● saveAlert loaded
For hris-fields: ● onSave: Rule is trig

gered when a page or
● onChange
HRIS-element is saved
● onChange: Rule is trig
gered when a field is
changed.
● onView: Rule is trig
gered when the block or
page with transient field
is loaded
● onEdit: Rule is trig
gered when the block or
page is opened in edit
mode
● saveAlert: Rule is trig
gered when a data record
change has taken place
and the current date is
equal or after the effec-
tive date of the defined
alert
Attribute rule external code of the rule This is the rule that is trig
gered when the event on the
user interface takes place. You
must have defined this rule in
the Rules Engine and refer to
the external code of the rule.

3.5 Modifying HRIS Elements
You can modify your HRIS elements in the data models to fit your business needs.
Prerequisites
You’ve downloaded the data model and have the file open for editing in an XML editor.
 Remember
Context
HRIS elements are found in Succession Data Model and Corporate Data Model.
 Caution
Don’t modify the id of the elements. The id is the key that is used to refer to the field in other parts of the
application.
Procedure
● Change element label
Overwrite the existing label in the element. If there are other language labels present in your HRIS element,
they also can be modified.
If the system does not find a corresponding label for the system language, it displays one of the following
(depending on the following order):
1. Locale of the user logged in

2. Company's default locale
3. Label that has been configured without the xml:lang attribute; in the example above, “Location” would be
displayed.
4. If none of the above has been configured, the system uses the default system label.
● Change search criteria
Add search criteria to a field by adding the <search-criteria> subelement to an HRIS element.

(For example, the code example is added to the location HRIS element. When the user searches for existing
locations by city or country/region name, the system searches the entries of the fields “city" and “country" of
the HRIS element “corporateAddress" (also defined in the Succession Data Model), for a match.
...
<search-criteria>
<search-field id="corporateAddress.city" />
<search-field id="corporateAddress.country" />
</search-criteria>
</hris-element>
 Note
Search criteria can only be string fields. They can’t be picklists or generic objects.
● Change associations
To define relationships between foundation objects, or between a foundation object and a generic object, set
up new associations or change the associations included in the standard XML file. The associations are the
final subelement of the hris-element included before the HRIS element end tag. You then define whether it’s
a ONE_TO_ONE or a ONE_TO_MANY association.
<hris-element id="location"> ... <hris-associations> <association id="id" multiplicity="ONE_TO_MANY"
destination-entity="locationGroup" /> </hris-associations> </hris-element>
Related Information
3.5.1 Associations in the Corporate Data Model
You create associations in the XML file for the data model to define the relationships between foundation objects.
 Note
When maintaining associations between a Foundation Object and an MDF Foundation Object, configurations
can be specified using the Configure Object Definition page or the Corporate Data Model, depending on the
scenario.
For more information, see the Working with MDF Foundation Objects section in this guide.
For Foundation Objects, you can only define a ONE_TO_MANY association and not a MANY_TO_ONE association.
In most cases, the one object typically filters the many object. However, it is recommended that associations be
modeled on the many object rather than the one object to achieve the required filtering behavior.
 Note
For the destination-entity, enter the HRIS-element ID of the foundation object, or the external code of the
generic object you want to associate the foundation object with.

Assuming the job codes ENG01 and ENG02 are applicable to “Philadelphia" and you would like to filter job codes by
location. Logically, this would be a MANY_TO_ONE relationship from the jobCode to the location. However, as only
ONE_TO_MANY associations are supported, this would need to be configured as a one-to-many association from
jobCode to location. Once this association has been defined, the valid locations can be attached to the job codes in
Employee Central when setting up the job codes on the UI. You do this under Admin Center Employee Files .
<hris-element id="location">
...
<hris-associations>
<association id="id" multiplicity="ONE_TO_MANY" destination-
entity="locationGroup" />
</hris-element>
The following example shows the ONE_TO_ONE associations from payRange to the foundation objects geozone
and payGrade. Do not create more ONE_TO_ONE associations than those that are predelivered in the standard
XML file.
<hris-element id="payRange">
...
<hris-associations>
<association id="id" multiplicity="ONE_TO_ONE" destination-entity="geozone" />
<association id="id" multiplicity="ONE_TO_ONE" destination-entity="payGrade" />
</hris-element>
3.6 Deleting HRIS Elements
You can customize your foundation objects by modifying the HRIS Elements in the Corporate Data Model and
Succession Data Model. This customization can include removing an element entirely.
Prerequisites
● You've downloaded the data model and have the file open for editing in an XML editor.
● You’ve removed the HRIS element from the country specific Succession Data Model or the country specific
Corporate Data Model, and uploaded the data model file.
 Remember
Context
Don’t delete the Company element. This element is required.

An element you’re considering deleting may have dependencies on another data model. Some of the foundation
objects defined in the Corporate Data Model are used for fields that are part of person or employment objects
defined in the Succession Data Model. For example, when you delete the location HRIS element from the
Corporate Data Model, you also delete the location field from the Succession Data Model (which belongs to the
HRIS element jobInfo), or set its visibility to "none", so it doesn’t appear on the UI. Otherwise, the user
continues to be able to select the location field in the Job Information block on the UI but be unable to change
the field.
Procedure
● Delete the desired HRIS element
Delete everything between the hris-element tags including the tag
 Note
○ When you delete an HRIS element, the corresponding block is no longer shown on the UI.
○ You cannot delete the following mandatory HRIS Elements:
○ employmentInfo
○ jobInfo
○ personInfo
○ personalInfo
Related Information

Associations in the Corporate Data Model [page 37]
3.7 Modifying HRIS Fields
You can customize your foundation objects by modifying the HRIS Elements in the Corporate Data Model and
Succession Data Model. This customization can include modifying the fields that belong to the foundation objects.
Prerequisites

 Remember
Context
Multiple fields of various types together form an HRIS element. You see more attributes for a field than what you
need to change. You can modify some of the attributes of your HRIS fields to fit your business needs.
Procedure
● Change a field label.

Overwrite the existing label in between the label tags in the field. You can also modify labels for other
implemented languages.
If the system does not find a corresponding label for the system language, it displays one of the following
(depending on the following order):
1. Locale of the user logged in

2. Company's default locale
3. Label that has been configured without the xml:lang attribute; in the example above, “Location” would be
displayed.
4. If none of the above has been configured, the system uses the default system label.
● Change the field visibility
Change the visibility attribute.
○ “none”: Field is hidden. You can’t import data for this field using CSV files.
○ “view”: Field is read-only. You can’t import data for this field.
○ “both”: Field is visible on the UI and can be edited. You can also import data for this field using CSV files.
 Note
To allow data import for a field with visibility=”view”, you can add the attribute allow-
import=”true” to the field. For example, for your company, the employee ID field is system-generated.
You thus prevent the user from accidentally changing the ID by setting it to read-only. However, you have
existing data for the employees, including their IDs, which you wish to upload using CSV file. Add the
allow-import=”true” to the field definition as in the example:
<hris-field max-length=”32” id=”person-id-external” visibility=”view” allow-

import=”true”>
<label>Employee ID</label>
</hris-field>
The person-id-external field is an exception: You can also use the allow-import attribute when this
field is hidden (that is, with visibility=”none”).

● Change field requirement
Change the required attribute.
 Note
The following fields are required on the UI even if required=”false” in the data model:
○ start-date
○ externalCode
○ status
○ Other mandatory fields for an element
● Masking data entry on screen.
Change the piiattribute

● Referencing customer-specific objects
a. Add a custom field of type custom-string
b. Add type attribute to the new field referencing the customer-specific foundation object as in the example
<hris-field max-length="256" id="custom-string5" visibility="both"

type="Generic_Object_Building">
<label>Building</label>
</hris-field>
 Note
Here Generic_Object_Building is the external code of a customer-specific foundation object.
Related Information
3.8 Mandatory HRIS Fields for the HRIS Elements in the

When defining standard hris-elements, there are fields that are required to be defined for standard functionality to
work as designed. This topic lists the required fields for the Corporate Data Model
For this HRIS element in the Corporate Data Model... ...this HRIS field is always required:
corporateAddress country
dynamicRoleAssignment person

For this HRIS element in the Corporate Data Model... ...this HRIS field is always required:
eventReason event
frequency annualizationFactor
payComponent payComponentType
payRange frequency
wfConfigCC actorRole
actorType
context
wfConfigContributor actorRole
actorType
context
wfStepApprover approverRole
approverType
context
3.9 Dependencies of Corporate Data Model
Corporate Data Model is a core data model for organization data. The fields defined therein can have impact on
other modules.
The advantage of a system like SAP SuccessFactors is easy data flow and ease of data management across various
functional areas or modules. However, for this interphase to work smoothly, right elements have to be in place.
These elements can be data elements in the data model, fields, and their configuration in the target modules, other
features, or permissions.
The Corporate Data Model XML for Requisitions [page 43]

Additional information about configuring the requisition XML.
Determining Pay Ranges in Calculations [page 46]

Determine which pay range an employee is associated with and how the system calculates compa-ratio and
range penetration values.
Creating a Dynamic Role [page 48]

With dynamic roles, you can flexibly assign different users, positions, or dynamic groups as workflow
approvers, contributors, and CC roles according to certain foundation data of the subject user or MDF
position object. So, for employees or positions of a particular job classification, or for a data change to a
particular event reason, the workflow approval requests or notifications are sent to the users or positions
defined in the dynamic role.

3.9.1 The Corporate Data Model XML for Requisitions
Additional information about configuring the requisition XML.
● Ensure that the following declaration is available at the top of every Corporate Data Model XML document:
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE corporate-data-model PUBLIC "-//SuccessFactors, Inc.//DTD Corporate
Data Model//EN" "http://svn/viewvc/svn/V4/trunk/src/com/sf/dtd/corporate-
datamodel.dtd">
<corporate-data-model>
<description>Success Factors HRIS Data Model</description>
● Add hris-element element and id attribute. The Job Classification foundation object is the only foundation
object used in Recruiting, but other HRIS objects are supported for EC in addition to Job Classification. The
HRIS element with id="jobCode" must exist and contain the recruiting-related fields, as shown. The presence
of the jobCode hris-element produces the Job Code option on the Import Foundation Data page.
<hris-element id="jobCode">
● The hris-element can contain multiple hris-field elements. The field elements define the fields in the foundation
object import file:
<hris-field id="custom-string1" visibility="both">

<label>Compensation Title</label>
</hris-field>
<hris-field id="custom-string2" visibility="both">
<label>Grade Level</label>
<picklist id="gradeLevel"/>
</hris-field>
You may configure the following hris-field id values. These field names must be used exactly as listed below:
hris-field id Acts as Field Type
description Text (100 character limit)
custom-string1-15 Text or Picklist (100 character limit)
custom-long1-5 Integer (no decimals)
custom-date1-5 Date
hris-field Element and id Attribute
Other hris-field id values may be supported for use in Employee Central but there’s a mapping process that links
the hris-field ids from the Job Classification foundation object to the jobCode fields in the Requisition form, and
only these hris-field ids are supported in this mapping process. Additional fields can’t be used for Recruiting.
 Tip
The Job Code Entity file can also be set up via a scheduled recurring process in Provisioning. Clients should
either extract the data from the current system of record or they can manually create the file if some of the data
is to come from the system of record and some comes from other systems. If the JCE process is via a
scheduled job from your HRIS, it is possible to do a Full Purge which replaces all existing records, or an

Incremental load, which inserts new records where a match is found, updates records where it does find a
match and leaves existing records alone if they aren’t not mentioned in the import file.
The visibility attribute doesn’t affect Recruiting; unless it has been adjusted for EC reasons, set it to "both".
label Element
<label>Grade Level</label>
The label element controls the appearance of the field name in the user interface for both importing the foundation
data and for the field as it appears in the requisition page, regardless of the field-definition label in the Requisition
XML.
The hris-field element must contain at least one field-label element.
picklist Element and id Attribute
<picklist id="gradeLevel"/>
The custom string hris-field ids can be configured to validate against a picklist upon foundation data import, and
render as picklists on the requisition page. The picklist must be defined in the hris-field in the Corporate Data
Model XML.
Example
This example is for reference purposes, and is not a recommended configuration:
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE corporate-data-model PUBLIC "-//SuccessFactors, Inc.//DTD Corporate Data
Model//EN" "http://svn/viewvc/svn/V4/trunk/src/com/sf/dtd/corporate-datamodel.dtd">
<corporate-data-model>
<description>Success Factors HRIS Data Model</description>
<hris-element id="jobCode">
<hris-field id="name" visibility="both" required="true">
<label>Name</label>
</hris-field>
<hris-field max-length="100" id="description" visibility="both">
<label>Job Description</label>
</hris-field>
</hris-element>
</corporate-data-model>

Configure jobCode Fields in Requisition Template
For each Recruiting-related hris-field configured in the Corporate Data Model, configure a corresponding field-
definition in the Requisition XML.
 Note
The field IDs change between the Corporate Data Model XML and the Requisition XML. Where the Corporate
Data Model states custom-string1, the requisition states customString1 — if you reference these fields in the
Offer Details XML, the field IDs change yet again. To reference this field in the Offer Details XML, you would
configure jce_customString1.
Be sure to configure the standard jobCode field-definition id in the Requisition XML.
<field-definition id="jobCode" type="text" required="true" custom="false">

<field-label mime-type="text-plain"><![CDATA[Job Code]]></field-label>
</field-definition>
<field-definition id="customString1" type="jobCode" required="true"
custom="false">
<field-label mime-type="text-plain"><![CDATA[Compensation Title]]></field-label>
</field-definition>
<field-definition id="customString2" type="jobCode" required="true"
custom="false">
<field-label mime-type="text-plain"><![CDATA[Grade Level]]></field-label>
</field-definition>
field-definition ID Acts as Field Type
description Text (100 character limit)
customString1-15 Text or Picklist (100 character limit)
customLong1-5 Integer (no decimals)
customDate1-5 Date
This data is auto-populated from the foundation data library at the point of requisition creation. There’s no dynamic
link that causes this data to be automatically updated on the requisition if the data in the foundation data library is
changed at a later date.
It’s possible to set the permission of the jobCode fields as editable to users if desired. Ensure that the client gives
careful consideration to whether these fields should be made editable or not.
Import Job Code Foundation Data
You manage the data that populates into these requisition fields by uploading it via the job code CSV template in
Admin Tools Import Foundation Data .
To upload foundation data:
● Download the Excel template by selecting Type: Job Code and clicking the “Download a blank CSV template”
● Populate the Excel file with data

● Select an import type. Full Purge replaces all existing records, and Incremental Load inserts new records where
a match is not found, updates records where it does find a match and leaves existing records alone if they
aren’t mentioned in the import file
● Choose file by browsing your computer
● Click Validate Import File Data to check the file for any possible data errors without importing it, if desired.
● Click Import to import the data
Set Up Job Code Field Preview in Browse Families and Roles
Clients may wish to provide the user more job code related information while they’re selecting from families and
roles during the requisition creation process. Up to five fields can be displayed on the Browse Families and Roles
page under the Job Code.
Parent topic: Dependencies of Corporate Data Model [page 42]
Related Information

3.9.2 Determining Pay Ranges in Calculations
Determine which pay range an employee is associated with and how the system calculates compa-ratio and range
penetration values.
Prerequisites
● Configure the Pay Range foundation object in the Corporate Data Model
● Create associations between Legal Entity and Pay Grade from the Pay Range
 Note
If the pay range should depend on the country/region of the legal entity, it is not sufficient to add the
association to the corporate data model.
 Sample Code
<association id="id" multiplicity="ONE_TO_MANY" destination-

entity="Country" required="false"/>

The reason for this is that there is no standard field of type Country/Region in the Job Information object,
since the field country-of-company is a picklist of type ISOCountryList, and picklists cannot be used in the
pay range determination.
In order to use the country/region as an association for the pay range, it is necessary to:
1. Add a custom field of type country/region (this means that it needs the tag type Country/Region) to
the jobInfo object in the data model.
2. Fill this field using a business rule based on the country/region defined in the legal entity.
 Note
This is so that when the system calculates the Compa Ratio and Range Penetration values, it will look up what,
for example, Legal Entity and Pay Grade values the employee has set in their current Job Information record.
Context
The system looks for a pay range that matches all of the configured objects associated with it. If one exact match is
found, that is used. If several matches are found, the first one found is used. If nothing is found, the last selection
criterion (the last association for payRange) is removed from the search, and the search repeated, and so on.
The Compa Ratio and Range Penetration values are calculated based on Pay Component Groups. You must define
which Pay Component Group is used to calculate both Compa Ratio and Range Penetration. You can use 2 separate
Pay Component Groups for each of the calculations.
To define which Pay Component Group is used for the calculation, do the following:
Procedure
1. Go to the Admin Center Manage Organization, Pay, and Job Structures .

2. Search for the Pay Component Group you want to use.
3. Set the value to Yes for these fields:
○ Use for Comparatio Calculation

○ Use for Range Penetration
Task overview: Dependencies of Corporate Data Model [page 42]
Related Information


3.9.3 Creating a Dynamic Role
With dynamic roles, you can flexibly assign different users, positions, or dynamic groups as workflow approvers,
contributors, and CC roles according to certain foundation data of the subject user or MDF position object. So, for
employees or positions of a particular job classification, or for a data change to a particular event reason, the
workflow approval requests or notifications are sent to the users or positions defined in the dynamic role.
Prerequisites
By default, the system uses the job information of the subject user to determine the assignment of a dynamic role.
To enable the MDF position as the other base object, go to the Corporate Data Model and change the Base Object
field settings so that it’s visible on the dynamic role creation page. For details, see the following setting:
<hris-element id="dynamicRole">
...
<hris-field max-length="128" id="baseObjectType" visibility="both">
<label>Base Object</label>
...
</hris-element>
The corporate data model can be maintained using the Import/Export Corporate Data Model tool.
Context
The dynamic role is created and assigned according to certain foundation objects, such as job classification,
department, pay grade, and event reason. By selecting a base object for the role, you specify how the system
determines the approver assignment, either by the job information or the position information of the subject users.
 Recommendation
Use position-based dynamic roles only in workflows for the MDF Position objects.
Dynamic roles can be defined with positions. Make sure to update the dynamic role assignment when there are
significant changes to the positions used in the role. For example, you have moved a position from US to Canada. If
this position is still used in a dyanmic role for US workflows, the relevant approval requests regarding employees in
US are still sent to the incumbent of this position who is based in Canada.
Procedure
1. Go to Admin Center Manage Organization, Pay and Job Structures Create New and select Dynamic
Role .
2. Specify a dynamic role ID, name, and description.
3. (Optional) Select the base object for the dynamic role:

○ Job Info
The system determines the approver assignment based on the job information of the subject user. Use it in
workflows for user-based MDF generic objects (such as Time Off or Time Sheet workflows) or workflows
for Employee Central objects. In workflows for other objects, such as migrated foundation object workflow,
there is no subject user involved. So, the system uses the job information of the workflow initiator to
determine the dynamic role assignment.
○ Position
The system determines the approver assignment based on the position information of the subject user.
Only use it in workflows for MDF position objects, and the system uses the changed position information to
determine the dynamic role assignment.
If you haven’t enabled the Base Object field, the system by default uses the job information as the base object
for the dynamic role.
4. In the Dynamic Role Assignment section, define how you want to assign approvers, contributors, or recipients
of completion notices and whom (users, positions, or dynamic groups) to include in the dynamic role:
1. Specify a foundation object as the assignment criterion. You can also specify multiple to detail the
assignment. For example, use both the legal entity and pay grade objects to define the assignment for
subject employees who belong to legal entity A and whose pay grade is 7.
2. Select an approver type: person, position, or dynamic group and specify the corresponding approvers.
 Note
Although it says approvers, dynamic roles can also be used as workflow contributors and recipients of
completion notices.
3. Create more assignments if necessary.
You can assign a different approver for each of your legal entities, so that approvers can be determined based
on the legal entity of the workflow subject user.
5. Save the dynamic role.
Results
The dynamic role has been created, and it is available for workflow setup.
Task overview: Dependencies of Corporate Data Model [page 42]
Related Information


4 Succession Data Model (SDM)
Succession Data Model is at the core of SAP SuccessFactors. All modules that use employee-related data elements
in the application are touched by the data model in one way or the other.
Succession Data Model defines objects that are related to the person or the employee in the company. You can
then display these fields in the People Profile based on the field level and/or role-based permissions.
The data that Succession Data Model defines can be of two types:
● Person data:
Data that is employee-based and isn’t related to the job of the employee, for example, the employee's address
or the national ID.
● Employment data:
Data that is job-related, for example, compensation and hire date.
4.1 Components of Succession Data Model XML
Succession Data Model xml elements and attributes are listed for your reference.
Standard Elements in the Succession Data Model [page 51]

Standard Elements (standard-element) in the Succession Data Model define the fields that are seen in
the Personal Information section of the People Profile in SAP SuccessFactors. The standard elements are
single value fields such as name, email, gender, department.
User Info Elements in the Succession Data Model [page 60]

User Info Elements (userinfo-element) are used to define custom fields as well as to define fields used
to integrate with SAP SuccessFactors Recruiting. Each userinfo-element can have more than one value.
Background Elements in the Succession Data Model [page 63]

Background Elements (background-element) in the Succession Data Model are elements where a one to
many relationships exists between the field and the data it can store.
Tab Elements in the Succession Data Model [page 75]

Tab Elements are included in the Succession Data Model so the functionality they reference can show up in
your instance.
HRIS Elements in the Succession Data Model [page 78]

HRIS Elements in the Succession Data Model determine which fields appear in the application as far as
data related to the employee is concerned.
Custom Filters in the Succession Data Model [page 81]

Custom filters can be added so as to use the standard elements as filters for search screens in the SAP
SuccessFactors HXM Suite, for example when mass creating forms.
HRIS Action (hris-action) in the Succession Data Model [page 83]

You include an HRIS action ID in your Succession Data Model so you can see the related action in the SAP
SuccessFactors HXM Suite.

50 CONFIDENTIAL Succession Data Model (SDM)
Element-Permission in the Succession Data Model [page 86]
Element permission is deprecated functionality that was used to give read or edit permissions to Employee
Profile elements.
Adding Dynamic Group Filters in the Succession Data Model [page 87]
Edit or add the dg-filters section if you want to set up dynamic group filters in the Succession Data
Model. This code enables the fields to be available for dynamic groups, for example, filter fields when
setting up permission groups for role-based permissions, or employee groups.
View Templates and Edit Templates in the Succession Data Model [page 90]
view-template and its attribute edit-template are used to define the fields that can display in certain
areas of the application.
Configuring HRIS Sync Mappings (hris-sync-mappings) in the Succession Data Model [page 93]
You can modify the Succession Data Model XML to include HRIS Sync mappings.
Configuring Read Audit in Succession Data Model [page 94]

You can configure log read access for HRIS elements including country/region-specific HRIS elements, and
for Employee Profile; User Info, Standard, and Background Elements using Succession Data Model.
4.1.1 Standard Elements in the Succession Data Model
Standard Elements (standard-element) in the Succession Data Model define the fields that are seen in the
Personal Information section of the People Profile in SAP SuccessFactors. The standard elements are single value
fields such as name, email, gender, department.
These fields are predefined in that the field-id is already set up. Their inclusion in the data model is optional. Even if
not defined in the Succession Data Model file, the fields are available to use in People Profile and Succession
modules based on permissions.
Defining the field in the xml however, allows you to modify its default behavior such as making it a picklist or
modifying its label.
Some of the standard elements are also where data can be imported/exported via the User Data File.
 Caution
If using Employee Central, do not make user data changes by importing User Data File either from the UI or
through a scheduled job. Doing so can overwrite data coming from Employee Central and cause data
inconsistencies.
Standard Element Definition [page 52]

XML elements and attributes for standard-element are defined in this topic.
Modifying Standard Elements [page 59]

You can modify your standard elements in the Succession Data Model to fit your business needs.
Parent topic: Components of Succession Data Model XML [page 50]

Succession Data Model (SDM) CONFIDENTIAL 51
Related Information

Standard Elements That Can’t Have a Picklist [page 58]
4.1.1.1 Standard Element Definition
XML elements and attributes for standard-element are defined in this topic.
List of Relevant Attributes of a Standard Element When Editing an Element

Element or Attribute Purpose Default value/Comments
id Predefined, id indicates the data to be Desired field id

captured, example username. Includes
15 custom fields (customxx) which can
be used to capture data not included in
the predefined fields
label Label of the field as seen on the UI. Can Standard labels that can be overwritten
have multiple rows for each language
supported
max-length Depends on the field type

Element or Attribute Purpose Default value/Comments
strings-list-id A specific picklist configured to allow leg Currently only used for jobCode.
acy field to have a picklist
 Sample Code
<standard-element
id="jobCode" strings-
list-
id="sysJobCodes"></
standard-element>
Here sysJobCodes is a system-gener

ated picklist that is automatically up
dated. You’re still able to manage the
picklist in the usual manner. You can also
use any other strings-list-id, but
that strings-list-id isn’t automat
ically automated. You need to manually
update such strings-list-id.
required If true, force the user to input information "false" by default if not configured.
for that field
matrix-filter If true, designates a field to be used in "false" by default if not configured. Only
the matrix grid certain fields accept this designation.
pii Personally Identifiable Information. It dis "false" by default if not configured

plays the field value as "********" for the
user.
pre-populate Impacts saved searches in Talent Search. "false" by default if not configured
Parent topic: Standard Elements in the Succession Data Model [page 51]
Related Information
Modifying Standard Elements [page 59]
4.1.1.1.1 Standard Element Field IDs in the Succession Data

Model
Standard elements that have preset functionality and use within the SAP SuccessFactors HXM Suite are listed
here.
Here are the field IDs available to you to use in your Succession Data Model as standard elements. These fields
have a one to one relationship between the field and the data.

Standard Element Field IDs
Field ID
username
email
gender
lastName
firstName
mi
nickname
suffix
salutation
department
division
location
jobCode
hireDate
timeZone
managerId
hrId
ssn
dateOfBirth
citizenship
nationality
ethnicity
married
minority
businessSegment
serviceDate
level
photo
function
performance
potential
objective

Field ID
competencyveteranDisabled
veteranSeparated
veteranProtected
veteranMedal
talentPool
empId
title
businessPhone
homePhone
cellPhone
fax
addressLine1
addressLine2
addressLine3
city
state
zipCode
country
reviewFreq
lastReviewDate
custom01
custom02
custom03
custom04
custom05
custom06
custom07
custom08
custom09
custom10
custom11
custom12
custom13
custom14

Field ID
custom15
riskOfLoss
impactOfLoss
benchStrength
reasonForLeaving
newToPosition
dateOfPosition
keyPosition
futureLeader
matrixManaged
salary
salaryLocal
localCurrencyCode
jobTitle
jobLevel
jobFamily
jobRole
finalJobFamily
finalJobRole
finalJobCode
payGrade
finPayGrade
dateOfCurrentPosition
bonusTarget
salaryProrating
raiseProrating
promotionAmount
lumpsumTarget
lumpsum2Target
compensationReadOnly
meritTarget
meritEffectiveDate
compensationEligible

Field ID
compensationSalaryEligible
compensationBonusEligible
compensationStockEligible
compensationSalaryRateType
compensationSalaryRateUnits
salaryBudgetTotalRaisePercentage
salaryBudgetMeritPercentage
salaryBudgetPromotionPercentage
salaryBudgetExtraPercentage
salaryBudgetExtra2Percentage
salaryBudgetLumpsumPercentage
salaryBudgetFinalSalaryPercentage
salaryBudgetTotalCompPercentage
stockBudgetStockAmount
stockBudgetUnitAmount
stockBudgetOptionAmount
stockBudgetOther1Amount
bonusBudgetAmount
matrixManager
proxy
customManager
secondManager
defaultLocale
status
vpIndividualView
personalCompensationStatement
userTags
time
retirementDate
seatingChart
personalVarPayStatement
personalCombinedStatement

Field ID
personalCombinedStatement
varPayBonusAssignmentStatement
facebook
linkedin
on-leave-status
empWorkflowRequests
matrix1Label
matrix2Label
companyExitDate
sysLearningHistory
sysCurricula
totalTeamSize
teamMembersSize
timeInCurrentPosition
timeAtCompany
previousPosition
previousEmployer
loginMethod
learningLicenseUserType
4.1.1.1.2 Standard Elements That Can’t Have a Picklist
Legacy fields that were part of the User Directory can’t have picklists IDs associated with them.
While importing the Succession Data Model, if a field not allowed to have a picklist, has been modified to have a
picklist, there’s no validation error. However, you see data issues in the application if such configuration exists.
Field ID
userid
username
nickname
email
gender
suffix
salutation

Field ID
division
department
location
jobCode
hireDate
managerId
hrId
defaultLocale
title
4.1.1.2 Modifying Standard Elements
You can modify your standard elements in the Succession Data Model to fit your business needs.
Prerequisites
You’ve downloaded the Succession Data Model and have the file open for editing in an XML editor.
 Remember
Context
Defining a standard element in the Succession Data Model is optional. If permissions have been granted to the
element, they’re available in the UI. However, if you wish to modify the default behavior of a standard element, you
define the element in the Succession Data Model.
 Caution
It’s possible for you to modify the label of a standard element and use the element for a different purpose.
However, doing so isn’t recommended. The length or type of the field may not suit its new purpose. Also, while
the use may seem to work now, it can have consequences downstream that may not be correctable. There are
15 custom standard elements available to you and the customxx field IDs can be used for a need not addressed
by the predefined standard elements.

Procedure
Overwrite the existing label in the element. If there are other language labels for your standard element,
modify or add them as needed.

● Add a picklist to the standard element.
<standard-element id="ethnicity" required="false" matrix-filter="false">

<label>Ethnicity</label>
<label xml:lang="en-US">Ethnicity</label>
<picklist id="Ethnicity"/>
</standard-element>
 Note
Switching a field to having a picklist or not causes data loss.
You create the picklist. The picklist is then added to the standard element as in the code sample.
● Set a field to be a matrix filter
Change the matrix-filter attribute.
Only certain fields accept this designation.
Task overview: Standard Elements in the Succession Data Model [page 51]
Related Information
Standard Element Definition [page 52]

4.1.2 User Info Elements in the Succession Data Model
User Info Elements (userinfo-element) are used to define custom fields as well as to define fields used to
integrate with SAP SuccessFactors Recruiting. Each userinfo-element can have more than one value.

Related Information

4.1.2.1 User Info Element Definition
XML elements and attributes for user-info-element are defined in this topic.
Attribute/Element Description Comments
Type The data type of the userinfo element. Type is required. Type can be:
● varchar: text or string
● float: number field with or without
decimals
● integer: number field with no
decimals
● date: a date field
 Note
You can set type to be blob or
boolean per DTD definition.
However, these types aren’t
supported.
id Unique ID for each element.
required Force the user to input information for "false" by default if not configured.
that field.
pii Personally Identifiable Information. It "false" by default if not configured.

displays the field value as "********" for
the user.
reportable Set reportable="true" for an "false" by default if not configured.

element to be available to employee
profile ad hoc reports as columns and
filters.

Attribute/Element Description Comments
label Label for the element. You can add labels for implemented
languages.
picklist Create a picklist in the system and add

the ID to the userinfo-element
needing a picklist.
4.1.2.2 Modifying User Info Elements
You can modify an existing userinfo-element or add a userinfo-element to your Succession Data Model
based on your business needs.
Prerequisites
 Remember
Procedure
● Add a new userinfo-element

Look for the last standard-element tag in your Succession Data Model file. Add your new userinfo-
element thereafter.
 Sample Code
<userinfo-element id="reloWilling" type="varchar" required="false" reportable="true">
<label>Willing to Relocate</label>
<picklist id="relo"/>
</userinfo-element>

● Add a picklist
You create the picklist. The picklist is then added to the userinfo element as in the code sample.
Here relo is the picklist ID.

 Note
The data-field and the picklist id aren’t required to be the same.
● Make a field reportable
Change the reportable attribute

● Change the element label
Overwrite the existing label in the element. If there are other language labels for your standard element,
modify or add them as needed.
Related Information

4.1.3 Background Elements in the Succession Data Model
Background Elements (background-element) in the Succession Data Model are elements where a one to many
relationships exists between the field and the data it can store.
There are two kinds of background elements - data field based and rating field based. Examples of background data
elements are Education and Work Experience. Rating fields can be from the Performance Management module or
be imported. The kind of rating depends on the field used and its configuration. The element ids prefixed with "sys"
are special types that have restrictions about what can be modified.
The elements defined as background elements can be displayed on People Profile in the background and trend
information blocks.
Related Information


4.1.3.1 Background Element Definition
XML elements and attributes for background-element are defined in this topic.
These are elements where a one to many relationship exists between the element and data. There are two kinds of
background elements - background data elements, and background rating elements.
background-element Definition
Attribute Description Notes
type-id A unique ID for each background ele This has to be an integer and is required.
ment. There’s no default value.
id A unique ID for each element. The global name for this section, is a
string field. Must be unique. It has no de
fault value. You see this ID being used in
the export and import of live profile back
ground and rating files. You can’t remove
or comment out data-fields or rating-
fields from a 'sys' background element.
You can set hidden to true for data fields
and set visibility to none for rating-fields
so the field doesn’t appear in the applica
tion.
 Note
You can't use the same ID for a Back
ground Element. While uploading the
data model upper and lowercase let
ters are considered as the same
string values.
For example: ABC, Abc, or aBc are

considered as the same string value.
max-entries Maximum number of the rows you’re al The maximum number of entries allowed
lowed from the UI via live profile self-service. This limit
doesn’t apply when importing data items.
scale-id Used for rating background elements. Only applicable for rating background el
ements. Allowed values are: Perform
ance, Potential, Objective, or Compe
tency.

feedback-type Used for rating background elements. Only applicable for rating sections.
The supported types are:
● 5: Overall Competency Rating -

Form's aggregate competency score
● 6: Overall Objective Rating - Form's
aggregate objective score
● 7: Overall Potential Rating -
● 8: Overall Performance Rating -
Form's overall score
These rating types can be calculated/

generated by a performance review form
except for Potential.
4.1.3.1.1 Background Element - Data Field Definition
XML elements and attributes for background-element are defined in this topic.
Example of a background data element in the Succession Data Model:
 Sample Code
<label>Language Skills</label>
<data-field id="language" field-name="vfld1" max-length="4000" max-file-size-KB="1000">
<label>Language</label>
</data-field>
<data-field id="variant" field-name="vfld5" max-length="4000" max-file-size-KB="1000">
<label>Language Variant</label>
<picklist id="variant" parent-field-id="language"/>
</data-field>
<data-field id="speakingProf" field-name="vfld2" max-length="4000" max-file-size-KB="1000">
<label>Speaking Proficiency</label>
<picklist id="fluency"/>
</data-field>
<data-field id="readingProf" field-name="vfld3" max-length="4000" max-file-size-KB="1000">
<label>Reading Proficiency</label>

</data-field>
<data-field id="writingProf" field-name="vfld4" max-length="4000" max-file-size-KB="1000">
<label>Writing Proficiency</label>
</data-field>
background-element > data-field Definition

id The unique identifier for each back A unique ID. There are some IDs which
ground data field.
are standard for SAP SuccessFactors
which are used to internally for other fea
tures and functionality. This is a required
field.
 Note
You cannot configure the same val
ues for the Data Field ID and
Background Element ID.
field-name Name for each background data field The field-name is the database field
name to use. This is a required field. Al
lowed names are based on type of field
needed and are unique for a background
data element. Refer to the table below for
names.
required Force the user to input information for Value is true or false. "false" by default if
that field not configured.
hidden Value is true or false. Same effect as visi

bility = "none". "false" by default if not
configured
url-link Value is true or false.
Mostly used with Google Docs feature.

"false" by default if not configured
max-length The maximum number of characters that

can be entered in the html form
display-size Not used currently

pii Personally Identifiable Information. It will This property is not supported currently.
display the field value as "********" for
Value is true or false.
the user.
Even if configured in the Succession Data
Model, it will not have any effect. The
value will not be masked as "*****".
"false" by default if not configured
document-type-id Attachment field attribute to identify the Each background element can have one
classification optional field of attachment type. This
field allows you to classify uploaded
documents for easy search. For example,
when you do a search on all the docu
ments of type "Classification", any docu
ment with type-id set to Classification will
be returned. The following types are sup
ported: RESUME, COVERLETTER,
HRIS_ATTACHMENT, PERFORM
ANCE_ASSESSMENTS,
360_MULTI_RATER_ASSESSMENTS ,
CERTIFICATIONS, PUBLICATIONS,
USER_DEFINED, ATTACHMENTS, APPLI
CATION_INTERVIEW_ATTACHMENTS
max-file-size-KB This is the maximum size of the file that

you can upload. The size has to be less
than the size specified by "Attachment
max file size" in provisioning.
file-formats Determines what file extension is al

lowed. For example, if only pdf file is al
lowed, then the value is pdf. The following
file formats are supported:
● Microsoft Office documents

● CSV
● HTML, HTM
● RTF
● TXT
● PDF
● Image file formats: GIF, PNG, JPG,
JPEG, TIF, BMP
● XML
 Note
If this field is not defined or is de
fined as empty, you can add attach
ments in all the supported formats
except XML and CSV, in People Pro
file or through Live Profile Import.

hris-field-mapping For details, see related information
readonly Column will be NOT editable if it is used Not supported currently. Configuring it in
the data model will have no effect. "false"
by default if not configured
text-area-enabled The input area will become a text area Value will be true | false.
which supports multiple lines
Used in UI v12. "false" by default if not
configured
Background Element Data Field Types and Length

field-name type max-length
name VARCHAR2 256
desc VARCHAR2 1024
vfld1-vfld20 VARCHAR2 4000
startDate date
endDate date
dfld1-dfld4 date
ifld1-ifld8 integer -2147483648 to 2147483647
ffld1-ffld8 float 1.40129846432481707e-45 to

3.40282346638528860e+38 positive or
negative
lastModified readonly
attachment1 limited by attachment size
4.1.3.1.2 Background Element - Rating Field Definition
XML elements and attributes for background-element used for rating-field are defined in this topic.
Example of a background rating element in the Succession Data Model:
 Sample Code
<background-element id="sysOverallPerformance" type-id="31" scale-

id="Performance" feedback-type="8">
<label>Performance **Manager view only</label>
<rating-field rating-name="start-date" visibility="none" required="true"
max-length="999" display-size="12" max-file-size-KB="1000">
<label>Start Date</label>
</rating-field>
<rating-field rating-name="end-date" visibility="none" required="true" max-
length="999" display-size="12" max-file-size-KB="1000">
<label>End Date</label>
</rating-field>
<rating-field rating-name="name" visibility="none" max-length="2000" display-
size="30" max-file-size-KB="1000">

<label>name</label>
</rating-field>
<rating-field rating-name="description" visibility="none" max-length="4000"
display-size="30" max-file-size-KB="1000">
<label>Description</label>
</rating-field>
<rating-field rating-name="rating" insert-rating="true" visibility="none"
required="true" max-length="999" display-size="8" max-file-size-KB="1000">
<label>Rating</label>
</rating-field>
<rating-field rating-name="label" visibility="edit" max-length="128" display-
<label>Rating Label</label>
</rating-field>
<rating-field rating-name="min" visibility="none" max-length="999" display-
<label>Minimum Scale Rating</label>
</rating-field>
<rating-field rating-name="max" visibility="none" max-length="999" display-
<label>Maximum Scale Rating</label>
</rating-field>
<rating-field rating-name="source" system-generated="true" visibility="view"
<label>source</label>
</rating-field>
<rating-field rating-name="module" system-generated="true" visibility="none"
<label>module</label>
</rating-field>
System rating elements are:
● sysOverallPerformance
● sysOverallPotential
● sysOverallObjective
● sysOverallCompetency
● sysOverallCustom1

background-element > rating-field Definition
rating-name The rating-name values are predefined Supported names are:
● start-date
● end-date - the two date fields are re
quired; the visibility must be either
"edit" or "both"
● name - not meaningful for perform
ance or potential. Used to store the
name of the competency and name
of the objective for the respective
ratings. If you wish to view all overall
competency scores from all forms
for a user in Live Profile, then you
can set this element to view and the
entire section to read only.
● description - Just as name, useful
for Competency and Objective rat
ings.
● rating - You have to include this field
in a rating background element. To
hide the numeric rating, set the visi
bility to "none". However, either the
rating or the label has to be modifia-
ble.
● label - You can use this field to im
port ratings from another system
● min - Used along with max to define
a range when importing ratings.
● max
● source - set system-generated to
true
● module - set system-generated to
true
● attachment1
insert-rating Only used for rating field. A rating Value is set to false by default.
scale is available for rating when this is
set to true.
system-generated If set to true, you can’t edit the field by Value is set to false by default.
self-service or by import. The system

generates an appropriate value. For ex
ample, if end-date is set to system gener
ated, the system inserts the start date
into the end date.

visibility Value determines what you can do with Visibility and permission rules:
the field.
If a user has "write" permission to the
field, then user can:
● see the field: if visibility = "view",

"edit" and "both".
● modify the field: if visibility = "edit"
or "both" (except if source is a
Form.)
If user has "read" permission to the field,

then user can:
● see the field: if visibility = "view" or

"both.
required Value is set to false by default.
max-length The maximum number of characters that

can be entered in the html form
display-size Not used currently
document-type-id Attachment field attribute to identify the Each background element can have one
classification optional field of attachment type. This
field allows you to classify uploaded
documents for easy search. For example,
when you search all the documents of
type "Classification", any document with
type-id set to Classification is returned.
The following types are supported: RE
SUME, COVERLETTER, HRIS_ATTACH
MENT, PERFORMANCE_ASSESSMENTS,
360_MULTI_RATER_ASSESSMENTS ,
CERTIFICATIONS, PUBLICATIONS,
USER_DEFINED, ATTACHMENTS, APPLI
CATION_INTERVIEW_ATTACHMENTS
max-file-size-KB Determines the maximum size of the file

that you can upload. The size has to be
less than the size specified by "Attach
ment max file size" in provisioning.

file-formats Determines what file extension is al

lowed. For example, if only a PDF file is al
lowed, then the value is pdf. The following
file formats are supported:
● Microsoft Office documents

● CSV
● HTML, HTM
● TXT
● RTF
● PDF
● Image file formats: GIF, PNG, JPG,
JPEG, TIF, BMP
● XML
 Note
If this field is not defined or is de
fined as empty, you can add attach
ments in all the supported formats
except XML and CSV in People Pro
file.
The MP4 file format is not supported

for the Rating Field.
4.1.3.1.3 Background Field IDs in the Succession Data Model
Some of the background elements that have preset functionality and use within the SAP SuccessFactors HXM
Suite are listed here.
These background elements are included in the Succession Data Model and are configured at the time of
implementation based on your needs.
Background Element ID
sysOverallPerformance
sysOverallPotential
sysOverallObjective
sysOverallCompetency
talentPool
sysScoreCardBadge
calibrationHistoryPortlet
sysScoreCardCompetenciesPortlet

Background Element ID
sysScoreCardObjRatingsPortlet
sysScoreCardOverviewPortlet
sysScoreCardPerfHistoryPortlet
sysScoreCardSuccessorPortlet
sysScoreCardPositionPortlet
matrix1placement
matrix2placement
sysScoreCardNominationPortlet
sysScoreCardDevelopmentObjectivesPortlet
sysLearningHistory
sysCurricula
sysScoreCardObjectivePortlet
sysScoreCardCustomExtensionPortlet
varPayEmpHistData
compensation
preferredNextMove
insideWorkExperience
outsideWorkExperience
education
experience
courses
certificates
promotability
specialAssign
4.1.3.2 Modifying Background Elements
You can modify your background elements in the Succession Data Model to fit your business needs.
Prerequisites

 Remember
Context
You can add a new background element or modify an existed pre-defined background element. Pre-defined
background elements have system-defined uses and functionality associated with them.
Procedure
● Insert a data field
You can insert a new data field in your background data element. The field-name is unique. Refer to element
and field definitions for specifics.
 Note
Don’t modify an existing data field-name. Doing so can cause data corruption.
Overwrite the existing label in the element. If there are other language labels for your background element,
data fields or the rating fields, you can modify or add them as needed.
 Remember
Some fields are required. Refer to element and fields definition for specifics.
● Add a picklist to the background data field.
<data-field id="relation" field-name="vfld2" required="true" max-length="4000"

max-file-size-KB="1000">
<label>Relation</label>
<picklist id="relation"/>
</data-field>
 Note
Switching a field to having a picklist or not causes data loss.
You create the picklist. The picklist is then added to the background data field as in the code sample.

Related Information

Background Element Definition [page 64]
Background Element - Data Field Definition [page 65]
Background Element - Rating Field Definition [page 68]
Background Field IDs in the Succession Data Model [page 72]
4.1.4 Tab Elements in the Succession Data Model
Tab Elements are included in the Succession Data Model so the functionality they reference can show up in your
instance.
Configuring a Tab Element in the Succession Data Model [page 76]

Tab elements are in the Succession Data Model so certain areas of the application are available on the front
end based on permissions.
List of Tab Elements in the Succession Data Model [page 77]

The tab-element needs to be defined in the Succession Data Model to navigate to the relevant
functionality.
Related Information


4.1.4.1 Configuring a Tab Element in the Succession Data
Model
Tab elements are in the Succession Data Model so certain areas of the application are available on the front end
based on permissions.
Prerequisites
 Remember
 Note
tab-element is added after the definition of the background fields is complete. So, if no tab-element is in
the data model, look for the last </background-element>, and add new tab-element right after.
 Remember
Procedure
Add a new tab-element as in the code sample.
 Sample Code
<tab-element id="pendingapprovals">
<label>Pending Requests</label>
</tab-element>
Label translations aren’t included in this sample code. The master data models include code for additional tab
elements as well as label translations.
Task overview: Tab Elements in the Succession Data Model [page 75]

Related Information

4.1.4.2 List of Tab Elements in the Succession Data Model
The tab-element needs to be defined in the Succession Data Model to navigate to the relevant functionality.
id is needed for the tab-element when defining the tab elements. These IDs are hardcoded in the system and are
listed here.
Tab Element ID Landing Page
pendingapprovals Pending Requests
employmentInfoTab Employment Information
personalInfoTab Personal Information
payrollIntegration Payroll Information
timeOffTab Time Off
timeOffAdminTab Manage Time Off
timeSheetTab Payroll Time Sheet
ectbenefitsfocus My Benefits
globalBenefits Employee Benefits
Parent topic: Tab Elements in the Succession Data Model [page 75]
Related Information
Configuring a Tab Element in the Succession Data Model [page 76]

4.1.5 HRIS Elements in the Succession Data Model
HRIS Elements in the Succession Data Model determine which fields appear in the application as far as data related
to the employee is concerned.
HRIS Elements in the Predelivered Succession Data Model
HRIS element ID Standard label Block Data object type
personInfo Biographical Information Biographical Information Person object
personalInfo Personal Information Personal Information Person object
globalInfo Global Information Part of Personal Information Person object

block (appears when the user
All fields for this HRIS element
adds a Country/Region in this
are defined in the Country/
block)
Region-specific Succession
Data Model.
nationalIdCard National ID Information National ID Information Person object
homeAddress Home Address Addresses Person object
All fields for this HRIS element

are defined in the Country/
Region-specific Succession
Data Model.
phoneInfo Phone Information Part of Contact Information Person object

block
emailInfo E-mail Information Part of Contact Information Person object

block
imInfo Social Accounts Information Part of Contact Information Person object

block
emergencyContactPrimary Primary Emergency Contact Primary Emergency Contact Person object
personRelationshipInfo Dependents Dependents Person object
paymentInfo Payment Information Payment Information Person object
 Note
You have to activate pay
roll integration to use this
feature.
employmentInfo Employment Details Employment Details Employment object
jobInfo Job Information Job Information Employment object

HRIS element ID Standard label Block Data object type
compInfo Compensation Information Compensation Information Employment object
payComponentRecurring Compensation Part of Compensation Employment object

Information block
payComponentNonRecurring Spot Bonus Spot Bonus Employment object
jobRelationsInfo Job Relationships Job Relationships Employment object
workPermitInfo Work Permit Info Work Permit Info Employment object
Note that when you’ve acti

vated the Global Assignments
feature, the
workPermitInfo block is
displayed on the Personal
Information page.
globalAssignmentInfo Global Assignment Details Global Assignment Details Employment object
 Note
You have to activate global
assignments manage
ment to use this feature.
pensionPayoutsInfo Pension Payout Details Pension Payout Details Employment object
 Note
You have to activate pen
sion payouts to use this
feature.
userAccountInfo Employee Information Employee Information block Employment object

on the Add New Employee
screen
Related Information


Creating Customer-Specific Foundation Objects
Mandatory HRIS Fields for HRIS Elements in the Succession Data Model [page 80]
Creating Customer-Specific Foundation Objects
Mandatory HRIS Fields for HRIS Elements in the Succession Data Model [page 80]
4.1.5.1 Mandatory HRIS Fields for HRIS Elements in the

Succession Data Model
Here is a list of required HRIS fields for the HRIS elements in the Succession Data Model.
For this HRIS element in the Succession Data Model... ...this HRIS field is always required:
compInfo currency-code
emailInfo email-address
email-type
employmentInfo end-date
start-date
globalAssignmentInfo company
end-date
assignment-type
planned-end-date
imInfo im-id

For this HRIS element in the Succession Data Model... ...this HRIS field is always required:
jobInfo job-code
company
business-unit
jobRelationsInfo relationship-type
rel-user-id
nationalIdCard card-type
national-id
isPrimary
country
payComponentNonRecurring pay-component-code
value
pay-date
payComponentRecurring pay-component
frequency
paycompvalue
pensionPayoutsInfo company
end-date
personalInfo first-name
last-name
personRelationshipInfo relationship-type
phoneInfo phone-type
phone-number
workPermitInfo issue-date
4.1.6 Custom Filters in the Succession Data Model
Custom filters can be added so as to use the standard elements as filters for search screens in the SAP
SuccessFactors HXM Suite, for example when mass creating forms.
By default the search screens in SAP SuccessFactors HXM Suite have some fields available as filters. These fields
are Department, Division, Location, and Username. Standard fields with fields Ids custom01 to custom15 can be
set up as custom filters.

Adding Custom Filters in the Succession Data Model [page 82]
custom-filter configuration enables you to define filter criteria for certain parts of the SAP
SuccessFactors HXM Suite such as when mass creating Performance or Compensation forms.
Related Information

4.1.6.1 Adding Custom Filters in the Succession Data Model
custom-filter configuration enables you to define filter criteria for certain parts of the SAP SuccessFactors
HXM Suite such as when mass creating Performance or Compensation forms.
Prerequisites
 Remember

Context
 Tip
● Only field ids customxx can be set up as custom filters.

● Standard fields division, department, and location are already available as filter fields.
● Calibration and Compensation can have module-specific filters, but for all others use filter-module
id="default"
Procedure
1. Find the custom-filter in your Succession Data Model xml.
If the custom-filter code doesn’t exist, find the last hris-action or the first dg-filter
2. Use the code example here to update custom filters for your instance
 Sample Code
<custom-filters>
<filter-module id="default">
<standard-element-ref refid="custom01"/>
</filter-module>
<filter-module id="calibration">
</filter-module>
</custom-filters>
filter-module id options are default, compensation, and calibration
Task overview: Custom Filters in the Succession Data Model [page 81]
Related Information
4.1.7 HRIS Action (hris-action) in the Succession Data Model
You include an HRIS action ID in your Succession Data Model so you can see the related action in the SAP
Modifying HRIS Action [page 84]

Add or review HRIS actions in your Succession Data Model.
Supported HRIS Actions in the Succession Data Model [page 85]

HRIS action IDs that are supported for inclusion in the Succession Data Model are listed here.
Related Information

4.1.7.1 Modifying HRIS Action
Add or review HRIS actions in your Succession Data Model.
Prerequisites
 Remember
Context
The hris-action IDs are pre-defined in the system and have functionality tied to them.

Procedure
1. Find the HRIS action section in your Succession Data Model.
This section comes right after the last hris element end tag (</hris-element>) in your Succession Data Model
2. Add the hris-action ID as in the code sample.
 Sample Code
<hris-action id="hireAction">
</hris-action>
Task overview: HRIS Action (hris-action) in the Succession Data Model [page 83]
Related Information
Supported HRIS Actions in the Succession Data Model [page 85]

4.1.7.2 Supported HRIS Actions in the Succession Data

Model
HRIS action IDs that are supported for inclusion in the Succession Data Model are listed here.
HRIS Action ID
addCitizenshipInfoAction
addDirectDepositAction
addEmailInfoAction
addIMInfoAction
addNationalIdCardAction
addPayCompNonRecurringAction
addPayCompRecurringAction
addPhoneInfoAction
addVisaInfoAction
addWorkPermitInfoAction
changeBusinessAddressAction
changeHomeAddressAction

HRIS Action ID
changeJobAction
changePersonalInfoAction
hireAction
hrisTransferAction
planLeaveOfAbsenceAction
reHireAction
returnLeaveOfAbsenceAction
terminateAction
transferAction
updateWorkEligibilityAction
Parent topic: HRIS Action (hris-action) in the Succession Data Model [page 83]
Related Information
Modifying HRIS Action [page 84]
4.1.8 Element-Permission in the Succession Data Model
Element permission is deprecated functionality that was used to give read or edit permissions to Employee Profile
elements.
Context
This code still exists in the Succession Data Model but is mostly due to backward compatibility. You permission the
various elements on the data model using role-based permissions.
Task overview: Components of Succession Data Model XML [page 50]
Related Information


4.1.9 Adding Dynamic Group Filters in the Succession Data

Model
Edit or add the dg-filters section if you want to set up dynamic group filters in the Succession Data Model. This
code enables the fields to be available for dynamic groups, for example, filter fields when setting up permission
groups for role-based permissions, or employee groups.
Prerequisites
 Remember
Context
When you create groups, you select the group members according to specific selection criteria. You can configure
which selection criteria show up on the screen where you define permission groups.
Procedure
Add dg-filter as in the code example right after all of the element-permission blocks.
 Sample Code
<dg-filters>
<my-filter>

</my-filter>
<permission-group-filter>
<hris-element-ref refid="compInfo">
<hris-field-ref refid="pay-group"/>
</hris-element-ref>
<hris-element-ref refid="jobInfo">
<hris-field-ref refid="job-code"/>
<hris-field-ref refid="employee-class"/>
<hris-field-ref refid="department"/>
<hris-field-ref refid="company"/>
<hris-field-ref refid="department" ref-field="name"/>
<hris-field-ref refid="location" ref-field="locationGroup"/>
<hris-field-ref refid="company" ref-field="countryOfRegistration"/>
</hris-element-ref>
<hris-element-ref refid="employmentInfo">
<hris-field-ref refid="isContingentWorker"/>
</hris-element-ref>
</permission-group-filter>
</dg-filters>
 Note
Ensure to always specify at least one HRIS Field reference for a HRIS Element in the Dynamic Group Filters
section before uploading the Succession Data Model. An invalid configuration will prevent Dynamic Group Filter
configuration sync.
Here:
○ Filters for default groups, for example the filters for Manage Employee Groups and Settings Groups , are
within the my-filter tags.
○ Standard element custom01 is set up as a filter criterion when creating dynamic permission groups.
○ HRIS elements and their fields are set up as filter criteria when creating dynamic permission groups
 Note
If there’s no configuration in place, in the Succession Data Model, there are standard fields that show up by
default.
 Tip
Always ensure that the HRIS fields included in your dynamic group filters are enabled in their respective HRIS
elements. If you disable a field in an HRIS element, check if it's also a part of a dynamic group filter. If so, then
remove it from the filter configuration as well. This way, you can avoid validations arising out of disabled fields
present in dynamic group filters when you import changes to your Succession Data Model.
Related Information


4.1.9.1 Standard Fields Available to Use as Filters in

Permission Groups
The fields that can be used when defining permission groups are the standard fields listed below, as well as any of
the HRIS fields when Employee Central is enabled.
Standard Fields allowed as filters in Permission Groups
benchStrength custom12 keyPosition
citizenship custom13 location
city custom14 married
country custom15 minority
custom01 dateOfBirth nationality
custom02 dateOfPosition newToPosition
custom03 department reasonForLeaving
custom04 division riskOfLoss
custom05 ethnicity state
custom06 External Source Channel (Only available Team View

if Learning is enabled.)
custom07 timeZone
futureLeader
custom08 title
gender
custom09 username
hireDate
custom10 zipCode
impactOfLoss
custom11 jobLevel
jobCode

4.1.10 View Templates and Edit Templates in the Succession
Data Model
view-template and its attribute edit-template are used to define the fields that can display in certain areas of
the application.
There are predefined view-template ids that exist in your Succession Data Model. These can be edited to refer to
the standard and background elements in your data model. Here's an example where this view-template is defining
the fields avialable for Talent Search.
<view-template id="talentSearch" visibility="none" pdf-printing-enabled="true">

<label>Talent Search</label>
<description>Talent Search Fields</description>
<edit-template id="personalInformation">
<description>Personal Information</description>
<standard-element-ref refid="title"/>
<standard-element-ref refid="jobCode"/>
<standard-element-ref refid="division"/>
<standard-element-ref refid="department"/>
<standard-element-ref refid="location"/>
<standard-element-ref refid="minority"/>
<standard-element-ref refid="hireDate"/>
</edit-template>
<edit-template id="insideWorkExperience">
<label>Work Experience Within Company</label>
<description>Work Experience Within Allied Building Products Corp.</
description>
<background-element-ref refid="insideWorkExperience"/>
</edit-template>
</view-template>
Related Information


4.1.10.1 Standard View Templates and Edit Templates in the
Here is a list of standard view templates and some of the edit templates that are defined in the Succession Data
Model.
View Template id Edit template Description
employeeProfile personalInformation
orgChartFields
promotability
sysOverallPotential
sysOverallObjective
sysOverallCompetency
specialAssign
education
courses
certificates
awards
languages
funcExperience
leadExperience
careergoals
mobility
memberships
community
compensation
talentSearch personalInformation
orgChartFields
jobInfo
specialAssign
education

View Template id Edit template Description
courses
certificates
awards
languages
funcExperience
leadExperience
careergoals
mobility
memberships
community
promotability
sysOverallPotential
employeeScoreCard scorecardEditTemplate
sysUserDirectorySetting sysAllUserDirectorySetting In order to see your standard and user

info elements on the Configure People
Profile page, you add the element Id in
the
sysAllUserDirectorySetting as
in the example:
 Sample Code
<standard-element-ref
refid="username"/>
sysVisibleUserDirectorySetting
photoCardFields
mobileCardFields
positionOrgChart editPosition
sysMappingDataTypes sysMappingDataTypesEditTemplate Include references to standard elements

you want to use beyond job code for
mapping competencies to a role in Per
formance Management

4.1.11 Configuring HRIS Sync Mappings (hris-sync-mappings) in the
You can modify the Succession Data Model XML to include HRIS Sync mappings.
Prerequisites
 Remember
Context
Using HRIS Sync mapping, you map Employee Central fields to the user data fields you wish to push data to.
Procedure
1. Find the last <view-template> tag section in your Succession Data Model.
The <hris-sync-mappings> elements begin right after the last view template end tag (</view-template>) in
your Succession Data Model.
2. Add the <hris-sync-mappings> as in the code examples.
 Sample Code
...
</edit-template>
</view-template>
<hris-sync-mappings>
<hris-element-ref refid="phoneInfo">
<hris-mapping entity-type="H" >
<hris-field-ref refid="custom-long2"/>
</hris-mapping>
</hris-element-ref>
<hris-element-ref refid="jobInfo">
<hris-mapping >
<hris-field-ref refid="company"/>
<user-info-record-key>user-company</user-info-record-key>
</hris-mapping>
<hris-mapping >
<hris-field-ref refid="employee-class"/>
<userinfo-element-ref refid="employeeClass"/>
</hris-mapping>

<hris-mapping >
<hris-field-ref refid="timezone"/>
<standard-element-ref refid="timeZone"/>
</hris-mapping>
</hris-element-ref>
...
<hris-sync-mappings>
Related Information

4.1.12 Configuring Read Audit in Succession Data Model
You can configure log read access for HRIS elements including country/region-specific HRIS elements, and for
Employee Profile; User Info, Standard, and Background Elements using Succession Data Model.
Prerequisites
You have access to Provisioning for your company instance.
 Remember

Context
By default, HRIS fields for HRIS elements aren’t configured as read audit fields. You can choose fields for HRIS
elements that you want to include in log read access.
For Employee Profile, you can configure log read access for the following fields:
● User Info
● Standard
● Background Elements (Data and Rating Fields)
Procedure
1. Log in to provisioning
2. Click on your instance in provisioning
3. Scroll down to the Succession Management section.
Succession Data Model (SDM) Import/Export Data Model
Country/Region Specific SDM Import/Export Country/Region Specific XML for Succession

Data Model
 Caution
We recommend that when uploading the country/region-specific data models, you remove any countries/
regions and fields that you don’t need before uploading the XML for the first time. If you upload the
complete data model, the upload takes longer due to the number of countries/regions in the XML file.
5. Export or Import the XML file.

○ To export the XML file, use the radio button by Export, and Choose Submit
○ Open the downloaded file in an XML editor and search for the field that requires to be configured.
○ To enable log read access for a field set attribute logreadaccess to true.
○ Save the exported file as a new file so you have a backup.
○ To import, use the radio button by Import. Use Browse to find the file on your local machine and then
choose Submit.
Related Information

Configuring Read Audit in Business Configuration UI
4.2 Succession Data Model and User Data
User data imports and syncing of data across modules is impacted by how the Succession Data Model is set up.
Succession Data Model and User Data File (UDF) [page 96]
User Data File columns are dependent on the fields defined in the Succession Data Model.
Configuring the Talent Card Extended Information Section [page 97]

The extended information section contains additional user information, such as the length of time an
employee has been in the company, their role or job code, or their manager.
Related Information
4.2.1 Succession Data Model and User Data File (UDF)
User Data File columns are dependent on the fields defined in the Succession Data Model.
User Data File is a comma separated (csv) file that stores employee-related data defined using standard elements
in the Succession Data Model.
 Caution
If using Employee Central, do not make user data changes by importing User Data File either from the UI or
through a scheduled job. Doing so can overwrite data coming from Employee Central and cause data
inconsistencies.
You can import this employee data using the User Data File. You can also export a template for the file or the file
with employee data in it from Admin Center. The format of the file and columns that are on it are determined by
how the fields are defined in the Succession Data Model.

You define the fields that are visible in the edit-template sysVisibleUserDirectorySetting. You can also
change the order of the columns in the User Data File by changing the order in which the files appear here.
 Sample Code
<edit-template id="sysVisibleUserDirectorySetting">
<label>User Directory Setting(Visible)</label>
<standard-element-ref refid="username"/>
<standard-element-ref refid="firstName"/>
<standard-element-ref refid="nickname"/>
<standard-element-ref refid="mi"/>
<standard-element-ref refid="lastName"/>
<standard-element-ref refid="suffix"/>
<standard-element-ref refid="title"/>
<standard-element-ref refid="gender"/>
</edit-template>
If a field is set to required="true" but the value is left blank during import, you receive an error.
<standard-element id="email" required="true" matrix-filter="false">

<label>Email </label>
<standard-element>
Parent topic: Succession Data Model and User Data [page 96]
Related Information
Configuring the Talent Card Extended Information Section [page 97]
4.2.2 Configuring the Talent Card Extended Information

Section
The extended information section contains additional user information, such as the length of time an employee has
been in the company, their role or job code, or their manager.
Procedure
1. The extended information section is collapsed by default on the talent card. Click to expand and then edit the
section.
2. Select the fields you want to display on the talent card.
By default, the extended information section displays the employee's Job Level, Function, and Country/Region.
To override those fields, select from the lists any other user information field defined for your company.

 Note
The available fields are drawn from the standard elements and userinfo elements defined in People Profile.
3. Select Show Label to display the field name label for a field.
Task overview: Succession Data Model and User Data [page 96]
Related Information
Succession Data Model and User Data File (UDF) [page 96]
4.3 Dependencies of Succession Data Model Across Modules
Succession Data Model is a core data model for employee data that takes input from most other modules.
The advantage of a system like SAP SuccessFactors is easy data flow and ease of data management. However, for
this interphase to work smoothly, right elements have to be in place. These elements can be data elements in the
data model, fields, and their configuration in the target modules, other features, or permissions.
For additional details regarding the configuration of the features in this section, refer to the respective module
documentation.
Succession and Development and the Succession Data Model [page 99]
Succession Management depends on the Succession Data Model to define, display, and permission fields
available for use based on your needs. Similarly, there’s functionality in Career Development Planning that
can fail if certain fields aren’t set up as needed in the Succession Data Model.
Compensation and Succession Data Model [page 116]

Compensation pushes data to the Employee profle based on the field definitions in the Succession Data
Model.
People Profile and the Succession Data Model [page 126]

Understand the connection between People Profile, the Succession Data Model and SAP SuccessFactors
Succession Planning.
Recruiting and Succession Data Model [page 127]

You can set up your SAP SuccessFactors system in a way such that data from Recruiting Management can
be synced across other SAP SuccessFactors modules.
Talent Management and the Succession Data Model [page 141]

Talent Management uses employee related data that is defined in the Succession Data Model. It can also be
the source for trend and background data that needs to be defined in the Succession Data Model.
Employee Central and the Succession Data Model [page 147]

Employee Central is a vast module that is heavily dependent for its behavior on the data models.
Learning and Succession Data Model [page 154]

Integration points of Learning with the Succession Data Model are listed in this topic.
Onboarding and the Succession Data Model [page 155]

Onboarding depends on the Succession Data Model when needing to pull or push data to other modules,
especially Employee Central.
Data Models and Other Integrations [page 162]

Besides other modules, there are integration points that are configured in the data models for some of
these integrated functionalities and features to work as desired.
4.3.1 Succession and Development and the Succession Data

Model
Succession Management depends on the Succession Data Model to define, display, and permission fields available
for use based on your needs. Similarly, there’s functionality in Career Development Planning that can fail if certain
fields aren’t set up as needed in the Succession Data Model.
Parent topic: Dependencies of Succession Data Model Across Modules [page 98]
Related Information

4.3.1.1 Succession Data Model to Succession Org Chart

Mapping Values of Standard Elements
Here is a table of supported standard elements and their mapping values.
Succession Data Model ID SOC XML Key Mapping Values
addressLine1 addr1 No enumeration – textOption only
addressLine2 addr2 No enumeration – textOption only
benchStrength benchStrength Can be a picklist

businessPhone biz_phone No enumeration – textOption only
businessSegment businessSegment Can be a picklist
citizenship citizenship Can be a picklist
city city No enumeration – textOption only
competency competency {(.ﬁwSh·.0DÜawÞ—»¶¹�ü˛Þ"°pi—Ì!H,ÇAíÄžÍ·Gäa7Ýk5\eÓ.A§(;¨šMMt_XLêStŸ)u’Ô

ing the normalized matrix competency
scale
country country No enumeration – textOption only
custom01-15 custom01, custom02, etc. No enumeration – textOption only
sysOverallCustom1 customrating1 Latest sysOverallCustom1 rating, using

the normalized matrix custom1 scale
sysOverallCustom2 customrating2 Latest sysOverallCustom2 rating, using

the normalized matrix custom2 scale
dateOfBirth dateOfBirth No enumeration – textOption only (date

format)
dateOfPosition dateOfPosition No enumeration – textOption only (date

format)
department department Enumerated. Automatically retrieved

from the company’s department list
division division Enumerated. Automatically retrieved

from the company’s division list
email email No enumeration – textOption only
empId empId No enumeration – textOption only
ethnicity ethnicity Can be a picklist
fax fax No enumeration – textOption only
firstName firstName No enumeration – textOption only
function function Can be a picklist
futureLeader futureLeader true, false
gender gender M, F
hireDate hireDate No enumeration – textOption only (date

format)
impactOfLoss impactOfLoss Can be a picklist
jobCode jobCode No enumeration – textOption only
keyPosition keyPosition true, false
lastName lastName No enumeration – textOption only
lastReviewDate last_review_date No enumeration – textOption only (date

format)
level level Can be a picklist

location location Enumerated. Automatically retrieved

from the company’s location list
managerId managerId No enumeration – textOption only
married married true, false
matrix1label matrix1label Latest performance/potential matrix grid

placement. No enumeration - tex tOption
matrix2label matrix2label €ûmAK»−ß\a{VÞ´Ý�(÷vˆ⁄"Ý5aHıe§UE’ë·ł¤8™Ô®}Ýy(Û™Dch«‰„–AÅ+ËÍ}ÕÙ(»Ô˘�@

ment. No enumeration
matrixManaged matrixManaged true, false
mi mi No enumeration – textOption only
minority minority true, false
nationality nationality Can be a picklist
newToPosition newToPosition true, false
objective objective Latest sysOverallObjective rating, using

the normalized matrix objective scale
performance performance Latest sysOverallPerformance rating, us

ing the normalized matrix perform ance
scale
potential potential Latest sysOverallPotential rating, using

the normalized matrix potential scale
reasonForLeaving reasonForLeaving Can be a picklist
reviewFreq review_freq No enumeration – textOption only
riskOfLoss riskOfLoss Can be a picklist
serviceDate serviceDate No enumeration – textOption only (date

format)
ssn ssn No enumeration – textOption only
state state No enumeration – textOption only
talentPool talentPool Can be a picklist
title title No enumeration – textOption only
userId userId No enumeration – textOption only
username username No enumeration – textOption only
zipCode zip No enumeration – textOption only

4.3.1.2 Links to Preferred Next Move in Live Profile
In the Career Worksheet you can include a checkbox on each future role, which will allow users to specify the role as
a Career Interest in their Employee Profile.
 Remember
The instance must have preferredNextMove specified in the background-element tag defined in the live
profile data model, and also include title in the data-field tag defined within that background-element.
Additional data-field tags may also be present.
For example:
<background-element id="preferredNextMove" type-id="16">

<label>Preferred Next Move</label>
<data-field id="title" field-name="vfld1" required="true" max-length="4000">
<label>Title</label>
</data-field>
<data-field id="relocPref" field-name="vfld2" max-length="4000">
<label>Relocation Preferences</label>
</data-field>
The Career Worksheet template must also have the share permission enabled for one or more relative roles. For
example, with this configuration, only the employee could share their own role plans. Employees can choose to
select Make public in Live Profile in the Career Worksheet.
<permission for="share">
<description><![CDATA[Only the employee may copy roles to their live profile
page. ] ]></description>
<role-name><![CDATA[E ] ]></role-name>
</permission>
And with this configuration, no one would see the function:
<permission for="share">
<description><![CDATA[ ] ]></description>
</permission>
Note that this function only copies the role name from the Career Worksheet to the Live Profile data model. An
advantage of this approach is that if the user enters a value directly into Live Profile that is an exact match with a
role name, and that role is in the user's career worksheet, the system will detect the match and check the
checkbox.
 Caution
Do not set any fields in the background-element to required="true", except for "title". Otherwise, the
career worksheet will not be able to add records to the background-element, since it is only populating the
"title" field.

4.3.1.3 Matrix Grid Reports and Succession Data Model
Learn how the matrix reports are impacted by configuration options in the Succession Data Model
There are other elements to get the matrix reports to work as desired. Look into the Succession: Implementation
and Administration guide for information on those elements.
Rating Field Configuration in the Succession Data Model [page 103]

Learn about the things you should consider when configuring rating trend elements in the Succession Data
Model for use with matrix grid reports.
Configuring the Data Model to Store Matrix Grid Placement History [page 105]
You can store the matrix grid placement history using the Succession Data Model.
Enabling Fields as Matrix Filters [page 107]

By default, the Matrix Grid Reports have the fields Department, Division, and Location available as filter
options. You can also add other fields as custom filters to allow for more granular filter options in the report.
You can enable fields to be used as filter fields for the Matrix Grid Reports via the XML.
Supported and Unsupported Fields for Matrix Filters [page 108]

There are three kinds of filters that are supported in matrix grid reports: default filters, custom filters, and
other standard fields.
Showing Matrix Rating Label in People Profile [page 111]

You can show the cell label for an employee's latest matrix grid report placement in People Profile.
4.3.1.3.1 Rating Field Configuration in the Succession Data

Model
Learn about the things you should consider when configuring rating trend elements in the Succession Data Model
for use with matrix grid reports.
 Remember
Four standard rating trend background-element fields are available for use on matrix grid reports:
● <sysOverallPerformance>
● <sysOverallPotential>
● <sysOverallCompetency>
● <sysOverallObjective>
You can also use the following two custom rating trend elements:
● <sysOverallCustom1>
● <sysOverallCustom2>
The custom fields are similar in behavior to the four standard trend elements, but they can only be used for:
● Importing ratings into People Profile with the trend data import

● Entering ratings directly into People Profile
● Displaying ratings on the matrix grid reports.
The custom fields can also be mixed and matched with the other rating elements.
 Note
If you use the objective competency section in your Performance Management form, you must also use
<sysOverallCompetency> and <sysOverallObjective> on the how vs. what matrix grid report. If you
utilize these section types today, you'll need to consider whether you want to trade one functionality for the
other. If you do not use these section types, this may not be a concern now, but you will not be able to
utilize this functionality in the future as long as your matrix grid reports are configured this way.
The custom fields, <sysOverallCustom1> and <sysOverallCustom2> cannot be used for other functions such
as:
● Display in the scorecard overview or rating history blocks
 Note
They will display in the mini-matrix in the overview block, just not the overall score.
● Capturing or calculating overall ratings on forms
 Note
The objective competency summary and performance-potential summary sections of the Performance
Management (PM) forms only support the ratings their names imply. So if you configure the how vs. what
matrix grid report to use, for example, <sysOverallCompetency> vs. <sysOverallCustom1>, then it
cannot be used for the objective competency summary section in a PM form.
Rating Elements in the Data Model XML
 Example
<background-element id="sysOverallPerformance" type-id="8" scale-id="Performance"

feedback-type="8">
Attributes for Required Items

id Name of the background section:
type-id Unique integer for identifier

scale-id Which matrix grid rating scale to use:
● Potential
● Performance
● Objective
● Competency
● Custom1
● Custom2
feedback-type Unique integer specifying the source of feedback for the sec
tion:
● 8 = Performance
● 7 = Potential
● 6 = Objective
● 5 = Competency
● 27 = Custom1
● 28 = Custom2
Parent topic: Matrix Grid Reports and Succession Data Model [page 103]
Related Information
4.3.1.3.2 Configuring the Data Model to Store Matrix Grid

Placement History
You can store the matrix grid placement history using the Succession Data Model.
Prerequisites
The Matrix Grid Report (9-Box) and Matrix Grid How Vs. What Report (9-Box) settings are enabled in Provisioning.
Context
The placement history is stored in the data model and can be viewed by adding a block to the People Profile.

 Remember
Procedure
1. Add two background elements to the Succession Data Model for the two matrix grid reports.
○ <matrix1placement>: for Performance vs. Potential
○ <matrix2placement>: for How vs. What
 Sample Code
<background-element id="matrix1placement" type-id= "133">

<label>Historical Matrix Grid Placement Block</label>
<background-element id="matrix2placement" type-id= "134">
<label>How vs. What Historical Matrix Grid Placement Block</label>
2. Make sure that appropriate role-based permissions are in place for the two background elements.
Results
Now, the data model is ready to store the matrix grid placement when a rating change occurs in a relevant
Performance Management form.
Next Steps
In order to view the history, you need to set up a block in People Profile. You can also generate an initial past history
of matrix grid placement by scheduling the job Regenerate Matrix Placement History.
 Caution
Changing a rating scale that impacts matrix grid placement results in regeneration of the entire matrix grid
placement history to match the new rating scale.
 Note
After you import trend data, either in Admin Center or in Provisioning, a Regenerate Matrix Placement History
job will be triggered.
Enabling Matrix Grid Reports

Task overview: Matrix Grid Reports and Succession Data Model [page 103]
Related Information

Enabling Matrix Grid Reports
4.3.1.3.3 Enabling Fields as Matrix Filters
By default, the Matrix Grid Reports have the fields Department, Division, and Location available as filter options. You
can also add other fields as custom filters to allow for more granular filter options in the report. You can enable
fields to be used as filter fields for the Matrix Grid Reports via the XML.
Context
 Remember
 Recommendation
Fill in matrix filter fields in user data imports. Blank or null values may result in invalid filter results in the matrix
grid reports.
 Tip
If you use text replacement in your system, avoid labels that include a forward slash, “/”, including localizations,
because the export function for Matrix Grid reports cannot process that special character. Any export
attempted where a forward slash is included in a label, for example “Mitarbeiter/in”, will fail. To correct the
issue, simply remove the forward slash from your text replacement labels.
Procedure
1. In Provisioning, go to Import/Export Data Model and export the data model.

2. In the XML, set matrix-filter to true for the standard-element definition of relevant fields:

 Example
<standard-element id="city" max-length="128" required="true" matrix-

filter="true">
3. Register the element in <view-template id="sysUserDirectorySetting"> / <edit-template

id="sysAllUserDirectorySetting">.
 Example
<view-template id="sysUserDirectorySetting" pdf-printing-enabled="true">

<label>User Directory Setting</label>
<edit-template id="sysAllUserDirectorySetting">
<label>User Directory Setting(Entire Ordered List)</label>
<standard-element-ref refid="city"/>
</edit-template></view-template>
4. Import the data model XML.
Related Information

4.3.1.3.4 Supported and Unsupported Fields for Matrix Filters
There are three kinds of filters that are supported in matrix grid reports: default filters, custom filters, and other
standard fields.
Supported Fields
● There are three default filters in Succession matrix grid reports: department, division, and location. These
three filters display all the time.
● Custom fields, from custom01 to custom15 are supported. Customizable fields can be associated to a picklist.
If a picklist is used as a matrix filter, the picklist labels will be displayed in customizable fields. Also,
customizable fields remember the picklist labels that you chose last time. These custom fields are put under
<view-template id="sysUserDirectorySetting" ... > / <edit-template
id="sysAllUserDirectorySetting"...> in the Succession Data Model with <matrix-filter> set to
"true".

● Many standard fields are also supported. For example, city, title, and state. Note that below supported standard
field list is not exclusively for Succession. For example, there are also elements for Compensation. These
standard fields are put under <view-template id="sysUserDirectorySetting" ... > / <edit-
template id="sysAllUserDirectorySetting"...> in the Succession Data Model with <matrix-
filter> set to "true".
 Sample Code
<standard-element id="empId" max-length="255" required="false" matrix-

filter="true">
<standard-element id="title" max-length="255" required="false" matrix-
filter="true">
<standard-element id="businessPhone" max-length="20" required="false" matrix-
filter="true">
<standard-element id="homePhone" required="false" matrix-filter="true">
<standard-element id="cellPhone" required="false" matrix-filter="true">
<standard-element id="fax" max-length="20" required="false" matrix-
filter="true">
<standard-element id="addressLine1" max-length="255" required="false" matrix-
filter="true">
<standard-element id="addressLine2" max-length="255" required="false" matrix-
filter="true">
<standard-element id="addressLine3" required="false" matrix-filter="true">
<standard-element id="city" max-length="255" required="false" matrix-
filter="true">
<standard-element id="state" max-length="20" required="false" matrix-
filter="true">
<standard-element id="zipCode" max-length="10" required="false" matrix-
filter="true">
<standard-element id="country" max-length="255" required="false" matrix-
filter="true">
<standard-element id="reviewFreq" max-length="200000000" required="false"
matrix-filter="true">
<standard-element id="lastReviewDate" required="false" matrix-filter="true">
<standard-element id="salary" required="false" matrix-filter="true">
<standard-element id="salaryLocal" required="false" matrix-filter="true">
<standard-element id="localCurrencyCode" required="false" matrix-
filter="true">
<standard-element id="jobTitle" required="false" matrix-filter="true">
<standard-element id="jobLevel" required="false" matrix-filter="true">
<standard-element id="jobFamily" required="false" matrix-filter="true">
<standard-element id="jobRole" required="false" matrix-filter="true">
<standard-element id="payGrade" required="false" matrix-filter="true">
<standard-element id="finalJobFamily" required="false" matrix-filter="true">
<standard-element id="finalJobRole" required="false" matrix-filter="true">
<standard-element id="finalJobCode" required="false" matrix-filter="true">
<standard-element id="dateOfCurrentPosition" required="false" matrix-
filter="true">
<standard-element id="bonusTarget" required="false" matrix-filter="true">
<standard-element id="multiBonusExtra" required="false" matrix-filter="true">
<standard-element id="extraAmount" required="false" matrix-filter="true">
<standard-element id="salaryProrating" required="false" matrix-filter="true">
<standard-element id="raiseProrating" required="false" matrix-filter="true">
<standard-element id="promotionAmount" required="false" matrix-filter="true">
<standard-element id="lumpsumTarget" required="false" matrix-filter="true">
<standard-element id="lumpsum2Target" required="false" matrix-filter="true">
<standard-element id="compensationReadOnly" required="false" matrix-
filter="true">
<standard-element id="meritTarget" required="false" matrix-filter="true">
<standard-element id="meritEffectiveDate" required="false" matrix-
filter="true">
<standard-element id="promotionEffectiveDate" required="false" matrix-
filter="true">
<standard-element id="extraEffectiveDate" required="false" matrix-
filter="true">

<standard-element id="extra2EffectiveDate" required="false" matrix-
filter="true">
<standard-element id="lumpsumEffectiveDate" required="false" matrix-
filter="true">
<standard-element id="lumpsum2EffectiveDate" required="false" matrix-
filter="true">
<standard-element id="compensationEligible" required="false" matrix-
filter="true">
<standard-element id="compensationSalaryEligible" required="false" matrix-
filter="true">
<standard-element id="compensationBonusEligible" required="false" matrix-
filter="true">
<standard-element id="compensationStockEligible" required="false" matrix-
filter="true">
<standard-element id="compensationSalaryRateType" required="false" matrix-
filter="true">
<standard-element id="compensationSalaryRateUnits" required="false" matrix-
filter="true">
<standard-element id="compensationFte" required="false" matrix-filter="true">
<standard-element id="salaryBudgetTotalRaisePercentage" required="false"
<standard-element id="salaryBudgetMeritPercentage" required="false" matrix-
filter="true">
<standard-element id="salaryBudgetPromotionPercentage" required="false"
<standard-element id="salaryBudgetExtraPercentage" required="false" matrix-
filter="true">
<standard-element id="salaryBudgetExtra2Percentage" required="false" matrix-
filter="true">
<standard-element id="salaryBudgetLumpsumPercentage" required="false" matrix-
filter="true">
<standard-element id="salaryBudgetFinalSalaryPercentage" required="false"
<standard-element id="salaryBudgetLumpsum2Percentage" required="false" matrix-
filter="true">
<standard-element id="salaryBudgetTotalCompPercentage" required="false"
<standard-element id="stockBudgetStockAmount" required="false" matrix-
filter="true">
<standard-element id="stockBudgetUnitAmount" required="false" matrix-
filter="true">
<standard-element id="stockBudgetOptionAmount" required="false" matrix-
filter="true">
<standard-element id="stockBudgetOther1Amount" required="false" matrix-
filter="true">
filter="true">
filter="true">
<standard-element id="bonusBudgetAmount" required="false" matrix-
filter="true">
<standard-element id="seatingChart" required="false" matrix-filter="true">
Unsupported Fields
Below is the list of standard fields that are NOT supported as matrix filter fields in matrix reports. Below fields
should NOT have true attribute for matrix filter in data model xml (matrix-filter="true" is incorrect).
 Note
Userinfo elements are not supported.

● businessSegment
● citizenship
● ethnicity
● firstName
● function
● futureLeader
● impactOfLoss
● jobCode
● keyPosition
● lastName
● level
● gender
● married
● matrixManaged
● minority
● nationality
● newToPosition
● reasonForLeaving
● retirementDate
● riskOfLoss
● talentPool
● userId
Parent topic: Matrix Grid Reports and Succession Data Model [page 103]
Related Information

4.3.1.3.5 Showing Matrix Rating Label in People Profile
You can show the cell label for an employee's latest matrix grid report placement in People Profile.
Context
The label will respect the matrix grid report admin settings, including rating sources and processes. You can do this
for either or both matrix grid reports.

Procedure
1. In the data model, define the field that will contain the rating.
○ <matrix1Label> for the Performance/Potential matrix
○ <matrix2Label> for the How vs. What matrix
 Sample Code
<standard-element id="matrix1Label" required= "false" matrix-filter= "false">

<label>9-box placement </label> </standard-element>
2. Grant the appropriate permission for the field in role-based permissions (RBP).
Typically, this should match the permissions for the ratings used for the matrix grid report.
3. Add the field to the <personalInformation> edit-template in the <employeeProfile> view-template.
4. In the admin center, go to Configure People Profile to add the new field to the layout of a block in People Profile.
Like other fields, it must be defined within a Live Profile User Information block.
 Note
Make sure to save the block and save the dashboard.
Results
The matrix rating label for an employee's latest matrix grid report placement is displayed in People Profile.
Also, by default, the <matrix1label> and <matrix2label> fields are included in the Personal Information
export. To override this and control the fields included in the export file, use the <sysDefinedFields> view-
template.
Related Information


4.3.1.4 Succession Data Model Configuration to Display
Development Goals in People Profile
Configuration needs to be included in the Succession Data Model. This configuration enables you to include the
Development blocks in People Profile.
 Remember
Add background element:
<background-element id="sysScoreCardDevelopmentObjectivesPortlet" type-id="101">

<label xml:lang="zh-CN">Development Objectives</label>
<label>Development Objectives Block</label>
<data-field id="title" field-name="vfld1" required="true" hidden="true" max-
length="4000" max-file-size-KB="1000">
<label>Objective Id</label>
</data-field>
4.3.1.5 Defining the View Template for Legacy Position-Based

Nominations
 Remember
You must define a view-template called positionOrgChart in the Succession Data Model that lists the fields that
can be edited for positions (whether filled or vacant). Here’s an example:
<view-template id ="positionOrgChart "visibility ="none" pdf-printing-enabled

="false">
<label> Position Org Chart</label>
<description> This view template is for position edits in the position Org Chart</
description>
<edit-template id =" editPosition">
<label>Edit Position</label>
<description> Edit Position</description>
<standard-element-ref refid ="jobCode"/>
<standard-element-ref refid ="department"/>
<standard-element-ref refid ="division"/>
<standard-element-ref refid ="location"/>
<standard-element-ref refid ="custom03"/>
</edit-template>
</view-template>
The view-template can only include standard-element fields defined in the data model. However, in general, it
should only include fields that would remain unchanged regardless of who fills the position. Attributes like hire date,
gender, risk of loss, and so forth would not be appropriate.

The view-template should also include the fields used to limit Succession Planning Permission. These can include
Department, Division, Location, manager, matrix manager, HR manager, custom manager, and the custom
succession reporting fields. Jobcode is strongly recommended since it is the link to the role definition.
The position code, manager position, incumbent, and key position are part of the position record, and should not
be included in the view-template—they always appear in the position edit dialog. Position Code is a unique value
that you can define, or if it's not available, the system will fill it with a unique ID number.
Title should also not be included in the view-template as it will always be included automatically.
4.3.1.6 Talent Search and Succession Data Model
Talent Search uses the fields defined in the Succession Data Model as search criteria.
4.3.1.6.1 Talent Search Basic Information Fields
A list of all possible basic information fields and their data types.
Field Data Type
username User
email Text
gender Boolean
lastName Text
firstName Text
mi Text
department Text
division Text
location Text
jobCode Text
hireDate Date
managerId User
timezone Text
hrId User
defaultLocale Text
title Text
businessPhone Text
homePhone Text

Field Data Type
cellPhone Text
fax Text
addressLine1 Text
addressLine2 Text
city Text
state Text
zipCode Text
country Text
empId Number
custom01 Text
custom02 Text
custom03 Text
custom04 Text
custom05 Text
custom06 Text
custom07 Text
custom08 Text
custom09 Text
custom10 Text
custom11 Text
custom12 Text
custom13 Text
custom14 Text
custom15 Text
ssn Text
dateOfBirth Date
citizenship Date
nationality Date
ethnicity Date
married Boolean
minority Boolean
businessSegment Text
serviceDate Date
level Text
function Text

Field Data Type
performance Number
potential Number
objective Number
competency Number
talentPool Text
analytics Text
riskOfLoss Text
impactOfLoss Text
benchStrength Text
reasonForLeaving Text
newToPosition Boolean
dateOfPosition Date
keyPosition Boolean
futureLeader Boolean
matrixManaged Boolean
4.3.2 Compensation and Succession Data Model
Compensation pushes data to the Employee profle based on the field definitions in the Succession Data Model.
Related Information

4.3.2.1 Display Compensation Information on the Employee
Profile
Context
Some customers choose to display compensation data on the SAP SuccessFactors People Profile. The setup of
People Profile is usually configured in a previous implementation. As part of the compensation implementation, you
may need to add one or more blocks to People Profile in order to store and display compensation data.
The blocks on the compensation profile can be updated in two different ways. Your configuration and customer's
preferences will determine which option will work best.
Option 1: Publish new compensation data from the compensation worksheet directly to People Profile.
With this option, the fields in the compensation worksheet are mapped to the profile. At the end of the cycle, an
administrator can publish the finalized compensation data directly to the profile. This option is best if the customer
wants to publish the results of the compensation cycle once per year after the cycle. They can't use this option to
continue to update compensation information throughout the year.
 Note
This option will only work if your customer is using standard SAP SuccessFactors fields. This option will not
work for any custom field on the compensation worksheet. If your customer wants to publish custom fields to
the employee profile, they must use a custom background portlet as described in option 2.
Option 2: Create a custom portlet in the employee profile which is populated by the customer through an import.
The customer will need to create a file outside of the SAP SuccessFactors system which can be imported manually
or via the FTP site to load into People Profile. With this option, there is no connection or integration between the
compensation worksheets and People Profile.
Most large customers use this option so they can continue to update compensation data year round. The most
common scenario is that the customer will schedule a daily update of People Profile by transferring data from their
HRMS to the SAP SuccessFactors People Profile through a daily import. At the end of the compensation cycle,
there is not direct connection from the compensation worksheet to the profile. Instead, the customer will need to
export the compensation data from the SAP SuccessFactors system and load it into their external HRMS. This data
is then updated in their HRMS, and will thus flow through to the SAP SuccessFactors People Profile on the next
daily import.
Option 3: Publish selected worksheets in Employee Central
You can now select and publish specific completed worksheet in Employee Central for a selected Compensation
Plan template.
Creating Compensation Portlets on the Employee Profile
In order to add a block to People Profile, follow these steps:
 Remember

Procedure
1. In Provisioning of your customer's instance, go to the Succession Management section and click Import/Export
Data Model to export the data model.
2. Select Export File(Select 'Save' not 'Open') and click Submit.

3. Open the data model in your XML editor.
4. Search the data model on “compensation” to verify that the following code is not already present. If the code is
not present, you will need to add the background-element section to the compensation data model.
If your customer is using option 1 described above (to publish standard fields directly from the compensation
worksheet to People Profile), then copy and paste the XML code below at the end of the BACKGROUND-
ELEMENT section (usually to be found above any custom filters and/or element permissions):
 Example
</data-field>
<data-field id="compRating" field-name="vfld6">
<label>Comp Rating</label>
</data-field>
<data-field id="curSalary" field-name="vfld7">
<label>Salary before review</label>
</data-field>
<data-field id="promotion" field-name="vfld8">
<label>Promotion</label>
</data-field>
<data-field id="merit" field-name="vfld9">
<label>Merit</label>
</data-field>
<data-field id="extra" field-name="vfld9">
<label>Adjustment</label>
</data-field>
<data-field id="raise" field-name="vfld10">
<label>Total Raise</label>
</data-field>
<data-field id="finSalary" field-name="vfld11">
<label>Salary after review</label>
</data-field>
<data-field id="compaRatio" field-name="ffld1">
<label>Compa-ratio</label>
</data-field>
<data-field id="lumpSum" field-name="ffld2">
<label>Lump Sum</label>
</data-field>

<data-field id="totalComp" field-name="ffld3">
<label>Total Pay</label>
</data-field>
<data-field id="bonusTotal" field-name="ffld4">
<label>Bonus</label>
</data-field>
<data-field id="stock" field-name="ifld1">
<label>Stock</label>
</data-field>
<data-field id="options" field-name="ifld2">
<label>Option</label>
</data-field>
<data-field id="stockGrantDate" field-name="dfld2">
<label>Grant Date</label>
</data-field>
 Note
○ The example above includes a number of standard SAP SuccessFactors fields. You should review the
XML and remove the fields that are not included in your XML template. You can also add standard fields
as long as the data-field id exactly matches the comp-field-definition id from the compensation
worksheet.
○ The field name parameter (e.g. field-name="vfld1") in this background section of Data Model must be
unique for each field.
○ As of today, we can push the following compensation form fields out to People Profile. These are the
only fields that can be published directly from the compensation worksheet to the People Profile
standard compensation block:
jobTitle
jobLevel
jobFamily
jobRole
jobCode
payGrade
finalJobFamily
finalJobRole
finalJobCode
finalPayGrade
startDate
prorating
pmRating
compRating
curSalary
promo
merit
extra
extra2
raiseProrating
raise
finalSalary
compaRatio
rangePenetration
lumpSum
lumpSum2

totalIncrease
totalComp
bonusTotal
stock
option
stockUnits
stockOther1
stockOther2
stockOther3
grantDate
If your customer is creating a custom background information block (as described in option 2 above), then you
will need to create your own XML to add to the data model. The format is similar to the example above.
However, the background-element ID and the data-field ID must be custom IDs. You cannot use the standard
field names in a custom background information block.
 Example
<background-element id="compensationSummary" type-id="3">

<label>Compensation Summary</label>
<data-field id="effectiveDate" field-name="dfld1" max-length="999" max-
file-size-KB="1000">
<label>Effective Date</label>
</data-field>
<data-field id="jobTitle" field-name="vfld2" max-length="4000" max-file-
size-KB="1000">
<label>Job Title</label>
</data-field>
<data-field id="annualBaseSalary" field-name="vfld3" max-length="4000"
max-file-size-KB="1000">
<label>Annual Base Salary ($)</label>
</data-field>
<data-field id="performanceBonusPercent" field-name="vfld4" max-
<label>Individual Performance Bonus %</label>
</data-field>
<data-field id="sipTarget" field-name="vfld5" max-length="4000" max-file-
size-KB="1000">
<label>SIP Target ($) (2013 and beyond)</label>
</data-field>
<data-field id="actualPerformanceBonusPaid" field-name="vfld6" max-
<label>Actual Performance Bonus ($)</label>
</data-field>
<data-field id="actualSIPPaid" field-name="vfld7" max-length="4000" max-
<label>Actual SIP Paid in year ($)</label>
</data-field>
<data-field id="actualTotalTargetCash" field-name="vfld8" max-
<label>Actual Total Cash ($)</label>
</data-field>
<data-field id="totalLTIawards" field-name="vfld9" max-length="4000" max-
<label>Total LTI Awards ($)</label>
</data-field>
<data-field id="actualTotalCompensation" field-name="vfld10" max-
<label>Actual Total Compensation ($)</label>
</data-field>
</background-element>Put your syntax here>

5. Ensure that the block of code below is also inserted into the permissions section. Make sure to select either
"read" or "write" for the permission type. This controls who has read/write access to the compensation data.
Paste the XML code at the end of the ELEMENT-PERMISSION section in the data model.
 Code Syntax
<element-permission type="read/write">
<description>The roles that may write compensation</description>
<role-name>EM</role-name>
<role-name>EMM</role-name>
<role-name>EMMM</role-name>
<role-name>EMMMM</role-name>
<role-name>EH</role-name>
<background-element-ref refid="compensation"/>
</element-permission>
6. Import the adapted data model into your customer's instance in Provisioning.
 Remember
Support.
7. Go back to the main Admin Tools page. Under Employee Files, click Configure Employee Files.
8. Go to the view that should have the new compensation portlet. If you want to create a new view, click Add New
View. Otherwise, you can add the portlet to an existing view under Actions. To do so, click the Edit link.
9. Under Background Elements, click Insert Portlet.

10. Click Create & Add next to Background Portlet.

11. From the Background Element dropdown menu, select the name of the portlet from the data model. In option 1
above, the portlet is called Compensation. In option 2, the example demonstrates a portlet called
Compensation Summary. If you added the correct XML to the data model, your newly added portlet should
appear as an option here.
12. Add a portlet title.
13. Click Save to save the portlet information.

14. Click Save to save the dashboard.

15. Now that the portlet has been added to the profile, you will need to set the appropriate permissions in RBP.
Give the appropriate groups the permission to see the portlet.
16. Once the appropriate permission is granted, go to the Employee Files tab in your customer's instance for a user
that is on the completed compensation worksheet and contains data. View the compensation information.
Results
Publishing Data to Employee Profile
As soon as you have successfully created the compensation portlet on the employee profile, you can publish data.
The method you use to publish data will depend on the option you choose for creating a portlet.
If you chose option 1 to create a standard portlet using standard fields from the compensation worksheet, then you
can publish data directly from the compensation worksheet to the employee profile using the following
instructions:
1. Go to Compensation Home and select the compensation plan template you are going to publish and click
Complete Compensation Cycle.
2. Click Publish Data, then Publish in Live Profile or Publish in Employee Central. Only recurring and non-recurring
pay component amounts greater than zero, on completed worksheets, will be published.
3. If you want to review the completion status of your worksheets first, click Check Forms Status. The number of
your worksheets for the selected template and their completion status is displayed.

4. Click Submit to push out the new information.
If you configured option 2 to create a custom background portlet, then the data will need to be updated by a data
file import using the following instructions:
1. Create the data file for loading the data.
 Example
Here are a few sample data files. The first column must be the ^Userid in order to identify which employee
the line refers to. The second column should be the same as the background-element id defined in the data
model. The other columns are the exact field-name ids defined in the data model for the portlet.
This example is the data file which would go with the XML section in the data model example for Option 2
earlier in this chapter.
Here is another sample data file for a different portlet. As you can see, the data is entirely based on the
configuration in the data model.
2. To load the data, go to Admin Tools. Click Update User Information, then Import Extended User Information.
3. Browse for your file, then select Background Element. You can select the appropriate import options.
4. Click Import Extended User File. Browse for your file, then select Background Element. You can select the
appropriate import options.
5. Click Import Extended User File.

If you chose option 3 then you can publish selected worksheets in Employee Central using the following
instructions:
1. Navigate to the Admin Center.

2. In Tools search field, type Go to Compensation Home and select the compensation plan template you want to
publish. Select Complete Compensation Cycle tab.
3. Click Publish Selected Worksheet in Employee Central.
4. Publish selected worksheets displays a multi-select search field for Employee, Division, Department and
Location.
5. Based on the search options, a list of worksheets are displayed.
6. Select the worksheet(s) to publish and click Submit.
7. Once the process is complete, you will now receive an email notification to your registered mail address.

 Note
The process could take some time, depending on the number of forms. If you do not receive any
notification regarding your process, contact our Product Support.
8. While publishing selected worksheet, if there are no compensation forms for the selected template, a warning
message is displayed:
4.3.3 People Profile and the Succession Data Model
Understand the connection between People Profile, the Succession Data Model and SAP SuccessFactors
Succession Planning.
The main purpose of People Profile as it relates to Succession Planning is to collect or store data that is displayed
with the various succession planning tools.
Employee data is gathered and displayed within People Profile based on the blocks that you design and the
permissions of the user.
Any changes to field labels or activation of fields must take place within the Succession Data Model XML before you
create any People Profile blocks. After the fields or template modifications are completed in the XML, you can
configure the blocks from Admin Center Configure People Profile .
Related Information

Defining the View Template for Legacy Position-Based Nominations [page 113]
4.3.4 Recruiting and Succession Data Model
You can set up your SAP SuccessFactors system in a way such that data from Recruiting Management can be
synced across other SAP SuccessFactors modules.
Related Information
4.3.4.1 Candidate Profile Element: Background Information
Only configure background information in the Candidate Profile template if you also have background information
configured in the Succession Data Model for Employee Profile.
You need access to Provisioning to configure the Candidate Profile template.
 Remember
<background-element id="mobility" type-id="7">
Background information appears as a section on the Candidate Profile where multiple entries can be captured.

Configure background elements in the Candidate Profile Template identically with the background elements in the
Succession Data Model. If fields between the Candidate Profile and Succession Data Model aren’t identical, the
sync for that row of data fails. For example, if a field is required in one place but not in the other. However, correctly
configured fields with adequate data still sync. The background elements appear in the candidate profile record in
the same order they have in the Candidate Profile XML Template. The integer defined as the type attribute doesn’t
control the order of display for background elements.
The internal candidate profile shows the add and delete options on a background element, even though the
background element fields are all read only. This is because, the Role-Based Permissions are set up as read on that
background element while the Succession Data Model has write permissions for that background element.
The background-element tag must appear after the field-definitions (or after search or candidate summary
display options, if configured).
Within background-element, you must configure the label and data-field elements, and if applicable, picklists.
XML Attributes of a Background Element

Attributes Description
id The id attribute can be any alphanumeric string without spaces or special characters. The value
of the id attribute must be unique within the Candidate Profile template. If an id attribute on a
background element isn’t unique, an error is displayed.
type-id The type-id attribute must be an integer, and the same type attribute can't appear twice in the
Candidate Profile template. If a type-id is on a background element isn’t unique within the Can
didate Profile template, an error is displayed.
Ensure the id and type-id are unique even when you take the Succession Data Model into an ac
count as well. Don’t reuse any of the ids or type-ids from that XML for nonmatching background
elements on the Candidate Profile template, in case you later require to sm-map the back
ground elements together.
required The required attribute must be set to either true or false. If a background element is set to
true, at least one line of data must be added to that background-element to allow the can
didate profile to be saved. Currently, it isn’t possible to specify a minimum number of entries in
a background element. Either no entries are required or one entry is required. More entries are
optional.
label The content in the label element tags is configurable to contain the preferred text that dis
plays the background-element header such as Skills, Work Experience, and so on.
The label element isn’t conditional. This means, it isn’t possible for one field to display one
label to internal candidates and a different label to external candidates. It’s also not possible for
one background-element to display one label to candidates and a different label to internal
recruiting users.
 Note
Multiple label elements can be defined on the background-element, if the client has pur
chased multiple language packs.

data-field within a Back Every background-element must contain at least one data-field element. Each
ground Element
data-field element appears as a field to the end user, and all the fields within a
background-element is displayed as a record within the background-element.
You can only configure a limited number of data-field elements for each field-name type (for ex
ample, 15 vfld fields). You must consider how much data a candidate can provide without getting
frustrated and what the user experience is with many fields on UI.
The first few data fields configured appear as the headers on the entry when the entry is col
lapsed. This isn’t configurable and depends solely on the order of the fields.
The data-field element must contain the following attributes: id, field-name, required, and
max-length.
● id: This attribute allows any alphanumeric value, without spaces or special characters, but
that value must be unique within the background-element. The alphanumeric value maybe
used as the id attribute for a data-field within a different background-element and/or can
be used as the id attribute of a field-definition. There are no standard data-field ids.
 Note
The ID custom1 is reserved for technical purposes. Do not use this ID in data-
field definition.
● field-name: This attribute defines the type of data the user is allowed to enter in the
field. There’s no type attribute on background element fields. The field-name attribute
replaces the usual type attribute.
○ ifld: This field contains integer values (no decimals). Possible to have up to 8 values
(IFLD1 to IFLD8).
○ ffld: This field contains decimal or boolean values. Possible to have up to 8 values
(FFLD1 to FFLD8).
○ dfld: This field contains dates values. Possible to have up to 3 values (DFLD1 to
DFLD3).
○ vfld: This field contains alphanumeric text values. Possible to have up to 15 values
(VFLD1 to VFLD15).
○ startDate and endDate: These fields contain date values validated against each
other, where start date must precede end date. The startDate and endDate field-
name values can only be used once per background-element.
 Note
1. In Manage Template, though it’s possible to use the Name and Desc fields, it’s
recommended that you don’t implement Name and Desc fields.
2. lastmodified isn’t supported in Manage Template.ppl
The ifld, ffld, dfld, and vfld must have an integer added to the end of the attribute value,
such as vfld1, ffld2, and so on. The integers need not be in an order or need not be consecu
tive, but they must be unique within the background element.
● required: Allowable values for the required field are "true" or "false". Fields can’t be
made conditionally required. The requirement attribute applies equally to any user editing a
line of data within a background element, whether they’re an internal candidate, external
candidate, or a recruiter.

● max-length: The max-length can’t be greater than 4000 or less than 1. The max-length
acts as a character limit on the field. If the max-length is 4 and you enter more than four
characters in the field. The system validates this value while you try to save the content and
displays an error.
 Caution
Configure a max-length in combination with a picklist carefully, as doing so can re
sult in an error.
XML Sample
<background-element id="areasOfInterest" type-id="100">

<label xml:lang="en_US"><![CDATA[Areas of Interest]]></label>
<data-field id="areaOfInterest" field-name="vfld1" required="true" max-
length="4000" anonymize="false">
<label><![CDATA[Area Of Interest]]></label>
<picklist id="areaOfInterest"/>
</data-field>
<data-field id="yrsExp" field-name="vfld2" required="true" max-length="4000"
anonymize="false">
<label><![CDATA[Years of Experience in this Area]]></label>
<picklist id="yearsOfExp"/>
</data-field>
<background-element id="mobility" type-id="7">
<label xml:lang="en_US"><![CDATA[Travel and Relocation]]></label>
<data-field id="travelOrRelo" field-name="vfld1" required="true" max-
<label xml:lang="en_US"><![CDATA[Willing To]]></label>
<picklist id="travelOrRelo"/>
</data-field>
<data-field id="reloCountry" field-name="vfld2" max-length="4000"
anonymize="false">
<label xml:lang="en_US"><![CDATA[Global Location]]></label>
<picklist id="country"/>
</data-field>
<data-field id="reloUS" field-name="vfld3" max-length="4000" anonymize="false">
<label xml:lang="en_US"><![CDATA[Specific Location]]></label>
<picklist id="candState"/>
</data-field>
<data-field id="travelPercent" field-name="vfld5" required="true" max-
<label xml:lang="en_US"><![CDATA[Travel Percentage]]></label>
<picklist id="travelRequired"/>
</data-field>
<data-field id="comments" field-name="vfld4" max-length="4000" anonymize="false">
<label xml:lang="en_US"><![CDATA[Comments]]></label>
</data-field>
<label xml:lang="en_US"><![CDATA[Languages]]></label>
<data-field id="language" field-name="vfld1" required="true" max-length="250"
anonymize="false">
<label xml:lang="en_US"><![CDATA[Language]]></label>
</data-field>

<data-field id="speakingProf" field-name="vfld2" required="true" max-length="250"
anonymize="false">
<label xml:lang="en_US"><![CDATA[Speaking Proficiency]]></label>
<picklist id="languageSkillLevel"/>
</data-field>
<data-field id="readingProf" field-name="vfld3" required="true" max-length="250"
anonymize="false">
<label xml:lang="en_US"><![CDATA[Reading Proficiency]]></label>
</data-field>
<data-field id="writingProf" field-name="vfld4" required="true" max-length="250"
anonymize="false">
<label xml:lang="en_US"><![CDATA[Writing Proficiency]]></label>
</data-field>
4.3.4.2 Candidate Profile Element: sm-mapping

Use the sm-mapping element in the Candidate Profile template to sync fields on the Candidate Profile with fields on
the Employee Profile. After mapping is set up, updates made to one record automatically updates the other record
through a bidirectional sync.
When you define a field or background-element in the Candidate Profile template, you can also correlate it to an
Employee Profile standard-element field. This is the purpose of sm-mapping.
 Note
The userinfo-element fields on the Succession Data Model aren’t supported in sm-mapping.
When creating sm-mapping entries, ensure the fields that you’re mapping have the same field type. For example,
text to text and picklist to picklist. Ensure that both fields are defined with the same picklist id when sm-mapping
picklist fields. It isn’t required to match the field id between templates to map successfully, unless you’re working
with a background-element.
Background elements can be mapped. While mapping background elements, the definitions of the background
elements have to match exactly. There are some exceptions for the parts that are intrinsically different in the XML
layout. For example, display-size and max-file-size-KB attributes in the Employee Profile XML, that aren’t supported
in the Candidate Profile template.
Both Candidate Profile data-fields and background-elements can be synced to corresponding fields on the
Employee Profile. The sync is effectively real time but the synced data is subject to the regular candidate indexing
process. Updates to synced data using search isn’t available for up to an hour.
Synchronized data is set up by defining an sm-mapping element in the Candidate Profile template after the last
background-element.
 Sample Code
<sm-mapping field-id="firstName" map-to="firstName"/>

<sm-mapping field-id="outsideWorkExperience" map-to="outsideWorkExperience" />
Any Candidate Profile field-definition or background-element can be mapped in the sm-mapping element.
Candidate Profile background-elements are synched if the Candidate Profile template and Succession Data Model
background-element configuration matches. Labels can differ but all other configuration of the background-

elements must match exactly or the Candidate Profile template displays an error while saving the XML in
Provisioning.
Fields with sm-mapping reflect the permissions specified in the Succession Data Model for internal candidate
profiles, regardless of their permissions in the Candidate Profile template.
The sm-mapping element must contain a field-id attribute and a map-to attribute.
Attribute Description
field-id This attribute must reference either an existing Candidate Pro

file field-definition id or Candidate Profile
background-element id.
map-to This attribute must reference either an existing Employee Pro

file standard-element id or background-element id.
 Recommendation
● Ensure that you always include the sm-mapping section in the candidate profile configuration. In case you
fail to include, none of the fields between Employee Profile and Candidate Profile gets mapped. At least the
following mapping should exist in every Candidate Profile template:
<sm-mapping field-id="firstName" map-to="firstName" />

<sm-mapping field-id="lastName" map-to="lastName" />
● When mapping fields from the Candidate Profile to the SM data model, certain person fields only render
the userID value on the Candidate Profile, rather than a name. This is true of the Manager (M), Matrix
Manager (X), HR Rep (H), and Custom Manager (C) designators. For example, let a user define a manager
ID field in the Candidate Profile template and attempt to map it to the sm-mapping field, managerID. In
this case, only the user ID of the manager is displayed, not the first name and last name of the manager.
● For sm-mapping, field-id must have a value corresponding to either the ID attribute from a field-definition
element or the ID attribute of background element.
XML Sample
<sm-mapping field-id="profMemberships" map-to="profMemberships" />

<sm-mapping field-id="middleName" map-to="mi" />
<sm-mapping field-id="lastName" map-to="lastName" />
<sm-mapping field-id="zip" map-to="zipCode" />
<sm-mapping field-id="insideWorkExperience" map-to="insideWorkExperience" />
<sm-mapping field-id="location" map-to="location" />
<sm-mapping field-id="outsideWorkExperience" map-to="outsideWorkExperience" />
<sm-mapping field-id="certifications" map-to="certifications" />
<sm-mapping field-id="address" map-to="addressLine1" />
<sm-mapping field-id="workPhone" map-to="businessPhone" />
<sm-mapping field-id="firstName" map-to="firstName" />
<sm-mapping field-id="mobility" map-to="mobility" />

4.3.4.3 Internal Candidate Search Settings
The searching of internal candidates can be disabled entirely or limited to where a date field on the Employee
Profile is X number of days from today or earlier.
For example, clients may wish to only allow internal candidates to be found in candidate search if the “ready to
develop” date on their Employee Profile was 30 days from today or earlier.
Check the desired setting. Only one setting may be selected at a time, or both settings may be de-selected.
Candidate Search Settings
● Disable searching of internal candidates: No internal candidates will return in the candidate search results
● Find candidates where <select> is <x> days from today or earlier: Internal candidates will only return in the
candidate search results if the specified date on their Employee Profile matches the criteria specified by the
administrator. Note that if no userinfo-element date fields are set up on the succession-data-model, this option
will be grayed out and unavailable.
4.3.4.4 Mapping Data from Recruiting Management with

Employee Central Entities
To pass the new hire data from Recruiting Management to Onboarding, you must map the mandatory Employee
Central Data entity fields with the corresponding fields in Recruiting Management.
Prerequisites
● The following modules should be enabled in Provisioning:

○ Onboarding
○ Recruiting
○ Employee Central
 Remember
implementation partner. If you're no longer working with an implementation partner, contact Product
Support.
 Note
All the three modules should be enabled for the Mandatory Onboarding HRIS Elements and Employee
Central HRIS Elements to appear on the Recruit-to-Hire Data Mapping page.
● Employee Central is configured in your system and all the fields required for data mapping are available in the
Succession Data Model. For more information about Succession Data Model, see the Related Information
section.
● Recruiting Templates are configured in your system.
Onboarding supports the following recruiting templates:

○ Job Requisition Template
○ Candidate Application Template
○ Job Offer Template
For more information about the respective recruiting templates, refer to the Related Information section.
 Note
In case you don’t see any data on the Recruit-to-Hire Data Mapping page, go to Admin Center OData
API Metadata Refresh and Export tool and Refresh the Cache. It’s recommended that you log out from the
application and log in back again after refreshing the cache.
Context
Before you map the mandatory Employee Central Data entity fields with the corresponding fields in Recruiting
Management, you need to understand how the data in the Succession Data Model should be made least restrictive.
 Note
You should set very few fields in Succession Data Model as mandatory.
When you’re mapping the fields from Succession Data Model for Onboarding, the fields that are required by the
new hire should only be made mandatory on the New Hire Data Model. Rest of the fields should remain optional.
When you are mapping the fields from Succession Data Model for Employee, you should configure it as most
restrictive by setting most of the HRIS fields required by the employee as mandatory.
 Note
Succession Data Model doesn’t allow you to disable mandatory fields.
For example, personalInfo entity by design needs only First Name and Last Name as mandatory fields in
Succession Data Model. Therefore, you aren’t allowed to set these fields as nonmandatory.
● Mapping is not required for the Pay Component Non-Recurring field pay-component-code and the Pay
Component Recurring field pay-component in Recruit-to-Hire Data Mapping. If the value isn’t mapped, it is
taken from context based on the variant name of Pay Component Recurring or Pay Component Non-Recurring
(Example, for the Base salary variant mapped in Recruit-to-Hire Data Mapping its Pay Component ID is taken as
the Pay Component code).
● When the Can Override value is set to Yes in the Foundation Object (FO), the values for the Pay Component
Recurring and Pay Component Non-Recurring fields are populated from the FO on the New Hire Data Review
page and the Manage Pending Hire page when the values aren’t mapped from Recruiting.
● When the Can Override value is set to No in the FO, all the values for the Pay Component Recurring and Pay
Component Non-Recurring fields are populated from FO on the New Hire Data Review page and the Manage
Pending Hire. An error is created in the Business Process Engine (BPE) flow when the values for these
mandatory fields are different from the values in the FO, when this happens you must map the Recruiting
values to similar values in the FO.
● Skip logic implemented based on your business requirements are used in the following scenarios to skip
passing the Pay Component variant from Onboarding to the New Hire Data Review page and the Manage
Pending Hire leaving the field values empty:

○ When Pay Component code is mapped in Recruit-to-Hire Data Mapping and null value is passed for this
from Recruiting.
○ When Pay Component code is mapped in Recruit-to-Hire Data Mapping and a value different from that of
the variant name is passed for this from Recruiting.
○ When values are not passed from Recruiting for any of the fields in Pay Component Recurring or Pay
Component Non-Recurring even if some fields are mapped in Recruit-to-Hire Data Mapping.
● For the currency-code field, the value is taken from the FO if you don't map in Recruit-to-Hire Data Mapping. If
the value is not available in FO, then the value for the field is taken from the legal entity. If the value is not
available in the legal entity, then the value for the currency-code field is taken from the legal entity country.
● New hires are not lost if the mandatory fields of Pay Component Recurring and Pay Component Non-Recurring
are not mapped in Recruit-to-Hire Data Mapping to pass their value from Recruiting to the New Hire Data
Review page and the Manage Pending Hire page. An error is created in the BPE flow if you don't map the fields
to pass values from Recruiting, and no corresponding value is set in the FO.
If you want to set Middle Name as a mandatory field for personalInfo entity for Internal users, then this field should
be set as a mandatory field in Employee Data Model. If you want to set Middle Name as a mandatory field for
personalInfo entity for an External user, you need to set this as a mandatory field in New Hire Data Model.

In the Recruit-to-Hire Data Mapping tool, the fields that appear as mandatory are the mandatory fields from
Succession Data Model.
 Note
You might notice start date as one of the mandatory fields even though it is not available in Succession Data
Model. This is because start date is one of the system mandatory fields.

Procedure
1. Go to Admin Center Recruit-to-Hire Data Mapping .

2. Select Mandatory Onboarding HRIS Elements to map the mandatory fields that are required for successful
initiation of Onboarding.
3. Select Employee Central HRIS Elements to map the required fields.
In the mapping interface, the Employee Central field labels and fields are shown on the left side, whereas the
available Recruiting templates and Recruiting fields are shown on the right side.
 Note
The Succession Data Model determines which fields are required and are denoted by a red asterisk.
4. To map an Employee Central field to a Recruiting field, select the Job Requisition Template, Candidate
Application Template, or Job Offer Template from the Recruiting Template dropdown menu and select the
corresponding fields under Recruiting fields.
 Note
Click Clear Changes to remove the modification you've made in the current session.
5. It’s recommended that you map the following mandatory Employee Central entities:
○ personalInfo
○ employmentInfo
○ jobInfo
 Note
Map all the mandatory fields under these entities correctly to avoid data mismatch.
Here’s an example of all the mandatory fields that you can map:
○ personalInfo.first-name
○ personalInfo.last-name
○ employmentInfo.start-date
○ jobInfo.company
○ jobInfo.manager-id
 Note
The manger info "Job Info - Supervisor" that flows from Recruiting to Employee Central should be same
as the manager info set in Position Management.
Other than these fields, there can be other fields from the Employee Central Data Model that are mandatory. It
is recommended that you map jobInfo.event-reason and jobInfo.start-date for the process to work
seamlessly.
 Note
Whether a specific field is mandatory or not in the Employee Central Data Model depend on the
configuration in the Data Model.

 Note
Time fields should not be mapped for internal hires. For details on mapping time related data, refer to the
Managing Time Related Data in Onboarding link in the Related Information section.
 Note
Event Reason isn’t maintained as part of Job Requisition. Currently, the admin must add custom fields for
each Job Req or Applicant Tracking System API.
6. To map configured country/region-specific fields, click  (Expand) next to the entity and select the country/
region-specific entity.
7. Click Validate all Entities to check that all mandatory fields are mapped and all data types are correct.
8. To configure variant fields, select the entity from the list, then click  (Add) and choose from the available
variants, then map the available fields.
For the variant entities listed below, data from Recruiting to Employee Central is passed only for those variants
of an entity that has the Employee Central Key field value (if the field is present) to be same as the variant
name. For example, if the variant selected for Email_Info is personal then the value of the field email-type for
this variant should be personal. If business is selected as email-type for this variant, then data isn’t passed
from Recruiting to Employee Central.
Entity Employee Central Key Field
Email_Info email-type
Phone_Info phone-type
IM_Info domain
Job_Relations_Info relationship-type
Home_Address address-type
Pay_Component_Non_Recurring pay-component-code
Pay_Component_Recurring pay-component
 Note
○ The variant name shouldn't contain any special characters except "-".
○ For Foundation objects not supported by Recruiting, the value passed from Recruiting should be equal
to the external code of the object.
○ For applicable entities in Admin Centre Manage Business Configuration , the Enabled for
Onboarding field should be set to Yes for data of an entity to be passed from Recruiting to Employee
Central during initiate onboarding.
○ Base objects for entities must be enabled in Admin Centre Manage Permission Roles .
○ Employee Central key fields that are of picklist type should be mapped to the same picklist from
Recruitment.

9. Click Validate and Save.
 Note
Currently, only the Employee Central entities listed in the table below, are supported while integrating
Onboarding with Employee Central. If you map any other entities apart from these, it is ignored and won’t
be saved in Employee Central.
Entities in Onboarding Supported Entities in In

Entity Name Flow ternal Hire Block
National_ID_Card Supported Not Supported National Id Information
Personal_Info Supported Not Supported Biographical Information
Phone_Info Supported Not Supported Part of Contact Information

block
Email_Info Supported Not Supported Part of Contact Information

block
IM_Info Supported Not Supported Part of Contact Information

block
Pay_Component_Non_Re Supported Supported Spot Bonus

curring
Pay_Component_Recurring Supported Supported Part of Compensation Infor

mation block
Emergency_Contact Supported Not Supported Emergency Contact
Emergency_Contact_Pri Supported Not Supported Primary Emergency Contact

mary
Emergency_Contact_Sec Supported Not Supported Secondary Emergency Con

ondary tact
Person_Global_Info Supported Not Supported Part of Personal Information

block (appears when the
user adds a Country/Region
in this block)
Employment_Info Supported Supported Employment Details
Home_Address Supported Not Supported Addresses
Job_Info Supported Supported Job Information
Comp_Info Supported Supported Compensation Information
Work_Permit_Info Supported Not Supported Work Permit Information
Job_Relations_Info Supported Supported Job Relationships
Per_Person_Info Supported Not Supported Personal Information
Internal Hire flow is always validated against Employee Data Model, unlike Onboarding flow which is
validated against the Succession Data Model. For the Internal Hire process to work, the following 6 entities
are validated and mapped:
○ Job_Info

○ Comp_Info
○ Job_Relations_Info
○ Employment_Info
○ Pay_Component_Non_Recurring
○ Pay_Component_Recurring
Rest of the entities' data is ignored even if it is passed from Recruiting. Also, it is not mandatory to map the
Termination End Date for internal hire.
If you don't map the event reason value for Comp_Info using Recruit-to-Hire Data Mapping the value is
taken from the event reason of Job_Info which is either configured by the OnSave rule or passed from
Recruiting.
 Note
If you remove or disable any fields or entities in Business Configuration UI, it doesn’t remove the existing
references of the entities or fields from the "Candidate to Employee Integration" template. You need to
make sure that there are no data mismatches between Business Configuration UI and "Candidate to
Employee Integration" template.
Results
Once the mapping is complete, data collected during the Recruiting process can pass to the new hire's employee
record in Employee Central.
 Note
If you want to check the values passed from Recruiting to Onboarding, you can use the Suite Tool to perform
the verification. For more information on how to perform the check, refer to the "Checking the Values Passed
from Recruiting to Onboarding" topic in Related Information section.
Related Information

Configuring Job Requisition Template
Configuring Candidate Application Template
Configuring Job Offer Template
Managing Time Related Data in Onboarding
Checking the Values Passed from Recruiting to Onboarding

4.3.5 Talent Management and the Succession Data Model
Talent Management uses employee related data that is defined in the Succession Data Model. It can also be the
source for trend and background data that needs to be defined in the Succession Data Model.
Performance Management, 360 Reviews, and the Succession Data Model [page 141]
You can display certain data from your performance and 360 review forms in the Employee Profile. This
data is part of trend or background data when needing to export from the system.
Goal Management and the Succession Data Model [page 145]

You define custom fields as custom-filters in the Succession Data Model. These fields can then be used
as filters for goal import by Goal Management.
Calibration and the Succession Data Model [page 146]

Calibration needs Succession Data Model to define rating elements and the Calibration History Block for
the module to display the ratings in a session and also to display the block. There are other dependencies
that Calibration has on the Succession Data Model
Related Information
4.3.5.1 Performance Management, 360 Reviews, and the

You can display certain data from your performance and 360 review forms in the Employee Profile. This data is part
of trend or background data when needing to export from the system.
You can also show ratings and other data from performance forms in blocks on the Employee Profile. For this data
to be available to Employee Profile, you need to include elements in the Succession Data Model as shown in the
code sample.
<background-element id="sysScoreCardCompBehaviorPortlet" type-id="33">

<label>Competency Behavior Breakdown Block</label>

 Remember
For this block Use this element ID
Objective Rating Block sysScoreCardObjRatingsPortlet
Competencies Block sysScoreCardCompetenciesPortlet
Performance History Block sysScoreCardPerfHistoryPortlet
Competency Behavior Breakdown Block sysScoreCardCompBehaviorPortlet
Parent topic: Talent Management and the Succession Data Model [page 141]
Related Information

4.3.5.1.1 Performance Management Blocks
You can configure blocks in SAP SuccessFactors People Profile to display ratings from Performance Management
forms.
Here's a list of supported blocks related to Performance Management.
● Trend blocks:
○ Overall performance rating block
○ Overall potential rating block
○ Overall goal rating block
○ Overall competency rating block
These blocks display respective ratings from all forms as multiple records for employees. For more information,
refer to Configuring a Trend Information Block in People Profile.
● Scorecard blocks:
○ Performance History block
○ Competencies block
○ Behaviors block
○ Goal Ratings block
These blocks are affected by processes and display respective ratings according to configuration in a process.
For more information, refer to Configuring a Scorecard Block in People Profile.
● History block in the History section: It shows employees' completed forms in the past 12 months. The data isn't
configurable.

 Note
● Rating scale labels are displayed in their default language in the blocks.
● The Performance History block uses predefined fields to display data. You can't add fields to or hide fields
from the block.
● Forms in the Performance History block are sorted alphabetically by form title in a descending order.
● The Competencies block displays an average of the ratings from Performance Management forms, 360
Reviews forms, and competency ratings from SAP SuccessFactors Learning.
● To display Learning URL in the Competencies block, make sure both the SAP SuccessFactors Learning
integration and Transcript features are enabled. For more information, refer to Setting up and Enabling the
Transcript Feature.
● If a competency has more than one rating from different forms, the average rating is displayed in the
Competencies block. The same rule applies to behaviors in the Behaviors block.
● For Scorecard blocks, if the rating scale in a process is different from that in a form, ratings displayed in the
blocks will be normalized to the rating scale in the process. For example, the form has a 5-point rating scale,
and the rating scale selected in the process is a 3-point rating scale. Therefore, ratings will be normalized to
the 3-point scale. Item weight won't be taken into account during the normalization. For more information
about normalization, refer to Calculation Process.
4.3.5.1.2 Adding Competencies by Customized Data Type
For customers using Job Description Manager, you can pull job-specific competencies in a competency section by
customized data type.
Prerequisites
● The use-jobcode attribute is set to true.

● You have access to Provisioning.
 Remember
Support.
Context
Generally, employees' competencies are auto-populated to a competency section according to their job code. You
can use the <fm-comp-filter-mapping> element to customize the mapping data type.

Procedure
1. In Provisioning, configure the data types to be used for mapping competencies in the Succession Data Model.
This example specifies that Job Code, Department, Division, Custom03, and Custom04 are valid mapping data
types.
<view-template id="sysMappingDataTypes" visibility="none" pdf-printing-

enabled="true">
<label>View Template for mapping data types</label>
<description>This View Template is for Families and Roles mapping data
types</description>
<edit-template id="sysMappingDataTypesEditTemplate">
<label>Edit Template for Job Roles Data Type</label>
<description>Edit Template for Job Roles Data Type </description>
<standard-element-ref refid="jobCode"/>
<standard-element-ref refid="department"/>
<standard-element-ref refid="division"/>
</edit-template>
</view-template>
2. Create a CSV file based on one particular mapping data type that you've configured, and import the file to
Admin Center Import Job Roles .
The file should include roles, families, values defined in the mapping data type, and competencies to be
mapped.
3. In an XML form template, add the <fm-comp-filter-mapping> element.
 Note
For the location where the element should be added, refer to the DTD Definition section in Competency
Section (competency-sect).
4. Specify the mapping data type in the element.
Only one mapping data type can be specified for one competency section. Employees' value for the specified
mapping data type will be used for fetching the applicable job roles and the corresponding competencies.
The default value of the enable attribute is false. To enable the feature, set it to true.
This example shows how to map competencies based on Department.
<fm-comp-filter-mapping enable="true">
<fm-comp-filter-element refid="department"/>
</fm-comp-filter-mapping>
 Sample Code
<competency-sect index="3" configurable= " false " mgt-only= " false " use-
jobcode= " true " category-filter-opt= "no-filter" no-rate= " false " no-
weight= " false " summ-opt= "99" split-cmt= " false " rating-opt= "1" cmt-
opt= "2" suppress-item-comments= "0" behavior-rating-opt= "0" behavior-cmt-
opt= "1" behavior-mode-opt= "0" in-summ-display= " true " in-overall-rating=
" true " no-group= " true " use-behavior= " false " if-no-ratings-then-ignore-
section= " false " lock-item-weights= " false " in-objcomp-summ-display= "
false " in-objcomp-summ-overall-rating= " false " show-comp-expected-rating=
" false " comp-expected-rating-format= "0" show-behavior-expected-rating= "

false " behavior-expected-rating-format= "0" behavior-weighted= " false "
sect-mode= "normal" ez-rater-expand-all= " false ">
<comp-sect-name><![CDATA[Competencies]]></comp-sect-name>
<comp-sect-intro><![CDATA[<b>Skills</b>]]></comp-sect-intro>
<fm-sect-config>
<rating-label><![CDATA[Leader Rating]]></rating-label>
<rating-label-others><![CDATA[Associate Rating]]></rating-label-
others>
< default-rating><![CDATA[Not Rated]]></ default-rating>
<hidden-strength-threshold>0.0</hidden-strength-threshold>
<blind-spot-threshold>0.0</blind-spot-threshold>
<num-decimal-places>2</num-decimal-places>
<publish-button-label><![CDATA[Publish Content]]></publish-button-
label>
</fm-sect-config>
<sect-weight>10.0</sect-weight>
<fm-sect-scale show-value= " false ">
<scale-source>1</scale-source>
<scale-id><![CDATA[Competency Scale]]></scale-id>
<scale-type><![CDATA[ null]]></scale-type>
</fm-sect-scale>
<fm-competency index= "1" removable= " false ">
<fm-comp-id>1159</fm-comp-id>
<fm-comp-name><![CDATA[ null]]></fm-comp-name>
<fm-comp-desc><![CDATA[ null]]></fm-comp-desc>
</fm-competency>
<meta-grp-label><![CDATA[Group]]></meta-grp-label>
<fm-comp-filter-mapping enable="true">
<fm-comp-filter-element refid="department"/>
</fm-comp-filter-mapping>
</competency-sect>
4.3.5.2 Goal Management and the Succession Data Model
You define custom fields as custom-filters in the Succession Data Model. These fields can then be used as
filters for goal import by Goal Management.
Related Information
Adding Custom Filters in the Succession Data Model [page 82]

4.3.5.3 Calibration and the Succession Data Model
Calibration needs Succession Data Model to define rating elements and the Calibration History Block for the
module to display the ratings in a session and also to display the block. There are other dependencies that
Calibration has on the Succession Data Model
Related Information
4.3.5.3.1 Calibration Elements in the Succession Data Model
Calibration depends on the Succession Data Model for the rating elements to be made available in a session. Other
dependencies are described in this topic as well.
You can configure some or all of the rating elements in a data model. These elements can then be used by you in a
calibration session. Also, the labels as configured in the data model appear in the Calibration template and the
Calibration session. Following are the rating elements that can be pulled into a calibration session:
Other data can be displayed in the Calibration session bin or grid view in addition to the rating elements. These
standard background elements are:
● riskOfLoss
● impactOfLoss
● reasonForLeaving
 Note
Risk of Loss, Impact of Loss, and Reason for Leaving are fields you can enable or disable on the data tab
when you configure a calibration template. If these fields are defined in your data model, regardless of
whether or not they’re enabled at the template level, they still show up as an entry under Filter Option.
To add custom fields to the Filter Option, you add the desired fields as custom filters. Example code:
 Sample Code
<custom-filters>

<filter-module id="calibration">
<filter-module>
<custom-filters>
 Note
The refid here are the standard custom fields included in the data model as custom01-custom15.
 Note
This filter applies to all calibration templates at your company. It can’t be configured uniquely for separate
Calibration sessions.
4.3.5.3.2 Calibration History Block
The Calibration History block can be configured to display in Employee Profile. This block displays up to 5 rating
types from calibration sessions. The displayed items are configured in the Calibration template.
When the following code is present in the Succession Data Model, you’re able to add the Calibration History block to
the Employee Profile view.
<background-element id="calibrationHistoryPortlet" type-id"138">

<label>Calibration History Block</label>
4.3.6 Employee Central and the Succession Data Model
Employee Central is a vast module that is heavily dependent for its behavior on the data models.
Fields related to employee data are defined in the Succession Data Model. There are other configurations that are
in the Succession Data Model which impacts how the Employee Central works. This topic collates the
dependencies on the Succession Data Model that are beyond the data structure for Employee Central.
Related Information

4.3.6.1 Additional Information about Sections in the Job

Information XML
Here is some information about sections within the XML for Job Information. You do not have to use sections. Use
sections only if you want to influence which fields appear in which section on the UI. If you do not define sections in
the Succession Data Model, the system defines which fields appear in which section.
Allowed Sections for JobInfo
The hris-section tag has to be inside the start and end tag of the jobInfo HRIS element. If you use sections in
the data model, all fields that are part of the jobInfo HRIS element have to be inside an hris-section tag. If you
use sections in the Succession Data Model, you also have to use sections in the country/region-specific Succession
Data Model.
You can add customer-specific fields to all sections except positionInfoList.
Here is a list of the hris-sections that you can use:
Hris-section ID Standard Label How To Use This Section
positionInfoList Position Information If you want to use hris-sections and you

have activated Position Management,
you have to add the position HRIS
field to this section. You cannot use other
fields in this section.
orgFieldsList Organization Information You can use this section for fields related
to the company.
If you use the following fields in your data

model, you have to put them into this
hris-section:
● company
● businessUnit
● location
● department
● costCenter
● division

Hris-section ID Standard Label How To Use This Section
jobFieldsList Job Information You can use this section for fields related
to the job, for example:
● Job Classification
● Job Title
● FTE
timeOffRelatedFields Time Information You can use this section for time-related
fields. For example,
Time Sheet fields:
● Time Recording Profile

● Time Recording Variant
● Time Recording Admissibility
Time Off fields:
● Holiday Calendar
● Work ScheduleFor
● Time Profile
eeoFieldsList EEO Information You can use this section for fields related
to equal employment opportunity (EEO).
This is only applicable to USA.
If you use the following fields in your data

model, you have to put them into this
hris-section:
● eeo1JobCategoryUSA
● eeoJobGroupUSA
● eeoClass
Using Sections in the Country/Region Specific Data Model
If you use sections in the country/region-specific Succession Data Model, all the countries with a jobInfo HRIS
element have to use sections. If a country has no jobInfo HRIS element defined in the data model, you do not
have to add sections to that country.
You can use different sections in each jobInfo HRIS element for each country in the country/region-specific
You can sort the fields in a section differently for each country, meaning, the order of the fields in a section can be
different for each country defined in the country/region-specific Succession Data Model.

You can also even change the order of the sections for each country defined in the country/region-specific
4.3.6.1.1 Entry Dates, Event-Based Dates, and TimeIn

Calculation for Job Information
The following entry-date fields are filled and saved in the system when their base fields of job classification (hris-
field with id="job-code"), position (hris-field with id="position") , company (hris-field with
id="company") , location (hris-field with id="location"), department (hris-field with
id="department"), or pay scale level (hris-field with id="payScaleLevel") are changed:
● Job Entry Date

● Position Entry Date
● Company Entry Date
● Location Entry Date
● Department Entry Date
● Pay Scale Level Entry Date
In case of a change in one of the base field values, all configured entry dates in the modified record are calculated,
propagated to future job records and saved to the database. Entry dates always refer to the standard job
classification, position, company, location, department, or pay scale level fields and cannot be calculated based on
custom fields. The respective base fields in Job Information must be configured in addition to the entry date fields
and the TimeIn fields. If the base field does not contain a value, the respective entry date is cleared.
When Centralized services is activated in the system, the entry dates are always automatically calculated, which
means that values set using the UI, imports, or business rules are overwritten by the automatically calculated value.
We recommended that you set the visibility to ‘View’ for these fields in the Succession Data Model (SDM) or the
Country/Region-Specific Succession Data Model (CSFSDM). If one of the base fields changes, all entry dates in the
record are recalculated. Since permissions also control/override the visibility of a field, users should not have insert
and correct permissions for these fields.
Changes to the base fields also trigger the calculation of the TimeIn fields:
● Time in Job
● Time in Position
● Time in Company
● Time in Location
● Time in Department
● Time in Pay Scale Level
These transient fields are calculated and filled in the History UI, Employment Info page and Manager Self-Service
(MSS).
The TimeIn calculation determines the number of years/months/days an employee has worked on a job, position,
company, location, department, or pay scale level. This calculation is based on approximate values, because not all
months have the same number of days. These values are transient and not saved to the database.
To use at least one of the entry date fields in existing Job Information records, run the Initialize additional entry date
fields in job info job. You can find this in Provisioning under Manage Scheduled Jobs. Initialization of entry date fields
in existing job info records has the following impact:

● If the field already contains a value, this value will be overwritten.
● If you first use a subset of these fields and run the job and later you want to use an additional entry date field,
you have to run the job again. However, note that the value of all entry date fields will be overwritten. If you did
not change any of the entry dates, this will not have any impact, since the calculation during save processes
and in the job is the same.
● Only fields configured in SDM or CSFSDM will be written by the job.
Event-Based Date Fields
If configured in the Succession Data Model (SDM) or the Country/Region-Specific Succession Data Model
(CSFSDM), the Hire Date, Termination Date, Leave of Absence Start Date, and Leave of Absence Return Date fields
are automatically filled with the effective start date in case a Job Information record is created/changed/deleted
based on their triggering events: Hire, Rehire, Termination, Leave of Absence and Return to Work. The event-based
date fields are only saved to the database if they are configured in the SDM or the country/region-specific SDM.
In case the Job Information’s effective start date is changed in a record with one of the above-mentioned events,
the hire date/termination date /leave of absence start date/leave of absence return date is newly set according to
the new effective start date.
In Job Information History, the date fields are propagated to future records until a new record with a suitable event
(Hire, Rehire, Termination, Leave of Absence, Return to Work) is created. The event-based date fields contain the
date on which the respective triggering event last occurred in this user’s Job Information History. This means that
the hire date contains a value throughout the user’s entire history, even in and after a termination record. Similarly,
the Leave of Absence Start Date is not cleared when a ‘Return to Work’ record is created. In case a Job Information
record is deleted, the event-based date fields are propagated from the previous Job Information records.
Related Information
Job Information
Scheduling Jobs
4.3.6.1.1.1 Initializing New Entry Date Fields in Existing Job Info

Records
To use at least one of the new entry date fields, you must run the Manage Scheduled Jobs Initialize additional
entry date fields in job info in Provisioning.
 Remember

 Caution
Do not schedule these jobs to recur on any basis. The jobs must not be run more than once since they will
process all Job Information records for all users to set the related entry dates. Ideally if the job must be run
again (if you are now using more of the Entry Date fields), please plan to run the job outside of business hours if
possible.
There is also the Initialize job entry date and position entry date in job info job that initializes only the job and
position entry dates. These jobs will initialize the fields for all existing Job Information records in the database. The
job writes the entry date fields in the same way as the UI logic.
 Note
Any values set through the UI will be overwritten by this job.
If you choose to initially use a subset of the new fields, run the job and later decide to use another one of the new
entry date fields, you will have to run the job again. While the new job will overwrite the value of all entry date fields,
this will have no effect on the values if the fields were not manually modified in the UI. This is because the
calculation performed in the UI and in the job is the same. Note that if the value was changed by rules, those values
are also overwritten.
 Note
Only fields configured in the Succession Data Model or the Country/Region-Specific Succession Data Model
will be written by the job.
The following fields are affected:
● Job entry date

● Department entry date
● Company entry date
● Location entry date
● Position entry date
● Pay Scale Level entry date
For these following date fields, there is no TimeIn calculation.
● Hire date
● Termination date
● LOA start date
● RLOA start date
They are automatically filled with the effective start date in case a Job Information record is created/changed/
deleted depending on the event:
● Hire
● Rehire
● Termination
● Leave of Absence
● Return to Work
In case the Job Information’s effective start date is changed in a record with one of the above-mentioned events,
the hire date/termination date /leave of absence start date/leave of absence return date is newly set according to

the new effective start date. In Job Information History, the date fields are propagated to future records until a new
record with a suitable event (Hire, Rehire, Termination, Leave of Absence, Return to Work) is created. In case a Job
Information record is deleted, the date fields are propagated from the previous Job Information records. During
new hire, no event-based date fields are set. The hire/rehire date is set automatically in Employment Details and
Job Information History.
Example of Entries in Succession Data Model
 Sample Code
.
.
<hris-field id="jobEntryDate" visibility="view">
<label>Job Entry Date</label>
</hris-field>
<hris-field max-length="128" id="timeInJob" visibility="view">
<label>Time In Job</label>
</hris-field>
<hris-field id="positionEntryDate" visibility="view">
<label>Position Entry Date</label>
</hris-field>
<hris-field max-length="128" id="timeInPosition" visibility="view">
<label>Time In Position</label>
</hris-field>
<hris-field id="companyEntryDate" visibility="view">
<label>Company Entry Date</label>
</hris-field>
<hris-field max-length="128" id="timeInCompany" visibility="view">
<label>Time In Company</label>
</hris-field>
<hris-field id="locationEntryDate" visibility="view">
<label>Location Entry Date</label>
</hris-field>
<hris-field max-length="128" id="timeInLocation" visibility="view">
<label>Time In Location</label>
</hris-field>
<hris-field id="departmentEntryDate" visibility="view">
<label>Department Entry Date</label>
</hris-field>
<hris-field max-length="128" id="timeInDepartment" visibility="view">
<label>Time In Department</label>
</hris-field>
<hris-field id="payScaleLevelEntryDate" visibility="view">
<label>Pay Scale Level Entry Date</label>
</hris-field>
<hris-field max-length="128" id="timeInPayScaleLevel" visibility="view">
<label>Time In Pay Scale Level</label>
</hris-field>
<hris-field field max-length="128" id="hireDate" visibility="view">
<label>Hire Date</label>
</hris-field>
<hris-field field max-length="128" id="terminationDate" visibility="view">
<label>Termination Date</label>
</hris-field>
<hris-field max-length="128" id="leaveOfAbsenceStartDate" visibility="view">
<label>Leave of Absence Start Date</label>
</hris-field>
<hris-field max-length="128" id="leaveOfAbsenceReturnDate" visibility="view">
<label>Leave of Absence Return Date</label>

</hris-field>
.
.
</hris-element>
4.3.7 Learning and Succession Data Model
Integration points of Learning with the Succession Data Model are listed in this topic.
Required HRIS Elements for External Learners [page 154]

To integrate external learners with SAP SuccessFactors Platform, you must make sure that the following
HRIS elements and fields are configured in your data model.
Related Information
4.3.7.1 Required HRIS Elements for External Learners
To integrate external learners with SAP SuccessFactors Platform, you must make sure that the following HRIS
elements and fields are configured in your data model.
Required Extended Enterprise Data Model
HRIS Element HRIS Field Notes
personInfo N/A The element is required but not any of

the fields. There is no harm in also im
porting the fields.

HRIS Element HRIS Field Notes
personalInfo first-name Although the three hris-fields are re

quired, there is no harm in importing or
last-name
using additional fields.
middle-name
homeAddress N/A The element is required but not any of

porting the fields.
phoneInfo phone-type Although the six hris-fields are required,

there is no harm in importing or using ad
isPrimary
ditional fields.
country-code
area-code
phone-number
extension
emailInfo email-type Although the three hris-fields are re

quired, there is no harm in importing or
isPrimary
using additional fields.
email-address
employmentInfo N/A The element is required but not any of

porting the fields.
Parent topic: Learning and Succession Data Model [page 154]
4.3.8 Onboarding and the Succession Data Model
Onboarding depends on the Succession Data Model when needing to pull or push data to other modules, especially
Employee Central.
There are Admin Center tools that you use to map Onboarding entities to elements in the Employee Central.
Configuring the Succession Data Model for Pre-Day 1 Access [page 156]
You must configure your Succession Data Model to add a custom field IsOnboardingUser, which is
required to classify Pre-Day 1 users and grant them the required access permissions to your SAP
Onboarding 1.0 to Employee Central UI Field Mapping Guide [page 157]

Related Information
4.3.8.1 Configuring the Succession Data Model for Pre-Day 1

Access
You must configure your Succession Data Model to add a custom field IsOnboardingUser, which is required to
classify Pre-Day 1 users and grant them the required access permissions to your SAP SuccessFactors HXM Suite.
Prerequisites
 Remember
Context
SAP SuccessFactors Onboarding has a feature where you can provide your new hires access to the application
before their hire date. The Succession Data Model doesn’t contain IsOnboardingUser field by default. By adding
IsOnboardingUser as a custom field to your Succession Data Model to include, you can enable the system to
initialize this parameter when Pre-Day 1 user records are created. For every Pre-Day 1 user record, the
IsOnboardingUser field value is set to YES. Based on this field's value, you can classify Pre-Day 1 users and setup
criteria for granting role-based permissions.

Procedure
1. Find one of the fifteen standard elements that are set aside for customization.
 Note
The id attribute of these fields is set to custom01 to custom15. Pick a field that is not used already for
another field.
2. Modify the label element of the custom field you have selected to be IsOnboardingUser.
 Sample Code
<standard-element id="custom02" max-length="255" required="false" matrix-

filter="false">
<label>IsOnboardingUser</label>
<label xml:lang="en-US">IsOnboardingUser</label>
</standard-element>
Task overview: Onboarding and the Succession Data Model [page 155]
Related Information
Onboarding 1.0 to Employee Central UI Field Mapping Guide [page 157]
4.3.8.2 Onboarding 1.0 to Employee Central UI Field Mapping

Guide
Add a New Employee Page One
UI Field Name Expected Employee Central Field Format
Hire Date employmentInfo.start-date
Company jobInfo.company
Event Reason jobInfo.change-reason
Name Information
First Name personalInfo.first-name
Last Name personalInfo.last-name
Middle Name personalInfo.middle-name

Suffix personalInfo.suffix
Person Information
Date of Birth personInfo.date-of-birth
Country/Region of Birth personInfo.country/region-of-birth
City of Birth personInfo.place-of-birth
Employee Info
Person ID personalInfo.person-id-external
National ID
Country/Region nationalIdCard.country/region
National Id nationalIdCard.national-id
Primary nationalIdCard.is-primary
The Contact Information object on the second page contains the new employee's e-mail and phone information.
These fields expect a variant as the field type. This is determined in the Onboarding 1.0-Employee Central mapping
tool. You can configure these as either static variants (for example, Home or Business) or as dynamic variants.
Dynamic variants substitute another Onboarding 1.0 field enclosed in $ symbols, for example $phone$.
Add a New Employee Page Two
Personal Information
Gender personalInfo.gender
Marital Status personalInfo.marital-status
Native Preferred Language personalInfo.native-preferred-lang
Preferred Name personalInfo.preferred-name
Contact Information
Email Information - Eail emailInfo.email-address.$emailType$
Email Information - Primary emailInfo.isPrimary.$emailType$
Phone Information - Country/Region Code phoneInfo.country/region-code.$phoneType$
Phone Information - Number phoneInfo.phone-number.$phoneType$

Global Information The fields related to a country/region have the country/region code as a prefix in the second dropdown in
the mapping tool. These examples use the country/region code for India, IND.
Religion globalInfo.[IND].genericNumber1
Number of Children globalInfo.[IND].genericNumber2
Occupational Code globalInfo.[IND].genericNumber3
Marital Status Since globalInfo.[IND].genericNumber4
Other Allowances. globalInfo.[IND].genericNumber5
Child Educational Allowances globalInfo.[IND].genericNumber6
Child Hostel Allowances globalInfo.[IND].genericNumber7
Addresses You do not need to map the address type. The value of the variant for fields in the Address object is used to populate
the address type by Employee Central.
Country/Region homeAddress.country/region.$addresstype$
Address 1 homeAddress.address1.$addresstype$
City homeAddress.city.$addresstype$
State homeAddress.state.$addresstype$
Zip homeAddress.zip.$addresstype$
Emergency Contact Emergency contact fields should be designated as repeating fields in the Onboarding 1.0 data dictionary.
Name Emergencycontact.[#].first-name
Phone Number Emergencycontact.[#].phone
Relationship Emergencycontact.[#].relationship
Email Emergencycontact.[#].email
Dependent Emergencycontact.[#].dependent
Emergency Contact Emergencycontact.[#].isEmergencyContact
Primary Emergencycontact.[#].isPrimary

Dependent Info In order for values to populate the Dependent Info fields in Employee Central, the values must be mapped to
emergency contact, and the isDependant checkbox should be enabled.
Add a New Employee Page Three
Employment Details
Hire Date employmentInfo.start-date
Original Start Date employmentInfo.originalStartDate
Seniority Start Date employmentInfo.seniorityDate
Eligible for Stock employmentInfo.eligibleForStock
Service Date employmentInfo.service-date
Professional Service Date employmentInfo.professionalServiceDate
First Date Worked employmentInfo.firstDateWorked
Job Information
Company jobInfo.company
Business Unit jobInfo.business-unit
Local Division jobInfo.division
Department jobInfo.department
Cost Center jobInfo.location
Work Location jobInfo.cost-center
Reporting Location jobInfo.timezone
Direct Upline jobInfo.manager-id
Job Code jobInfo.job-code
Job Title jobInfo.job-title
Local Job Title jobInfo.local-job-title
Pay Grade jobInfo.pay-grade

Add a New Employee Page Four
Compensation Information
Pay Type compInfo.pay-type
Pay Group compInfo.pay-group
Is Eligible for Benefit compInfo.eligible-for-benefit
Is Eligible for Car compInfo.is-eligible-for-car
Benefits Rate compInfo.benefits-rate
Payroll System Id compInfo.payroll-system-id
Payroll Id compInfo.payroll-id
Pay Component - Compensation
Amount payComponentRecurring.paycompvalue.$paycomponent$
Currency payComponentRecurring.currency-code.$paycomponent$
Frequency payComponentRecurring.frequency.$paycomponent$
Pay Component - Pay Targets
Amount payComponentRecurring.paycompvalue.$paycomponent$
Currency payComponentRecurring.currency-code.$paycomponent$
Frequency payComponentRecurring.frequency.$paycomponent$
Pay Component - Spot Bonus
Issue Date payComponentNonRecurring.pay-date
Type payComponentNonRecurring.pay-component-code
Currency Code payComponentNonRecurring.currency-code
Amount/Percentage payComponentNonRecurring.amount
Parent topic: Onboarding and the Succession Data Model [page 155]
Related Information
Configuring the Succession Data Model for Pre-Day 1 Access [page 156]

4.3.9 Data Models and Other Integrations
Besides other modules, there are integration points that are configured in the data models for some of these
integrated functionalities and features to work as desired.
Related Information
4.3.9.1 Configure My Benefits Link for Benefitfocus
Context
To configure the My Benefits link for Benefitfocus, carry out the following steps in EC. This also requires access to
Provisioning for the EC company.
Procedure
1. To activate and configure the link to Benefitfocus via jump-to, include the authentication via IdP with BF as the
mapping key.
2. For activation, choose Company Company Settings Enable Employee Central V2 My Benefit Link .
3. Enter the target URL:
https://[SFSF data center servername]/sf/idp-init/sso/bf?saml2=true

4. In Provisioning, select the company and choose Import/Export Data Model under Succession Management.
5. Download the data model and add the following (if it is not already there):
 Sample Code
<tab-element id="ectbenefitsfocus">
<label>My Benefits</label>
<label xml:lang="en-GB">My Benefits</label>
<label xml:lang="de-DE">Meine Vorteile</label>
</tab-element>
6. In Employee Central Admin Tools, choose Configure Employee Files under Employee Files.
7. Check that the My Benefits entry is visible.
8. In Admin Center, choose Manage Permission Roles under Manage Security.

9. Choose the relevant permission role.
10. Under Permission settings, click Permission…
11. Under Employee Views, check that the My Benefits entry is visible. Make sure the permission role is assigned to
the relevant users.
4.3.9.2 Adding the CompanyExitDate Field to the User Record

Most customers already have the standard user field companyExitDate configured in the system. If you don't, you
need to add it before you can use the DRTM data purge function.
Prerequisites
You are an administrator with access to the Business Configuration UI.
Context
Adding companyExitDate to your data model with the Business Configuration UI allows you to proceed with
setting up the data purge function but it does not enable you to see this field in the employee profile or in the

employee export file. Later, you can choose to add it to the profile or export file as you would any other user
information field.
If you don't have access to the Business Configuration UI, ask Product Support to add the following element to your
data model:
 Sample Code
<standard-element id="companyExitDate">
<label>Company Exit Date</label>
</standard-element>
Procedure
1. Go to Admin Center Manage Business Configuration .
2. Go to Employee Profile Standard companyExitDate in the navigation pane.
If the companyExitDate field is not yet enabled in your system, it is marked with an X. If it is already enabled,
it is marked with a checkmark and you do not need to complete this task.
3. Add a default label in the Label field.
4. If necessary, click the localization icon to open a dialog and add labels in other languages in your system.
5. Set the Enabled setting to Yes.
6. Click Save to save your change.
Next Steps
To complete the minimum prerequisite steps so that you can proceed to set up the DRTM data purge function,
proceed to configure the required sync between your HRIS and the SAP SuccessFactors platform. If you use
Employee Central, you can do this with the Business Configuration UI. If you need to import these dates frosm an
external HRIS, please contact Product Support.
4.3.9.3 Data Models and Workflows
In order to have workflows work in your instance, there are elements that are needed in both Succession Data
Model and Corporate Data Model. These elements already exist in the XML files of your data model.
Check that the foundation object for workflow has been created as well as the following HRIS elements exist in your
<hris-element id=”wfConfig”>
</hris-element>
<hris-element id=”wfConfigStep”>
</hris-element>
<hris-element id=”wfStepApprover”>

</hris-element>
Check that the pending approvals tab has been created in your Succession Data Model:
<tab-element id=”pendingapprovals”>
<label>Pending Requests</label>
</tab-element>
Related Information
4.3.9.4 Setting up the Data Models for Employee Central

Payroll
Setting Up the Corporate Data Model [page 166]

In Provisioning, you must prepare the Corporate Data Model for master data replication.
Setting Up the Succession Data Model for Master Data Replication [page 168]
In Provisioning, you must prepare the Succession Data Model for master data replication.
Setting Up the Country-Specific Succession Data Model [page 169]

Enhance the Country-Specific Succession Data Model to correspond to fields that are needed for Employee
Central Payroll.
Setting Up the HRIS Propagation Configuration XML [page 170]
4.3.9.4.1 Setting Up the Corporate Data Model
In Provisioning, you must prepare the Corporate Data Model for master data replication.
Prerequisites
You have access to Provisioning.
 Remember

Procedure
1. Under Succession Management, choose Import/Export Corporate Data Model XML.
 Caution
The choices under Succesion Management have similar names. Ensure that your selection is correct.
2. Determine the length restrictions of the foundation object ID as shown in the following table:
Foundation Object Max. Length of ID Recommendation
Company (Legal Entity) 20 ≤4
Location 20 Mapping always required
Cost Center 20 ≤ 10
Job Classification 10 ≤2
Pay Group 4 ≤2
Pay Component 10 ≤4
Frequency 32
Next Steps
Read Master Data Replication Information in the Employee Central Payroll using Point-to-Point Integration guide to
set up the Corporate Data Model with picklists. A picklist is a configurable set of options from which a user can
make a selection, typically in a dropdown menu or smart search list. You can define the picklists used in your
system to limit the values a user can enter, preventing them from entering an invalid value. If the picklists match the
code lists in the Implementing Employee Central Payroll guide, you can also avoid additional mapping efforts.
Task overview: Setting up the Data Models for Employee Central Payroll [page 166]
Related Information

4.3.9.4.2 Setting Up the Succession Data Model for Master
Data Replication
In Provisioning, you must prepare the Succession Data Model for master data replication.
Prerequisites
You have access to Provisioning.
 Remember
Procedure
1. Under Succession Management, choose Import/Export Data Model.
 Caution
The choices under Succession Management have similar names. Ensure that your selection is correct.
2. Activate the following fields:
Set the attribute visibility of this field to

In this HRIS Element… both Is it required?
personInfo Place-Of-Birth Yes
Birth-Name Yes
personalInfo nationality Yes
employmentInfo firstDateWorked Yes (For US only)
 Note
firstDateWorked is only needed for
legal reporting for the US. It isn’t
relevant for master data replication
or payroll processing.
jobInfo workingDaysPerWeek Yes
employment-Type Yes
3. Create the following labels for the Payroll profile menu:

In this Tab Element… Create this Name label…
payrollIntegration Payroll Information
Next Steps
Read the Master Data Replication Information section to set up the Corporate Data Model with picklists. A picklist is
a configurable set of options from which a user can make a selection, typically in a dropdown menu or smart search
list. You can define the picklists used in your system to limit the values a user can enter, preventing them from
entering an invalid value. If the picklists match the code lists in the Implementing Employee Central Payroll guide,
you can also avoid additional mapping efforts.
Related Information

4.3.9.4.3 Setting Up the Country-Specific Succession Data

Model
Enhance the Country-Specific Succession Data Model to correspond to fields that are needed for Employee Central
Payroll.
Procedure
1. Under Succession Management, choose Import/Export Country Specific XML for Succession Data Model.
 Caution
The choices under Succesion Management have similar names. Ensure that your selection is correct.
2. Activate the following fields:
In this HRIS Element… Activate this field…
jobInfo country-of-company (and set visibility to view)

In this HRIS Element… Activate this field…
payScaleType
payScaleArea
payScaleLevel
payScaleGroup
Related Information

4.3.9.4.4 Setting Up the HRIS Propagation Configuration

XML
Procedure
● To enable country-specific value help for payScaleArea, payScaleType, payScaleGroup, and payScaleLevel you
need to update the HRIS Propagation XML file.
For more information, see the Uploading Picklists for Pay Scale Area and Pay Scale Type in the Employee Central
Payroll guide and Step 4 Updating HRIS Propagation XML of the section Setting up country-specific picklists in
the Implementing Employee Central Core guide under Setting up the Succession Data Model.
Related Information


5 Country/Region-Specific Data Models
Setting up country/region-specific data models allows you to have fields only needed for that country/region as
well as have fields in specific formats, for example, date or monetary amounts.
What are country/region-specific data models?
Certain types of information need to be entered in a specific format depending on the country/region the company
is located in. For example, the format for national ID can vary depending on the country/region – for USA, the social
security number follows the format 999-99-9999, in Great Britain the format is AA999999A.
By setting up country/region-specific data models, you reflect these country/region-specific differences by

defining the following:
● Fields that are country/region-specific

For example, Fair Labor Standards Act (FLSA) is only valid for USA.
● Field values that are used for all countries
For example, the local job title can vary depending on the country/region in which the employee works. You can
set up specific picklists for each country/region that contain country/region-specific values.
● Fields that require a country/region-specific format
A field that is applicable to all countries, but that can be formatted differently in each country/region, for
example, the address or national ID.
What country/region-specific Data Models Exist?
There are two country/region-specific data models:
● Country/Region-Specific Corporate Data Model

You use this data model to set up country/region-specific fields and picklists for HRIS elements that have been
previously defined in the Corporate Data Model. For example, country/region-specific job codes. You can also
change the format for the corporate address for a country/region.
In the standard XML file, the following setup is already included:
○ For all countries listed in the data model, the corporate address (HRIS-element ID: corporateAddress)
with country/region-specific address fields is already defined. Also, custom fields you can use as a basis to
define customer-specific fields are listed.
○ For USA, in addition to the above mentioned information, jobClassLocal is defined, this includes fields
for federal reserve bank, EEO job categories, and the FLSA status.
● Country/Region-Specific Succession Data Model
You use this data model to set up country/region-specific fields, formats, and picklists for HRIS elements that
have been previously defined in the Succession Data Model. For example, international formats for addresses
and national IDs. In the standard XML file, the following setup is already included:
○ National ID format for all countries/regions listed in the standard XML file

Country/Region-Specific Data Models CONFIDENTIAL 171
○ Home address with country/region-specific fields for all countries listed in the standard XML file
○ Global information for some of the countries/regions listed in the standard XML file. For example, ethnic
group, religion, or for USA, information about veterans and Visa type. Corresponding picklists are assigned
to each field.
○ For USA, in addition to the above mentioned information, the job information is defined which includes
fields for the FLSA status, the EEO job group and EEO categories.
5.1 Adjusting the Data Model for Country/Region-Specific

Fields
Update the data models to meet the needs of your company.
Context
In the data models, you can do the following:
● Change existing fields in the standard XML files You can overwrite labels, change attributes, or delete fields not
needed as with the Corporate or Succession Data Model.
● Add custom fields to contain country/region-specific information
Procedure
1. If the HRIS element the field belongs to isn’t yet included in the data model, copy it over from the Corporate
orSuccession Data Model and insert it under the corresponding country/region. Consider that you can add
country/region-specific fields only to those HRIS elements listed below:
Option Description
Country/ You can only add countr/regiony-specific fields, values, and formats for the following HRIS elements and
region-specific their fields:
Corporate ○ Corporate address (HRIS-element ID: corporateAddress)
Data Model This is the address format used in the location foundation object.
○ jobClassLocal: All fields relevant for jobClassLocal are defined in the country/region-specific
Corporate Data Model.
Country/ You can only add country/region-specific fields, values, and formats for the following HRIS elements and
region-specific their fields:
Succession ○ Job information (HRIS-element ID: jobInfo)
Data Model ○ Employment information (HRIS-element ID: employmentInfo)
○ Compensation information (HRIS-element ID: compInfo)
○ Address information (HRIS-element ID: homeAddress)

172 CONFIDENTIAL Country/Region-Specific Data Models
Option Description
○ Global information (HRIS-element ID: globalInfo): All fields relevant for global information are de
fined in the country/region-specific Succession Data Model. This is the country/region-specific ele
ment for the Personal Information.
○ National ID (HRIS-element ID: nationalIdCard)
2. Insert the custom field within the HRIS element tags.

3. Overwrite the label with the text you want to appear on the UI, and set the visibility to both, for example, if you
want the field to be visible and editable on the UI.
Make fields used in the Corporate or Succession Data Model country/region-specific.
4. Insert the HRIS element the field belongs to into the country/region-specific data model under the
corresponding country/region. Copy also the label and the xml:lang translations over, if existing. Don’t forget
to insert the end tag of the HRIS element at the end. Consider that you can add country/region-specific fields
only to those HRIS elements listed in the previous step.
5. Copy the HRIS field from the Corporate or Succession Data Model and paste it in the country/region-specific
data model within the HRIS-element tags.
If you want to make a field from the Succession Data Model country/region-specific, consider the following:
○ If you want to change only the label depending on the country/region, you can copy the field over into the
country/region-specific Succession Data Model and change only the text inside the label tags.
○ If you want to change attributes of the field depending on the country/region, you have to delete the field
from the Succession Data Model as you can use the field and its attributes only once — either in the
Succession Data Model, or in the country/region-specific Succession Data Model. This doesn’t apply to
fields from the HRIS element homeAddress — these can be used in both data models with different
attributes.
6. Adjust the label and attributes according to your country/region-specific needs.
With the attribute display-order-follows you can influence the field order of the country/region-specific
field on the UI.
7. If this field is to be used in other countries, insert the corresponding HRIS element and HRIS field under the
corresponding country/region ID.
 Note
For fields from the country/region-specific Succession Data Model that belong to jobInfo,
employmentInfo, compInfo or nationalIdCard, it’s important to remember that if you reuse a
country/region-specific field across several countries, you can only change the label but must keep the
same attributes for all the fields (visibility, required, and so on).
8. Repeat the steps for all fields you want to make country/region-specific.
5.1.1 Country/Region-Specific Fields
Country/Region-specific fields are needed, for example, for address or national IDs.
In this example, you define that if the employee works for a company that is located in the United States. The field
EEO Job Group that is used to identify the equal employment opportunity (EEO) class of the employee is displayed
in the job information. The 3-letter code for the country/region is the ISO code. The ID for the HRIS element is the

ID from the Succession Data Model for the job information. The predefined values the user can select come from
the picklist EEOJOBGROUP_USA.
<country id=”USA”>
<hris-element id=”jobInfo”>
<hris-field max-length=”256” id=”eeo-class” visibility=”both”
required=”false” pii=”false”>
<label>EEO Job Group</label>
<picklist id=”EEOJOBGROUP_USA” />
</hris-field>
</hris-element>
</country>
5.1.2 Country/Region-Specific Formats for Fields
You can define the format for country/region-specific fields.
In this example, you define that the format for the national ID for USA follows the structure XXX-XX-XXXX. You can
make this the only format allowed if the employee works for a company in the USA. The ID for the format group is
the ID defined in the Succession Data Model for this field. Display format is a hint for the user in which format to
enter the national ID if the entry is not correct. <reg-ex> is the regular expression which is used to validate the
user input.
<country id=”USA”>
<format-group id=”national-id”>
<format id=”ssn”>
<instruction>Social Security Number</instruction>
<display-format>XXX-XX-XXXX</display-format>
<reg-ex>[\d]{3}-[\d]{2}-[\d]{4}</reg-ex>
</format>
</format-group>
</country>
5.1.3 Influencing the Field Order on the UI
Your instance follows the field order for elements as defined in the Corporate or Succession Data Model. However,
this order can be changed for the fields defined in the Country/Region-Specific Succession Data Model.
Prerequisites
You’ve downloaded the relevant country/region-specific data model and have it open and ready to edit in your xml
editor.

Context
The order, in which fields are displayed in the UI, is determined by the order they’re listed in the xml files.
The country/region-specific data model only contains fields that vary from country/region to country/region.
Standard fields common across the company instance are defined in the Succession Data Model or the Corporate
Data Model. Fields from the country/region specific data models follow the fields from the Succession Data Model
or Corporate Data Model.
 Note
The field order in which you enter the data for country/region-specific elements is only relevant for the HRIS
element homeAddress. Here, the order of the fields you define in the country-specific data model is the order
the fields appear on the UI.
You can change order in which the fields display by including the display-order-follows tag in your country/
region-specific data model xml.
 Note
● Start Date always appears on top of the screen as the date when the change is to be effective.
● You can’t change the order of the fields in the Country/Region-Specific Corporate Data Model.
● Change of the order only works in the View and not in the Edit Mode.
Procedure
1. Find the field you wish to change the order for.
2. Modify the xml by adding the display-order-follows as shown in the example.

If the following code is in the field definition for country id="USA"
<hris-field max-length=”256” id=”flsa-status” visibility=”both” required=”false”

pii=”false”>
<label>FLSA Status</label>
<picklist id=”FLSASTATUS_USA” />
<display-order-follows ref-id=”employee-class” />
</hris-field>
The field FLSA Status is displayed after the field for the employee-class for USA

5.2 Setting Up Country/Region-Specific Picklists
Picklists allow you to control what users see when selecting values from a dropdown list. Configure country/region-
specific picklists to make sure that users only see values relevant to their region.
Context
Configuring a country/region-specific picklist is a 5–step process:
Step 1: Modify the country/region-specific Succession Data Model
Step 2: Define the picklists
Step 3: Set permissions for the Job Information fields
Step 4: Update the business rule for propagation
Step 5: Validate your changes
5.2.1 Modify the Country/Region-Specific Succession Data

Model
Context
Consider the following extract from the country/region-specific Succession Data Model. In this example, we’ll be
defining country/region-specific values for the fields notice-period and sick-pay-supplement . The extract provided
below is for Germany (country id=”DEU”).
<country id="DEU">
<hris-field max-length="256" id="country-of-company" visibility="view">
<label>Country</label>
<picklist id="ISOCountryList"/>
</hris-field>
<hris-field max-length="256" id="sick-pay-supplement" visibility="both">
<label>Sick Pay Supplement</label>
<picklist id="SICKPAYSUPP" parent-field-id="country-of-company"/>
</hris-field>
<hris-field max-length="256" id="notice-period" visibility="both">
<label>Notice Period</label>
<picklist id="NOTICEPERI" parent-field-id="country-of-company"/>
</hris-field>
</hris-element>
</country>

Procedure
1. Go to the Admin Center Manage Business Configuration .

2. Under Employee Central, select jobInfo.
3. Add the fields, following the information below.
A few things to note:
○ For the field country-of-company, the picklist id ISOCountryList has been defined.
○ The field country-of-company must be in the same hris-element (that is, block), preferably above the fields
sick-pay-supplement and notice-period.
○ For the field sick-pay-supplement, the picklist SICKPAYSUPP has been defined, whose parent picklist is the
picklist ISOCountryList which is assigned to HRIS field country-of-company. Likewise, for the field
notice-period, the picklist NOTICEPERI has been defined, whose parent picklist is also the picklist
ISOCountryList which is assigned to HRIS field country-of-company. In both cases, the parent-
field-id has to refer to the HRIS-field ID country-of-company.
○ To prevent issues of values in the picklist not cascading correctly, make sure that the code of country-of-
company (or any parent field ID that you are configuring) is at the beginning of the custom string. Also
ensure that both fields are in the same HRIS section.
5.2.2 Define the Picklists
Context
Procedure
1. Go to the Admin Center Picklist Management .

2. Select Export all picklist(s).
3. Choose Submit.
Now that you’ve downloaded the picklist file, modify the picklist file to include the country-specific entries.
Start by noting the OptionId for Germany in the picklist ISOCountryList. You will need this when defining the
entries for the picklist SICKPAYSUPP and NOTICEPERI. In this example, the OptionId is 5949.
 Note
OptionId is a system generated code that gets generated when you upload the picklist. Note that the
OptionId column must be left blank, when uploading the CSV file, for the code to be generated.

You are now ready to add the entries for the picklist SICKPAYSUPP and NOTICEPERI. Sample entries are shown
below. Note the reference to the OptionId. The OptionId for Germany in the picklist ISOCountryList (5949) now
serves as the parentOptionId for the picklists SICKPAYSUPP and NOTICEPERI.
Upload the modified picklist using the Admin Center Picklist Management option.
5.2.3 Set Permissions for the Job Information Fields
Procedure
Set the permissions for the Job Information fields.
In this example, we need to set the permission for the Germany specific fields for Sick Pay Supplement and Notice
Period. The Permission Settings page is shown below.

5.2.4 Update the Business Rule for Propagation
Procedure
Update the propagation business rule. You can also point to the MDF Foundation Objects: Cost Center, Department,
Division, Business Unit, Legal Entity and Legal Entity Local.
In the rule, set up the propagation from company, as defined in the Configure Object Definition page, to country-of-
company in the Succession Data Model.

5.2.5 Validate the Changes
Procedure
Validate your changes.
Verify your changes by checking that when the country is set to Germany, you see the following entries displayed
for the Sick Pay Supplement and Notice Periodfields:
Sick Pay Supplement picklist when country is set to Germany
Notice Period picklist when country is set to Germany

Important Disclaimers and Legal Information
Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:
● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your agreements
with SAP) to this:
● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.
● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.
● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such links, you
agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this information.
Videos Hosted on External Platforms

Some videos may point to third-party video hosting platforms. SAP cannot guarantee the future availability of videos stored on these platforms. Furthermore, any
advertisements or other content hosted on these platforms (for example, suggested videos or by navigating to other videos hosted on the same site), are not within the
control or responsibility of SAP.
Beta and Other Experimental Features

Experimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by SAP at
any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use the
experimental features in a live operating environment or with data that has not been sufficiently backed up.
The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your feedback
(e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.
Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax and
phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of example
code unless damages have been caused by SAP's gross negligence or willful misconduct.
Bias-Free Language
SAP supports a culture of diversity and inclusion. Whenever possible, we use unbiased language in our documentation to refer to people of all cultures, ethnicities, genders,
and abilities.

Important Disclaimers and Legal Information CONFIDENTIAL 181
www.sap.com/contactsap
© 2022 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form

or for any purpose without the express permission of SAP SE or an SAP
affiliate company. The information contained herein may be changed
without prior notice.
Some software products marketed by SAP SE and its distributors

contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for

informational purposes only, without representation or warranty of any
kind, and SAP or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP or
SAP affiliate company products and services are those that are set forth
in the express warranty statements accompanying such products and
services, if any. Nothing herein should be construed as constituting an
additional warranty.
SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.
Please see https://www.sap.com/about/legal/trademark.html for

additional trademark information and notices.
THE BEST RUN

COmplete SAP SF Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

COmplete SAP SF Guide

Uploaded by

Copyright:

Available Formats

CONFIDENTIAL

Document Version: 1H 2022 – 2022-08-19

SAP SuccessFactors Data Model Reference Guide

THE BEST RUN

1 Data Models in SAP SuccessFactors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2 Introduction to Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

3 Corporate Data Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Succession Data Model (SDM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

SAP SuccessFactors Data Model Reference Guide

5 Country/Region-Specific Data Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

SAP SuccessFactors Data Model Reference Guide

Type of Change Description More Info

SAP SuccessFactors Data Model Reference Guide

Type of Change Description More Info

SAP SuccessFactors Data Model Reference Guide

Data for any company is of two kinds.

SAP SuccessFactors Data Model Reference Guide

Working with Data Model Files in Provisioning [page 9]

Adding Picklists to Fields in the Data Model XML [page 15]

Corporate Data Model [page 23]

SAP SuccessFactors Data Model Reference Guide

1. Go to Admin Center Employee Files .

To work with... Select Link

Succession Data Model (SDM) Export Succession Data Model

Country/Region Specific (SDM) Export Country-Specific Succession Data Model

3. Export the XML file.

SAP SuccessFactors Data Model Reference Guide

The XML file is successfully downloaded to perform your edits.

Task overview: Data Models in SAP SuccessFactors [page 6]

Working with Data Model Files in Provisioning [page 9]

1.2 Working with Data Model Files in Provisioning

Learn how to begin working with your data model files.

You have access to Provisioning for your company instance.

SAP SuccessFactors Data Model Reference Guide

To work with... Select Link Notes

Country/Region Specific SDM Import/Export Country/Region Specific

Country/Region Specific CDM Import/Export Country/Region Specific

SAP SuccessFactors Data Model Reference Guide

5. Export or Import the XML file.

Task overview: Data Models in SAP SuccessFactors [page 6]

SAP SuccessFactors Data Model Reference Guide

1. Go to Admin Center Foundation Object Configuration .

To work with... Select Link

Corporate Data Model (CDM) Import/Export Corporate Data Model XML

Country/Region-Specific CDM Import/Export Country/Region Specific XML for Corporate

SAP SuccessFactors Data Model Reference Guide

3. Import XML file.

Task overview: Data Models in SAP SuccessFactors [page 6]

SAP SuccessFactors Data Model Reference Guide

1.4 Data Model Definitions (DTDs) for SAP SuccessFactors

Data Models in Scope of This Guide and Their DTDs

Succession Data Model (SDM) sf-form.dtd

Country/Region Specific Succession Data Model (CSFSDM) country-specific-fields.dtd

Corporate Data Model (CDM) corporate-datamodel.dtd

Country/Region Specific Corporate Data Model (CSFCDM) country-specific-fields.dtd

sf-form.dtd is also used by other modules in SAP SuccessFactors.

Parent topic: Data Models in SAP SuccessFactors [page 6]

SAP SuccessFactors Data Model Reference Guide

● You’ve created the picklist.

1. Note the Code for the picklist that you’ve created.

The id can be from:

SAP SuccessFactors Data Model Reference Guide

<hris-field max-length="128" id="suffix" visibility="none">

The data-field and the picklist id aren’t required to be the same.

hris-element Foundation object for organization-related data in your in

corporateAddress — Part of foundation object loca Organization structure

dynamicRoleAssignment — Part of foundation object dy Dynamic Role

Element description This is where you enter a text that de

Element hris-field With hris-field, you define each in

Element hris-associations Associations define the relationship be