SF EC Master Impl
SF EC Master Impl
2 Configuration Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1 Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Setting Up the Basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Setting Up Attachment Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Creating a Super Admin User in Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 Data Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6 Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Characteristics of Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
MDF vs. Legacy Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Deleting a Foundation Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Forward Propagation for Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Validations for Foundation Objects, Generic Objects, Associations, and Picklists . . . . . . . . . . . . . . . . 34
Requirements for Legacy Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Effective Dating. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Foundation Objects for Structuring Your Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Foundation Objects for Handling Job-Related Areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Foundation Objects for Handling Pay-Related Areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Other Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
2.7 MDF Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Adding Search Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Working with Associations, Field Criteria and Value Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Optional: Editing the Country/Region and Currency Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Adding a New Country/Region and Related Fields to LegalEntity. . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Adding a New Country/Region and Related Fields to Job Classification. . . . . . . . . . . . . . . . . . . . . . .86
Configuring Standard Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.8 Generic Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Employee Central provides comprehensive, integrated, searchable people and organizational information.
Information is natively stored in our product so other modules can access the information. It captures information
about a company’s organization, pay, job structure, and employees. It drives a lot of the information used in the
Employee Profile as well as Talent.
Employee Central data is smart because it allows you to capture history, create associations, use effective-dated
objects, define automated workflows, and automatically configure options for on-screen selections.
Here is a brief overview to show the differences between Employee Central and the employee profile.
What does it do? Drives all core HR administration, trans- Drives all Talent and Learning processes.
What is it based on? Person and employment records. Employment records based on User ID.
Where does the data come from? Data from imports and manual entry. Data from HRIS Sync from Employee
Central.
This document covers the core of Employee Central, but there are many parts to Employee Central. Hopefully, this
will help you find all the information that you need.
All guides for Employee Central can be found on the SAP Help Portal at https://help.sap.com/hr_ec
Topic Link
Company Structure Overview Implementing and Managing the Company Structure Overview
in Employee Central
Data Model Field Information for Employee Central Data Model Field Information in Employee Central
Integration with SAP ERP SAP SuccessFactors Employee Central Integration to SAP
Business Suite
Related Information
This is the recommended implementation sequence for Partners and Consultants. We strongly recommend that
you follow this sequence for the first few implementations and discuss any variations with your Team Lead.
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
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 .
This section describes the steps to get started with your imple-
mentation, including the different options you need to select in
Provisioning to enable Employee Central.
The section How do you create the Super Admin describes the
different steps required to create the Super Admin.
Step 3: Defining the Corporate Data Model Refer to the SAP SuccessFactors Data Model Reference Guide
for information about how to set up the Corporate Data Model.
Step 4: Defining the Country/Region-Specific Corporate Data Refer to the SAP SuccessFactors Data Model Reference Guide
Model for information about how to set up the Country/Region-Spe-
cific Corporate Data Models.
Step 5: Setting up MDF Foundation Objects MDF Foundation Objects [page 77]
Step 6: Configuring the Succession Data Model Refer to the SAP SuccessFactors Data Model Reference Guide
for information about how to set up the Succession Data
Model.
Step 7: Configuring the Country/Region-Specific Succession Refer to the SAP SuccessFactors Data Model Reference Guide
Data Models for information about how to set up the Country/Region-Spe-
cific Succession Data Models.
Step 10: Configuring Business Rules Business Rules in Employee Central [page 196]
This section describes how to set up the different rules for your
system.
Step 11: Creating Event-Reason Derivation Rules Event Reason Derivation Business Rules [page 200]
Step 12: Creating Workflow Derivation Rules as well as Work- Implementing and Configuring Workflows in Employee Central
flows guide in the SAP Help Portal.
Step 13: Setting Role-Based Permissions Role-Based Permissions for Employee Central [page 113]
Step 15: HRIS Sync Human Resource Information System (HRIS) Synchronization
[page 255]
This section describes how you can sync data from Employee
Central to other modules.
Step 16: Setting up Leave of Absence You need to set up Time Off to use leave of absence. Note that
you need to decide first whether you want to use leave of ab-
sence as standalone or together with other Time Off features.
Depending on this decision, the setup varies.
Optional: Setting Up Employee Central Advanced Reporting Employee Central Advanced Reporting: Standard Reports
Note
If you want to have the same IDs in the Employee Central
and Employee Central Payroll systems, we recommend
that you use numeric employee IDs in Employee Central,
because the PERNR is numeric in Employee Central Pay-
roll. Therefore, an alphanumeric ID cannot be used across
all processes in the Employee Central Payroll system.
Optional: Setting Up Higher Duty or Temporary Assignment Implementing Higher Duty or Temporary Assignment
This guide describes how to set up the Job Profile Builder tool.
This is information about the recommended sequence for partners and consultants to integrate Employee Central
with other SAP SuccessFactors modules.
It is recommended to either start with Employee Central or end with Employee Central.
Before implementation, consider the following topics and how they impact other modules:
• Employee ID generation
• Foundation Objects
• Company Structure
• Job Structure
• Global Assignment
• Concurrent Employment
1.4 Assignment ID
Assignment ID is an identifier assigned to the work relationship between a person and the company. The
relationship could be an employment relationship, contingent relationship, pensioner relationship, intern, global
assignment, or others. A person can have one or many work relationships with a company at the same time, for
example, concurrent employments or home and host assignment in a global assignment.
Note
Currently, assignment ID is not supported in some SAP SuccessFactors areas, for example, Learning,
Compensation, Onboarding 1.0, and data protection and privacy features. This might cause display
inconsistencies across the HCM suite. Refer to the Important Notes about Assignment ID to find the specific
areas impacted by assignment ID as well as the areas where assignment ID is not supported. This document
will be regularly updated to reflect the latest development of assignment ID.
Caution
Before you change assignment IDs, we recommend that you evaluate the risks associated with the
inconsistencies. If assignment ID is not supported in the SAP SuccessFactors areas you've enabled, please
don't make any changes to assignment ID at this time.
The system automatically generates assignment IDs for users created prior to the Q3 2019 release, and their
default values are the same as the current user IDs. However, in the Employee Central-enabled instances, if you
Previously, when you wanted to change user IDs in some cases, such as employee relocation or going live on
Employee Central or another HRIS system, a support ticket was needed. The user ID conversion process was
costly and time-consuming. In addition to this, user ID conversion wasn’t supported in Employee Central, Metadata
Framework, or SAP HANA database.
Now, you can use assignment ID to identify users and change it if needed.
Assignment ID is a unique identifier in Employee Central and assigned to the Employee Central object employment.
It is a multiple purpose field. Currently assignment ID supports two main scenarios. One is the Platform use case
of managing users with the Manage Users, Employee Import, Import Extended User Information admin tools, and
OData APIs. The other is the integration use case of the Employee Central to SAP ERP system or SAP S/4HANA
(SAP ERP/S/4). In the Employee Central integration use case, the assignment ID is equal with the SAP ERP/S/4
PERNR (personnel number). Employee Central is responsible for ensuring the assignment ID matches the SAP
ERP/S/4 PERNR format and determines an assignment ID by using rules during all processes where a new
employment is created. As a result, the assignment ID (8 digit max) is generated and replicated to the integrated
SAP ERP/S/4 system.
For more information, refer to Using Assignment ID in Employee Central Integration with SAP ERP HCM.
Note
You must decide on one scenario and are not allowed to switch between the two scenarios.
You can use the Check Tool to find any missing or inconsistent assignment IDs in the system. Any fix would result in
the update to your data in Employee Central. We recommend selecting the check available under the Employee
Central Core Employment Information section.
Read the following table to find the differences and relationships between person ID, UUID, user ID, and assignment
ID.
Person ID (person-id-external) A unique identifier of a person Yes UUID and person ID are in a
in Employee Central. Person
one-to-one relationship.
ID identifies a natural person.
An employee generally has User ID and assignment ID are
only one person ID through- in a one-to-one relationship.
out their time at the company,
since this ID is associated to One person ID is associated to
each person. one or more user IDs and as-
Related Information
Component Description
LOD-SF-EC-WFL Workflows
LOD-SF-EC-LOC Localization
LOD-SF-EC-ADV Advances
LOD-SF-EC-DED Deductions
LOD-SF-EC-MOB Mobile
Here are some data protection and privacy features specific to Employee Central rather than the entire HCM suite.
For information about data protection and privacy in your SAP SuccessFactors system, refer to Setting Up and
Using Data Protection and Privacy on the SAP Help Portal.
Data Blocking
For HRIS workflows in Employee Central as well as MDF workflows, data blocking is only available for completed
workflows. This means, for workflows that have the status approved, rejected, or canceled. The completed
workflows can only be viewed by users with the correct permissions.
Read Audit
For Employee Central, we recommend not only marking fields to be flagged for the read audit, but also flagging
fields as sensitive, which masks them on the UI. Both of these fields can be added to the HRIS elements in the
Business Configuration UI. This helps to prevent that a log is written every time that UI is accessed.
Only those fields marked for read access are reported. Masked fields are not considered for read audit. If a field is
masked but also enabled for read audit, it will be included only if the Show link is selected for that field.
Masked fields hide sensitive information and should only be made visibile if required.
Note that attachments cannot be tagged as sensitive information. If an error occurs for a field with an attachment,
then the system will not show that card.
The following core areas support read audit. Note that Address and Deductions do not support read audit.
Area Sub-area
Change Audit
The following core areas support the change audit. This includes both effective and non-effective dated entities.
Area Sub-area
Employment Information Compensation Info - Pay Component Recurring & Spot Bonus
Non-Effective-Dated Create I
Non-Effective-Dated Change U
Non-Effective-Dated Delete D
Effective-Dated Create I
Note
• If an admin changes data for users in different countries with different retention times, then the system
applies the lesser of the retention times, for example, 3 months instead of 6 months.
• The system does not check whether target users are Employee Central users or not, for example, a user
could be from Onboarding or other modules.
To get started with the your implementation, you need to do a number of initial configuration tasks.
The tasks listed below are the minimum required Provisioning settings. You will make further Provisioning settings
based on your requirements as you progress through the implementation.
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.
Prerequisite
Tasks
• Check Tool
• Admin Alerts on the Home Page
Tip
2.1 Provisioning
Provisioning is an internal tool that SAP consultants and partners use to set up SAP SuccessFactors modules for a
customer. You can access each customer instance from within 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.
Here is an overview of the basic options that can be selected for Employee Central.
Procedure
1. Log on to Provisioning with your user name and password, and select the company from the list shown or
through the initial letter of the company ID.
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.
This allows the admin to purge inactive users. For more information about purging users, refer to the Setting
Up and Using Data Protection and Privacy guide.
7. Optional: For a new customer, if you want to use the new Payment Information (MDF-based, effective-
dated, and employment-specific), select the following checkbox. You don't have to set up the HRIS
elements directDeposit and paymentInfo in Succession Data Model. For more information, refer to the
Implementing and Configuring Payment Information in Employee Central guide on the SAP Help Portal.
• Enable New Payment Information (MDF-based, effective-dated, and employment-specific). [CAUTION: For
existing customers, by switching on this feature via Upgrade Center, the old direct-deposit-based UIs, APIs
and objects will be irreversibly deactivated. New Payment Information is integrated into Employee Central
Payroll. Integration scenarios towards 3rd party systems utilizing the old direct deposits APIs might no
longer work. Please check in advance and inform customers that they might need to migrate existing
3rd party integration scenarios to the new APIs, for example, compound employee API or OData API.] —
requires Employee Central V2 (Event Reason Derivation), Enable Generic Objects, Effective Dated Data
Platform, Employee Profile data audit and Enable the Attachment Manager
Note
For an existing customer that is using the old Payment Information or Direct Deposit, if you want to enable
the new Payment Information, please use the Upgrade Center instead. For more information, see the
Implementing and Configuring Payment Information in Employee Central guide on the SAP Help Portal.
8. Optional: If you want to hide the user name in the value help in the system, select the following checkbox:
Here is an overview of the attachment options that can be selected for Employee Central.
Context
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.
Procedure
1. In Provisioning, on the Company Settings page, scroll to the section Document Attachment.
2. Specify the attachment settings as required by the customer.
If the customer requirements are not known at this time, make the following settings:
Attachment Setting
Create a super admin user in the Provisioning application, for a specific customer instance, so that you can access
the system and grant necessary permissions to other users.
Prerequisites
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.
Procedure
1. Log into Provisioning and select the company instance you wish to access.
Setting Description
Admin Username Determines both Username and User ID of the super admin
user.
Admin Password Password with which super admin can access your system.
Admin First Name First name of super admin as it appears in the system.
Admin Last Name Last name of super admin as it appears in the system.
Use PWD to log in to SAP SuccessFactors Once it is checked, the newly created super admin can log
into the system using username and password.
Note
This ONLY applies to the instance that has enabled Par-
tial Organization SSO.
Confirmation of customer approval Provisioning user must check a box confirming that they
have received approval from the affected customer for the
creation of a super admin user account.
Note
As a Provisioning user, it is your responsibility to obtain
this approval before creating a super admin. You cannot
proceed without confirming that you have done so.
Customer Email Address Customer email address that receives notification when the
super admin account is created.
Note
This should be the email address of one person who
provided the customer approval. You can only send noti-
fication to one address.
Note
You can only proceed to create a super admin if you have provided all of the required information. If not,
this action is disabled.
Results
The super admin user account is created and the customer is notified at the email address provided.
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.
For more information about data models, refer to the SAP SuccessFactors Data Model Reference Guide.
For more information about fields in the data model, refer to the Data Object Tables in Employee Central.
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.
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.
You need to import the data into the system using different methods and in a specific order. The import methods
are as follows:
• You update legacy 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.
You can use the Check Tool to find any inconsistencies in your associations. Any fix would result in the update to
your data in Employee Central. We recommend selecting checks available under the following sections:
• System Health Tab Employee Central Core Invalid Effective End Date for FO/GO Area
• System Health Tab Employee Central Core Object Relationship Area
• System Health Tab Work Structure Rules
Related Information
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. When
creating a new record. The external code field is now read-only. However, when editing an existing record
the external code field becomes editable. if the user changes the external code and saves the record the
external code will be updated for all the records.
• 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
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.
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.
Configuring the Object Provisioning Corporate Data Model Admin Center Configure Object
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
Note
You need the Manage Organization,
Pay and Job Structures permission to
access the Manage Organization, Pay
and Job Structures user interface.
Importing Object Values/Data Admin Center Import Foundation Admin Center Import and Export
Data Data
Exporting Object Values/Data Ad Hoc Report Report Definition Admin Center Import and Export
Mass Deleting Object Values/Data Manual deletion only using Admin Admin Center Import and Export
Alternatively, you can import the founda- which data should be deleted upon im-
“Active” to “Inactive”
Note
You need the Access Manage
Organization, Pay and Job Structures
page permission to acces the
Manage Organization, Pay and Job
Structures user interface.
Permissions for the objects and data Manage Foundation Object Types MDF Foundation Objects
Custom Fields You can only have 20 of each type: There is no limit to the number of custom
fields you can create for MDF objects.
• String
In addition to the data types supported
• Date
for 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 updating 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
Related Information
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:
• Deleting or deactivating a foundation object leads to inconsistencies in employee data. If an object references
that foundation object, the object reference breaks. Please check relationships to other objects and to
employee data before deleting or deactivating a foundation object.
• 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
• check Admin Alerts for errors after deactivating the foundation object .
This allows for a proper audit of the data to be kept 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
Some legacy Foundation Objects available in the Admin Center Manage Organization, Pay, and Job
Structures do not support forward propagation, whereas others do.
Department Yes
Division Yes
Dynamic Role No
Event Reason No
Frequency No
Geozone No
Location No
Location Group No
Pay Component No
Pay Grade No
Pay Range No
Workflow No
The system runs validations for changed data in foundation objects, generic objects, associations, and picklists.
This improves data consistency and reduces the workload for admins.
Whenever you create and change HRIS-based employee data, the system checks the following for foundation
objects, generic objects, associations, and picklists:
Note
Since Cost Center objects are imported into Employee Central from other systems, the system allows a
new record to be added that is before creation date.
• For picklists, the system checks whether the value is active. The system does not consider the effective date of
the data change, but does consider the validity of the picklist value always as of the current date.
• For picklists, the system checks whether the fields configured as picklist are of type 'String'.'
• Check Tool System Health Tab Employee Central Core Association Area
• Check Tool System Health Tab Employee Central Core Invalid Effective End Date for FO/GO Area
Here are the requirements for the use of legacy foundation objects.
• In Provisioning,
• Enable Employee Central Foundation Objects
• Activate the Enable Translation of Employee Central Foundation Objects setting
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.
• 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.
Remember
To use foundation objects without Employee Central, you must configure foundation objects, for example,
Location, in the Corporate Data Model.
Related Information
For example, a business unit consists of several departments, so you would create an association of one business
unit to many departments — a ONE-TO-MANY relationship. Whereas a location can only have one geozone
associated with it — this is a ONE—TO—ONE association. The type of association restricts what the user can
display or enter in Employee Central — for a ONE_TO_ONE association from location to geozone, for example, the
user can enter exactly one geozone for a location on the UI.
The standard XML file for the Corporate Data Model already contains some associations. You can add more
ONE_TO_MANY associations, or change the existing associations in the XML file if needed. Each association has a
“driving object” that acts as the basis for the association.
Associations should always be configured to go from the lower-level object (the child object) to the higher-level
object (the parent object). In other words, the association should be placed on the object you expect to be filtered
based on the parent value selected. For example - Location (Child) to Legal Entity (Parent) requires that the
association be placed on the Location object. Following this, in the UI, after selecting the Legal Entity, a filtered list
of Locations will be available, based on the selection made in Legal Entity.
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.
As an example, if we assume 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.
• Check Tool System Health Tab Employee Central Core Invalid Effective End Date for FO/GO Area
• Check Tool Employee Central Core Object Relationship Area
Related Information
Working with Associations, Field Criteria and Value Help [page 78]
In this example of a company’s organization structure, you can see a range of different options for configuring and
customizing the associations to accommodate different hierarchies.
In this example, we can see that there is a ONE-TO-MANY association between the following objects:
We can also see the ONE-TO-ONE associations between the following objects:
Should the standard Foundation Objects not account for the number of organization units that a company needs to
define their org hierarchy, additional levels can be created through the use of custom MDF Generic Objects. In this
example, we can see the following ONE-TO-MANY associations to custom objects:
• Area to Division
• Section to Department
An additional option available in constructing the Foundation Object associations is to build an association against
the same object. For example, if a larger department is divided into sub-departments, a parent-child association
can be created against the department object. The benefit of constructing this parent-child relationship is that it
does not drive any restrictions when drilling down the hierarchy. This is possible for all objects except Legal Entity,
since this must stay at the top of the hierarchy.
This table lists several examples of associations to show the relationships between foundation objects.
Note
References to Department, Division, Legal Entity and Business Unit in these examples now point to the MDF
foundation objects.
Business Unit Job Code ONE_TO_MANY A job code can be used across
several business units. (Busi-
ness Unit is the driving ob-
ject.)
Pay Component Group Pay Component ONE_TO_MANY A pay component group can
contain multiple pay compo-
nents.
You need to fully understand the relationships between foundation objects in order to define them correctly in the
system.
Associations from Legacy FOs to other Legacy FOs are defined in the Corporate Data Model, whereas associations
from MDF FOs to Legacy FOs or to other MDF FOs (or GOs) are defined in MDF (Configure Object Definitions). For
associations from an MDF FO to a Legacy FO, associations cannot be directly defined. Instead, a wrapper MDF FO is
used. A wrapper is not required for associations to custom FOs as these are considered to be GOs.
For more details of how to configure associations based on the object destination, refer to the Working with
Associations, Field Criteria and Value Help [page 78] topic.
You can also add an association to a field that is not part of the same entitiy; for example, to filter the pay
components in Compensation Information based on Job Information criteria. To do this, you have to add a prefix of
the corresponding object as destination field value.
Here, the pay component that is part of the payComponentRecurring is filtered based on the payScaleGroup field
from the Job Information. To achieve this, you add the prefix jobInfo. to the destination field value.
Note
You can only use IDs of effective-dated HRIS elements as prefixes, for example, jobInfo, compInfo, or
personalInfo as prefixes.
The next few sections describe how you can get associations to work for the following scenarios.
The steps also describe optional configuration that is required only if you have position management enabled and
need associations to work on the position and the employee record.
Disable the filter for custom fields of type Foundation Object in the system.
Context
Custom fields using the attribute type="foundationObject" take over the association settings of the corresponding
foundation object. For example, if you have a custom field of type="location", and you have associated the location
FO with the legal entity FO, the custom field would only show a restricted list of values (where the legal entity
defines which locations are displayed). However, if you prefer custom fields with type="foundationObject" to show
all the FOs available in the system, you need to check the following setting:
Procedure
Context
To understand the steps involved, consider the following example of the Generic Object cust_MarketCategory
being filtered by the Generic Object cust_FunctionalArea.
Context
This allows you to attach the parent Generic Object doing the filtering (cust_FunctionalArea) to the child Generic
Object being filtered (cust_jobMarketCategory). The steps are as follows:
Procedure
1. Create the Generic Objects that will do the filtering and be filtered.
Results
Attach the relevant Parent Generic Object values to the Foundation Object.
Context
This sets up which parent Generic Object values filter the child Generic object values.
Procedure
In the Business Configuration UI (BCUI), define field criteria for the Generic Object field being filtered.
Context
This tells the system for this field what Generic Object is doing the filtering and the field that references it on Job
Information.
Procedure
The field name of the internal code on the parent Generic Object can be derived from the <internalCode>
database field name found in the Configure Object Definition page.
Note
The field-criteria attribute is not supported for the country/region-specific data models.
Define field criteria for the child Generic Object being filtered.
Context
This step is to be done only when Position Management is enabled. This tells the system for this field what
Generic Object is doing the filtering and the field that references it on the Position object.
Note
Refer to the previous step for information on how to derive the internal code.
Procedure
It is possible to use one generic object as a filter for another using field criteria.
Context
Context
This allows you to attach the parent Generic Object doing the filtering to the child Generic Object being filtered.
Procedure
For the new field, ensure that Data Type Generic Object is set.
5. Select Details. Update the Valid Value Source to be the technical name of the parent field.
Attach the relevant Parent Generic Object values to the Foundation Object.
Context
This sets up which parent Generic Object values filter the child Generic object values.
Procedure
In the Business Configuraiton UI (BCUI), add the field criteria for the field to be filtered.
Context
This tells the system for this field what Generic Object is doing the filtering and the field that references it on Job
Information.
Procedure
Context
To understand the steps involved, consider the following example where Legal Entity (Generic Object) is required to
filter Location (Foundation Object) on Job Information and Position.
In the Corporate Data Model, add an association to the Generic Object in the Foundation object element that is to
be the subject of filtering.
Context
1. Create the Generic Objects that will do the filtering and be filtered.
Attach the relevant parent Generic Object values to the Foundation Object.
Context
This sets up Generic Object values that will filter the Foundation Object values.
Procedure
Define field criteria for the foundation object field being filtered.
Context
This specifies which Generic Object is doing the filtering and the field that references it on Job Information.
Procedure
The field-criteria attribute is currently not supported for the country/region-specific data models.
Define field criteria on the Foundation Object that is to be the subject of the filtering field on the Position Object.
Context
This step is to be done when the object doing the filtering is an MDF Object. This tells the system for this field which
Generic Object is doing the filtering and the field that references it on Position.
Procedure
It is possible to use one foundation object as a filter for another foundation object.
To understand the steps involved, consider an example where: Location Group (Foundation Object) is required to
filter Location (Foundation Object) on Job Information and Position.
In the Corporate Data Model, add an association to the Foundation Object to be filtered.
Context
Procedure
1. Create the Generic Objects that will do the filtering and be filtered.
Attach the relevant parent Foundation Object values to the Foundation Object.
Context
This attaches the relevant parent Foundation Object values to the child Foundation Object and allows you to specify
which parent values filter which child values.
Procedure
Define field criteria for the Foundation Object field being filtered (in this case, location).
This step is to be done for Job Information in the Business Configuration UI. For the Position object, see the next
step.
Here, we are using a custom field in the field criteria, <custom-string18>, to refer to <locationGroup> since
locationGroup is not a standard field of Job Information.
Define field criteria for the Foundation Object that is to be the subject of the filtering field on the Position Object.
Context
This step is to be done when the object doing the filtering is an MDF Object. We just defined the field criteria for the
FO that is the subject of filtering for Job Information. We will now do the same for the Position Object. This tells the
system for this field which Generic Object is doing the filtering and the field that references it on Position.
Procedure
Note
For the example, we assume that you have already created a custom field by the name of
cust_locationGroup which is of type Foundation Object.
Context
To understand the steps involved, consider the following example where the Foundation Object Pay Grade is
required to filter the Generic Object Grade Level on Job Information and Position.
Associate the wrapper to the child generic object, which means the field that should have its values filtered.
Context
Procedure
Associate values to be filtered to the values doing the filtering on the child Generic Object to be filtered.
Context
With this, you configure the child values (Generic Object) that can be selected for specified parent values
(Foundation Object).
Procedure
In the Business Configuration UI, define the field criteria for the Generic Object field being filtered.
Context
The field-criteria attribute is currently not supported for the country/region-specific data models.
Define field criteria for the Generic Object field being filtered on the Position Generic Object.
Context
Procedure
Effective dating means that information records capture time as part of the data that is stored in SAP
SuccessFactors and the time element can be edited.
In the application, the HRIS fields “start-date” and “end-date” are used for effective dating. The “start-date” is
usually uppermost on the UI. This is where the user has to enter the date from which the changes are effective.
Whether an HRIS element is effective-dated or not is defined by the system.
The HRIS field “end-date” does not appear on the UI but is used for reporting purposes. For example, if you change
an effective-dated field such as Pay Grade and set the date when the change should be effective to 01/01/2015, the
system records 12/31/2014 as the end date in the background. If you run a report on the pay grade in the time from
01/01/2014 until 12/31/2014, the pay grade value that was valid in that time frame will be shown.
The system does not change the stored data. Instead, it creates a new row of data to track the new values from the
effective date of the change, and continues to store the values that were effective before the change.
By default, the end date does not appear on the UI for MDF Foundation Objects, but it is possible to change
the visibility of this field. To preserve the system functionality that automatically sets the end date, it is highly
recommended to either leave the end-date field as hidden, or set to read-only. It is not recommended to manually
set the end-date of Foundation Objects.
Change a Foundation Object by inserting a new record to update the Foundation Object. You should never edit the
object directly.
Context
Foundation objects are effective-dated in the same way as employee data. When updating an employee’s job
information, the process typically involves inserting a new record, effective on a specific date, updating the
employee attributes, and then saving the record. The same applies to Foundation Objects.
This is an example of how you can update the name of a Location in your system.
Procedure
Ensure that the date you set is either today’s date or a future-dated date. A best practice is to set these
changes to happen over a weekend, when Job Information changes are not likely to be made.
It is important to know that if you set the date in the past, this could affect Job Information records that
are using the older Location value but the effective start date of that Job Information record is after the
Effective Start Date of the Location FO’s changes.
Next Steps
Once the Foundation Object has been updated, you will also need to add a new Job Information record to all
employees that should have this updated Location. For example, if you updated the location’s name from “Chicago”
to “Chicago, USA”, the system will not automatically propagate that change to Job Information, so you will need
to update all users who have “Chicago” set as their Location in Job Information. This is because FO’s are effective
dated, and so are Job Information records.
Note
If the employee’s job information is not updated, you will still see the label update on view of the employee’s job
information. This is only a display feature. A new record should still be inserted in the Job Information of the
user for the change to be reflected in Job History and synced to Employee Profile.
You can update the employee’s Location manually using the UI, using the Mass Changes tool, or by importing a new
record for the impacted employees.
Another example is the updating of a Business Address. For example, the company has moved their office at the
location Chicago, from one address to a new address, and this address is shown in Employee Central or synced to
Employee Profile. You would need to follow this full process to force the system to update the employee’s Employee
Central data.
There are different types of foundation objects. You can use one of these types, called organization objects,
to define how your business is structured. This information states where in the organization the employee and
position belongs, as well as where they are physically.
Legal Entity MDF The legal entity table stores all the legal
entities of a company. No legal entity
can cover more than one country, so the
country in the legal entity determines the
country of employees assigned to the le-
gal entity.
Note
For customers using the Team Sum-
mary tile on the Home Page, the
business address must also be con-
figured so that an accurate location
can be displayed.
Note
By default, Department, Division, and Location values are synced from Employee Central to Employee Profile
for downstream talent processes. The values contained in these fields will also display in dashboards and UI
views (such as the org chart and People Profile). For more information, see the Human Resource Information
System (HRIS) Synchronization [page 255] topics.
Some of the foundation objects (FO) can be used to handle job-related issues. This information states what they do
in the organization.
Some of the foundation objects (FO) can be used to handle pay-related issues. This information states what and
how they are paid.
Pay Range Legacy Pay Range is primarily used for the cal-
culation of Compa Ratio and Range Pen-
etration. The system stores minimum,
median, and maximum points of a pay
range.
Overview
In addition to the organization objects, job-related objects, and pay-related objects, you can also use the following
(most are related to workflows):
Some previously legacy Foundation Objects (FO) were migrated to the Metadata Framework (MDF), so they are
now called MDF Foundation Objects (but sometimes also referred to as Generic Objects - GOs).
• Cost Center
• Department
• Division
• Business Unit
• Legal Entity
• Legal Entity Local
• Job Function
• Pay Group
• Pay Calendar
• Job Classification
• Job Classification Local
Use the Configure Object Definitions page will be used to configure these MDF Foundation Objects and the Manage
Data page will be used to manage these MDF Foundation Objects.
The currency and country fields of the Legal Entity FO are now GOs. Any references to these fields will now refer to
the corresponding GO.
Related Information
You can add terms at the object under which they can be found in the search.
Procedure
Note that while the search criteria will appear blank, the externalCode and name fields are already implicitly
defined as part of the search criteria. These are default search keys and do not need to be manually configured.
In the empty text box, specify the name of any other field you would like to make searchable. You can choose
from the list of fields mentioned in the Fields section.
Note
Default search-criteria for the fields externalCode and name are defined by default and do not need to be
manually configured.
For the fields of type GO and Picklist, the field needs to be added in the search criteria. For example, if
department is a field pointing to a Department GO, then department.name would need to be added to the
search criteria.
With the migration of Foundation Objects (FOs) to MDF Foundation Objects (GOs), the HRIS elements of the
migrated objects are no longer available in the Corporate Data Model XML as an association destination. Instead,
associations from the GOs to another FO or GO are now defined in MDF. For associations from a GO to a FO,
associations cannot be directly defined. Instead, a wrapper GO is used. A wrapper is not required for associations
to custom FOs as these are considered to be GOs.
The table below describes the different associations possible. Here mFO refers to the MDF FO; cGO refers to a
custom FO; FO refers to Foundation Objects defined in the Corporate Data Model.
mFO – FO Corporate Data Model mGO – FO using Metadata Framework Here you cannot
WrapperGO
have a direct
association. Therefore,
a WrapperGO is created
during migration. The
wrapper instances are
created and association
data is migrated.
cGO – mFO using Metadata Framework cGO – mGO using Metadata Framework The data type of
custom WrapperGO custom WrapperGO the custom wrapper’s
external code is set to
GO.
FO – mFO Corporate Data Model FO – mGO Corporate Data Model Here FO is changed to
GO in the association
definition.
mFO – mFO Corporate Data Model mGO – mGO Metadata Framework Defined in Configure
Object Definitions page.
The association type is
valid-when.
mGO - mFO using Metadata Framework mGO - mGO Metadata Framework The association using
wrapper GO the wrapper GO is
replaced by a direct
association between
the two GOs .
Example
Association from FO costCenter to an FO or GO defined in the Corporate Data Model before the migration:
<hris-associations>
<association id="id" multiplicity="ONE_TO_MANY" destination-entity="location"
required="false"/>
<association id="id" multiplicity="ONE_TO_MANY" destination-
entity="cust_GOSubDivision"
required="false"/>
</hris-associations>
After the migration, the association to FO Location is migrated to the MDF association with name
cust_toFOWLocation and destination object type FOWLocation. Here, FOWLocation is the wrapper GO for
the FO Location. The association to the wrapper GO is modeled as Type "Composite" and Multiplicity "One To
Many". The association to the custom FO Sub Division (GOSubDivision) will be modeled as an association of
Type "Valid When" and Multiplicity "One To Many".
Example
Association from FO to FO costCenter defined in Corporate Data Model before the migration:
<hris-associations>
<association id="id" multiplicity="ONE_TO_ONE" destination-entity="geozone"
required="false"/>
<association id="id" multiplicity="ONE_TO_MANY" destination-entity="company"
required="false" />
<association id="id" multiplicity="ONE_TO_MANY" destination-entity="costCenter"
required="false" />
</hris-associations>
Association from FO to GO CostCenter defined in the Corporate Data Model after the migration:
<hris-associations>
<association id="id" multiplicity="ONE_TO_ONE" destination-entity="geozone"
required="false" />
<association id="id" multiplicity="ONE_TO_MANY" destination-
entity="LegalEntity" required="false" />
<association id="id" multiplicity="ONE_TO_MANY" destination-
entity="CostCenter" required="false" />
</hris-associations>
If you have implemented a GO with composite association to cost center, you must define an association from
the GO to costCenter FO. For that you must implement a wrapper GO as proxy for the costCenter FO. After
the migration, the wrapper GO will be the proxy for the GO CostCenter. If the wrapper GO is not used for other
purposes, we recommend that you change the association definition at the GO and have GO CostCenter as the
association destination instead of the wrapper GO.
Before the migration, cost center was an FO, and it is now a GO. If you want to update the GO CostCenter
assignments, you can use the Manage Data page.
All the filtering on Job Information and Position works as before. Now you have a new element called Field Criteria:
Earlier, the value help on custom-defined fields would automatically filter out associated Generic Objects. After
migration, the field criteria can be used to change the value help behavior as to which field shall be filtered as child
field.
You can restrict the value list of the GO source depending on the GO/FO destination selection, while associating GO
source to a GO/FO destination. If FO is the association destination, you perform this task using a GO Wrapper.
If you want to filter an FO-related field by a GO-related field, you define a One-to-Many association at the FO HRIS
element type in the Corporate Data Model and enter the GO type as the association destination.
You must add field criteria in Job Information at the field that is filtered. Earlier, the element Field Criteria was not
required, and the parent/child field relationship was reversed.
Example
On Job Information, the cost center field is filtered by business unit and a custom field custom-string2
referring to GO cust_GCC:
Example
For the migrated FOs Business Unit, Division, Department and Legal Entity, FO Wrapper types are now deprecated.
You must not use them anymore. If Cost Center has an association to an FO Wrapper, it will be migrated to the
mapped GO and association type will be changed to valid-when. This is applicable for associations to Business Unit,
Division, Department and Legal Entity only.
Example
If the Department is restricted, the field criteria is always defined at the restricted field. The field criteria in this
case will be as follows:
The source field name must be in the format <association name>.internalId and destinationFieldValue will be
in the format <filteringFieldID>. The destination field will be the field name in the Succession Data Model.
For example, if the business unit filters the division, the field criteria defined on the division field looks as
follows:
<field-criteria sourceFieldName="cust_toBusinessUnit.internalId"
destinationFieldValue="business-unit" >
Example
If there is an association from Business Unit to Location, a wrapper will be required for the association.
Additionally, if there is an association from Business Unit to Cost Center, it will be a direct association since this
is an mGO - mGO association:
<field-criteria sourceFieldName="cust_toFOWLocation.internalId"
destinationFieldValue="location" >
You can also add an association to a field that is not part of the same block; for example, to filter the pay
components on the job information block. To do this, you have to add a prefix of the corresponding object as
destination field value as in this example:
Sample Code
<hris-element id="payComponentRecurring">
<label>Compensation</label>
<hris-field id="pay-component" visibility="both" required="true">
<label>Pay Component</label>
<field-criteria destinationFieldValue="jobInfo.payScaleGroup"
sourceFieldName="PayScaleGroup"/>
</hris-field>
...
Here, the pay component which is part of the payComponentRecurring block is filtered based on the field
payScaleGroup from the job information block. To achieve this, you add the prefix jobInfo. to the destination
field value.
Note
You can only IDs of effective-dated HRIS elements as prefixes, for example, jobInfo, compInfo, or personalInfo
as prefixes.
Related Information
You can add the legal entity field to the cost center foundation object to create associations between these objects.
This is for new customers from 2020.
Prerequisites
You have set the visibility of the Legal Entity field to Yes in the object definition. By default the visibility of the legal
entity field is set to No, but it must be set to Yes to use this field.
Context
There is no need to create a custom legal entity field or a custom association to the legal entity object within cost
center.
Procedure
This creates the association between the specific cost center and the specific legal entity.
Results
In the Job Information in the employee profile, the cost center objects displayed in the dropdown list are filtered by
the selected legal entity. The user can view and select only the cost center objects that are assigned to the selected
legal entity using the new legal entity field in the cost center object.
You can repeat these steps for the Position object as well.
HRIS elements with fields referring to countries/regions or currencies are based on the Country/Region and
Currency GOs. With these GOs, you can now add new countries/regions and currencies, set them to 'inactive' as
well as create associations.
Context
The currencies from GO Currency are now visible in places where currencies are used (for example,
PayComponent).
You can import a full set of countries/regions as well as currencies (includes translations) through predelivered
files available in the Software Download Center .
Procedure
Likewise, you can manage the currency using this page as well. Instead of country/region, select currency and
proceed. Select the View Translations icon next to the currency name to get a list currency name translations.
6. To remove a currency from the drop-down list, enter the currency name. From History, select Take Action
Make Correction .
7. Change the status of the currency to Inactive:
8. Save your changes and repeat for all currencies and countries/regions.
If you want to add a new country/region and the fields related to it, you need to create a new MDF object for those
country/region-specific fields. Then you have to assign the new object as a child object to LegalEntity.
Create a new MDF object for the country/region-specific fields needed for your company.
Procedure
Results
Assign the new country object to Legal Entity to associate the two objects in the system.
Procedure
If you want to add a new country/region and the fields related to it for job classification, you need to create a new
MDF object for those country/region-specific fields. Then you have to assign the new object as a child object to
JobClassificationCountry.
Create a new MDF object for the country/region-specific fields needed for your company.
Procedure
Results
Assign the new country/region object to JobClassificationCountry to associate the two objects in the system.
Procedure
This example shows you how you can configure a field. For this example, we'll be configuring the standard field
glStatementCode as a picklist.
Procedure
The Configure Object Definitions page now displays the current configuration for the GO CostCenter.
6. Select Done.
7. Now, add a custom field of data type picklist. To do so, scroll to end of the fields list and select Details against
the cust_ field.
When the standard Legacy and MDF Foundation Objects are not enough to structure an organization’s business, it
may be necessary to build custom objects to add additional information and attributes. These custom objects are
referred to as Generic Objects. You use generic objects for information and settings relating to the people working
in the company.
Generic objects are created using the Metadata Framework. This guide concentrates on the use of generic
objects in the context of Employee Central. For more information about the Metadata Framework, refer to the
Implementing the Metadata Framework guide.
The key difference between Foundation Objects (both Legacy and MDF) and Generic Objects is that Foundation
Objects are standard, pre-delivered, and preconfigured objects that are used to structure a company’s
Organization, Job, and Pay areas. All Foundation Objects were originally Legacy Foundation Objects, created and
updated using the Corporate Data Model. As the Foundation Objects are slowly migrating to MDF, we are seeing the
conversion from Legacy to MDF Foundation Objects. As Employee Central continues to expand, all future objects
are being developed on the Metadata Framework platform. Objects that are created on the Metadata Framework
are known as Generic Objects. In fact, all MDF Foundation Objects are Generic Objects, as they are built on the
Metadata Framework platform, and it is common to see the term “Custom Foundation Object” and “Generic
Object” used in place of “MDF Foundation Object”.
Related Information
In addition to the standard Foundation Objects available, as Employee Central continues to expand, additional
objects are available to help organizations run their businesses effectively and efficiently.
Here are some examples of standard Generic Objects that are used to configure and support Employee Central
functionality.
• Country/Region
• Pay Calendar
• Pay Scale
• Position
Features
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.
• You have to set permissions for generic objects, which determine who can use them and what they can do with
them.
• In the case of field IDs, you can decide whether each field appears in your UI and, if so, whether it is for display
only or whether users can change or edit the information in it.
Some customers may require additional foundation objects to be created to provide a holistic representation of
their organization in Employee Central. For example, organizations with more levels in their organizational hierarchy
may require the addition of a “Sub-Department”.
Context
Customers transitioning from other SAP products may require the use of Generic Objects to store their “Personnel
Area” and “Personnel Sub-Area” attributes, rather than using the standard “Employee Class” and “Employment
Type” picklists.
Procedure
Note
For information on how to create a generic object, refer to the Implementing the Metadata Framework guide
on the SAP Help Portal.
2. Assign the Generic Object to the Corporate Data Model or Succession Data Model.
Download the Succession Data Model or Corporate Data Model from Provisioning and open it in an XML editor.
a. If assigning the Generic Object to a Legacy Foundation Object
1. Download the Succession Data Model or Corporate Data Model from Provisioning and open it in an
XML editor.
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.
2. 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.
Related Information
In this example, we configure a workflow for the Location foundation object. The workflow will be triggered when a
new Location is created or an existing Location is edited.
For more information on how to configure workflows, see the Employee Central Workflows: Implementation
and Administration guide on the SAP Help Portal.
2. Create a business rule that can trigger the workflow.
The base object must be the foundation object for which the workflow should be triggered. The parameter
code FOWorkflow and the object FO Workflow must also be included.
Allow the admin access to the Company System and Logo Settings link in the Admin Center, which has many
Employee Central relevant settings.
Prerequisites
Ensure that the permission for Administrator Permission Manage System Properties Company System and
Logo Settings is enabled.
Procedure
• Enable Address Validations: validate if postal codes are in the correct format for your country or region
whenever you add or edit addresses in People Profile or import addresses
• Enable National ID Validations
• Enable Bank Account Validations
• Enable Payment Information Validations
3. Optional: If you use contingent workers, select the Enable target group based filtering for Worker fields
checkbox.
This means that, if checked, then the values in the dropdown list for Worker fields will be based on the target
group settings assigned in permissions. If not checked, then all users will be available in the dropdown list.
4. Save your settings.
Prerequisites
You must have the required permissions to view the page: Permission Settings Manage System Properties
Employee Central Feature Settings
Context
Manage the areas of Employee Central using the Admin Center, for example:
Procedure
Note
If you are unable to see this page, it is recommended that you log out and log back in to the Admin Center.
Doing so will trigger the changes in permission immediately. You should then be able to search for the
Manage Employee Central Settings page.
Configure the Internal Job History on the legacy People Profile to view the internal career history of an employee.
This history can be shared with a broader audience with the company.
Prerequisites
• Ensure that you have permissions to use the admin tool for legacy People Profile from Administrator
Permissions Manage System Properties Configure People Profile .
• Create a rule using the Display Internal Job History rule scenario. You do this by going to Admin Center
Configure Business Rules Employee Central Core Display Internal Job History .
This rule scenario only supports Job Information as the base object. In the rule, you only add the If condition,
for example, to show job changes in the People Profile. You can’t change the Set condition in the rule, and it is
not shown in the rule.
Here is an example for a rule configured for an event reason for promotion. Rules can be configured and
customized based on customer requirements.
• Ensure that you have permissions for this card from User Permissions Employee Widgets Internal Job
History .
• Ensure that you have permissions to view Job Information records from User Permissions Employee
Central Effective Dated Entities Job Information .
Context
This is a read-only card, which is really a filtered version of the job history for an employee.
This is a double card, meaning it needs 2 spaces. The system does not allow you to place it in a single space.
4. Select the card to edit it's properties.
5. Edit the card.
a. Enter the title and description.
b. Optional: Select the option Show the description below the card title.
If you don't select the option, users access the description through the Help in the card.
c. Select the Job Information fields from the dropdown that you would like to have in the card.
Note
The fields shown in the dropdown list are based on the configured fields of the Succession Data Model
as well as the Country/Region-Specific Succession Data Model.
Note
Transient fields, for example, time in position, time in job, time in company, are not supported.
Note
Any fields with the label NA do not show data in the card.
d. Select the rule you created using the Display Internal Job History rule scenario from the Rules dropdown.
Note
Only the Display Internal Job History rule scenario rules are shown. If no rule is configured, then the
Rule dropdown will not be seen.
Results
To view the Internal Job History, navigate to the legacy People Profile for the employee whose history you would like
to see. The new card appears on the Profile. You will see the filtered version of the job history for an employee based
on the rule scenario configured and the Job Information fields selected.
Related Information
Set up the currency exchange rate to show pay component group values as well as to be able to calculate Compa
Ratio/Range Penetration.
Context
Procedure
Permission Description
Metadata Framework Import Permission on Metadata Allows users to import the MDF object into the system.
Framework
MDF Foundation Objects Currency Exchange Rate Allows users to see and use the Currency Exchange Rate
MDF object.
If you are a new customer, check whether there is already an existing picklist with ID =
"CurrencyExchangeRateType" and a picklist value = "DEFAULT". If it is not available, create the picklist and
the default value.
Only exchange rates with the default exchange rate type, DEFAULT, are used in Employee Central
currency conversion.
For mass updates of currency exchange rates, you can use the standard import and export UI. For more
information, refer to Importing MDF Data topic in the Implementing the Metadata Framework (MDF) guide.
d. Save any changes.
The system automatically assigns user IDs based on a database sequence to new hires and rehires including fixed
term contract, global assignments, and concurrent employment once they are created in the system.
Optionally, you can configure business rules using the Generate Employee ID For Hire/Rehire rule scenario to
generate user IDs during the hire (including fixed-term contract, global assignment or concurrent employment)
and rehire with new employment process.
If you have configured rules, the rules take precedence over the database sequence.
The database sequence helps to avoid application errors caused by duplicate employee IDs, which can happen in
the following cases:
Let's say a company with 10,000 employees acquires another company. When merging the employees into one
company, 5,000 new employees are added with a CSV file import to the system. You would then need to set the ID
for the next person that is hired to be the current number of employees plus 1, so you would enter 15,001 in the
Next Employee ID Assigned field.
Note
We recommend selecting a number that does not start with a leading zero. For example, for a company with
10,000 employees, you could start with the following number “100000”, which would give a capacity of 1 million
employees.
Note
If Position Management is active in your system, remember to update the Employee Number in this section as
well as the Position Sequence Number during data migration.
In certain cases, gaps in the row of assigned IDs cannot be avoided, such as aborted hires. After enabling the
sequence, you may get the error with the text “Unable to generate unique Employee ID. Sequence needs to be
updated. Please contact your Admin.”. This error occurs because the next number provided by database sequence
is already used for other employees. The system has a set number of attempts to find a valid number, but if it
can't find one, then you will get the error. To resolve this issue, you can update the sequence to Maximum Number
Already Used as Employee ID for Existing Employees value. To do this, enter the Maximum Number Already Used as
Employee ID for Existing Employees in the field Next Employee ID Assigned and save the changes.
To start the sequence with different number, update the number in the field Next Employee ID Assigned and save
the changes.
Related Information
You can create multiple sequence ranges for customers who want to place certain types of employees in those
ranges.
Procedure
Next Steps
You can then create a business rule with an If/Else condition to call the respective sequence based on the employee
category.
Related Information
Learn about Events in SAP SuccessFactors Employee Central and how they can be used.
Events are predelivered by SAP SuccessFactors. You can change the labels of these events as needed. Events are
occurrences that span the various stages of an employee’s lifecycle from hire to retirement. The event sets the user
status. Technically, events are defined in picklists. This is a sample list of events with their unique external codes
delivered by SAP SuccessFactors:
Note
Refer to the Restrictions for the Furlough and Suspension Events section for more information.
• Hire (H)
• Leave of Absence (10)
• Job Reclassification (9)
• Pay Rate Change (12)
• Position Change (13)
Note
• Suspension (7)
Note
Refer to the Restrictions for the Furlough and Suspension Events section for more information.
• Termination (26)
• Transfer (6)
• Add Global Assignment (GA)
• End Global Assignment (EGA)
• Obsolete Global Assignment (OGA)
• Start Pension Payout (SPP)
• End Pension Payout (EPP)
• Discard Pension Payout (OPP)
The hire and rehire events set the Employment Status as active and that is the reason that the status is kept as
active where as the transfer/promotion/data change events get the status of the employment from the previous
record and set it accordingly.
Furlough
Job Information records with the Furlough event can be created in the History UI and Job (Information) History
imports. There is no dedicated UI transaction available.
System Behavior
Job Information records with the Suspension event can be created in the History UI and Job (Information) History
imports. There is no dedicated UI transaction available.
System Behavior
You can't create new records or edit existing records for specific Hire, Rehire, and Termination events using the Job
Information History UI. Instead, these transactions must be made using the Take Action menu for such events (or
the Add New Employee page for Hire or Rehire events). This ensures that the status of the employee, along with
their employment and/or termination details, is updated correctly. A full purge import can also be used to make
these changes.
• Hire (H)
• Termination (26)
• Rehire (R)
• Leave of Absence (10)
• Return to Work (22)
• No Show (NS)
• Add Global Assignment (GA)
• Away on Global Assignment (AGA)
• Obsolete (OGA)
• Back from Global Assignment (BGA)
• End Global Assignment (EGA)
• Start Pension Payout (SPP)
• End Pension Payout (EPP)
• Discard Pension Payout (OPP)
• Surviving Spouse Start (SSS)
• Surviving Spouse End (ESS)
• Work Order End (ECWK)
You can't delete existing records for specific Hire, Rehire, and Termination events using the Job Information History
UI. Here is a list of affected events:
The system allows admins to add a Data Change event with a custom event reason to changes the employee status
to either Terminated or Retired.
Admins can change the employee status in the Job Information History from Retired to Terminated or from
Terminated to Retired by adding a new record with the Data Change event and a corresponding event reason.
The event reason must have the employee status configured to either Terminated or Retired; for example, the
Retirement with Pension Payout custom event reason has the Retired employee status or a custom event reason
for Death of Pensioner has the Terminated employee status. Admins cannot make multiple of such changes for the
same day, though.
Note
The Employment Information end date is not updated when adding such records since the event used is a data
change rather than a termination.
Related Information
When the manager or an administrator changes an employee’s data, for example, by increasing the salary or
changing the department information, the reason behind this change is normally that an event has taken place in
For example, the event “Termination” can take place either because the employee’s performance wasn’t sufficient,
or because the employee wanted to change companies. In this example, if the customer wants to differentiate
between the two possibilities, you define two event reasons that you could call “Terminated - Performance Issues”,
or “Terminated - By Employee”.
Technically, event reasons are foundation objects. This means that the administrator can create event reasons in
the Admin Center Manage Organization, Pay and Job Structures screen or by mass uploading data using a
CSV file in the Admin Center Import Foundation Data .
Event reasons are mandatory in the system. Even if you decide not to create your event reasons for the purpose of
narrowing down the reasons why an event takes place, you have to create an event reason for each event that your
company uses. The event reason sets the employee status.
The event reasons are grouped by event and you cannot change the order or filter this list.
Multiple Event Reasons can be created as needed for any of the events. At a minimum, the administrator should
create an event reason for the following:
• Hire event
• Rehire event
• Termination event
• Changes to Job Information and Compensation Information
Tip
Associate the event reason for such changes to the Data Change event, or you create specific event
reasons for the events Promotion, Transfer, Pay Rate Change, and so on.
• If Leave of Absence is activated, you need to create event reasons for the events Leave of Absence and Return
to Work.
UI Expected Behavior
Change Job and Compensation Information The Event and Event Reason fields aren’t shown on the UI if
you’ve enabled the Enable Business Rules for Event Reason
Derivation setting in Provisioning.
Job History Events and event reasons are displayed in Job History.
Job (Information) History Import If no event reason is provided in the imports template, it can
be derived with onSave business rules. This doesn’t depend
on the Provisioning setting for the Event Reason Derivation. If
no event reason can be derived by a business rule, an error
message is displayed by the system.
Add New Employee All event reasons that have the event "Hire" (external_code
H) and the employee status "Active" (external_code A) are dis-
played in the Add New Employee Wizard.
Add Concurrent Employment All event reasons that have the event "Hire" (external_code
H) and the employee status "Active" (external_code A) are dis-
played in the Event Reason field.
Add Global Assignment All event reasons that have the event "Add Global Assignment"
(external_code GA) and the employee status "Active" (exter-
nal_code A) are displayed in the Event Reason field.
Termination All event reasons that have the event "Termination" (exter-
nal_code 26) and the employee status "Terminated" (exter-
nal_code T) are displayed in the Termination Reason field.
Termination - Transfer of Direct Reports All event reasons that are available in the "Change Job and
Compensation Information" actions are also displayed in the
Transfer Event Reason field of the Termination UI when termi-
nating employees with direct reports.
You have to create event reasons for certain events in the employment cycle and set statuses for when they occur.
Prerequisites
You have edit permissions for event reasons listed in Permission Settings User Permissions Employee Data .
Procedure
Leave the employee status empty for all events that do not have a status based on this list.
Event Status
Hire Active
Probation -
End of Probation -
Data Change -
Assignment -
Transfer -
Suspension Suspended
Job Reclassification -
Job Change -
Demotion -
Promotion -
Additional Job -
Layoff Furlough
Rehire Active
Termination Retired
Terminated
Results
Event reasons can be sorted in alphabetical order by enabling the Sort Picklist Columns Based On Labels option 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.
Next Steps
Once the event reasons are created, you can assign the event reason to a permission role.
Create event reason derivation rules in the system so that the system automatically selects the appropriate event
reason for an event.
Related Information
By default, a cross-entity rule from Compensation Information to Job Information copies the event reason from
the source entity to the target entity. This can lead to problems when the event reason in the Job Information
target record already exists in the user’s Job Information history. With this configuration object in systems with
Centralized services enabled, you can define fallback event reasons that will be used in case the event reason used
in the Compensation Information record would lead to change in the employment status in Job Information.
Context
If a fallback event reason is configured, the system changes the event reason to avoid data inconsistencies. If no
configuration is found or it can't be used, then the user receives an error message.
Example
When the Compensation Information in a hire record is created or changed, the rule creates a new Job
Information record with the same event reason as the Compensation Information record. This would result in
an additional hire record in Job Information. Since a user can only have one hire record in Job Information, this
transaction fails. However, with the new configuration, the event reason is replaced with the defined fallback
event reason and the transaction is successful.
Procedure
Customers that operate in multiple countries/regions often have event reasons that are very specific for a country/
region.
Prerequisites
Context
Customers that operate in multiple countries/regions often have event reasons that are very specific for a country/
region. As the employee is always clearly assigned to one legal entity, and thus to one specific country/region, you
can set up to show only the values relevant for that employee.
Once set up, administrators and managers can use them on all screens that have an event reason field:
• Employment/Personal Information
• Update Employee Records
• History
• Add New Employee
• Large customers operating in multiple countries/region that have several legal entities in one country
• Customers that have a high number of country/region-specific event reasons
Procedure
1. Create an association from the Country/Region object to the Event Reason foundation object.
a. Associate the Country/Region generic object with the wrapper generic object:
1. From the Configure Object Definitions page, choose Object Definition Country/Region .
2. Select Take Action Make Correction .
3. Under Associations, in the Destination Object field, select the wrapper generic object that you have
created:
Note
As of the 1H 2023 release, custom country/region-specific fields in Job Information are not included in
a search where event reasons are filtered by country.
Next Steps
Related Information
This section describes how to set up mobile use for Employee Central users.
Context
You can access certain Employee Central features on your mobile device. Since HR data is private and personal, the
following features help ensure the security of the data:
For a list of all features available, refer to SAP SuccessFactors Mobile Features the guide on the SAP Help Portal.
Note
There are pre-defined links that direct users straight to specific screens inside the mobile app, for example, for
approvals or access to SAP Jam.
Note
To set up mobile devices for Time Off, see the Implementing Employee Central Time Off guide on the SAP Help
Portal.
Procedure
1. Select which mobile functionality should be made available. In your instance, go to the Admin Center
Mobile Settings .
2. Select who will be allowed to use the mobile features and then grant them permission to do so. For more
information, refer to the Using Role-Based Permissions guide available on the SAP Help Portal.
3. Notify those users with permission about the available features using the Notification e-mail. Inform them how
to install and use on their device.
For more information about mobile set-up, refer to the Mobile Deployment Guide on the SAP Help Portal.
To-Do items are a way of notifying users that there are tasks waiting that they need to complete. For example, if you
are a manager, one of your To-Do items might include approving a job change or one-time bonus for one of your
direct reports.
Prerequisites
Features
Once you have performed all the registration, activation, and configuration steps, any Employee Central To Do
items requiring your attention appear in the Open To-Dos screen on your mobile device.
Supported Workflows
The following types of workflows are supported for your mobile device. This means that you can view the activities
related to them, as well as approved or declined.
You can use role-based permissions (RBP) to control access to who sees what with regard to employee
information.
Role-based permissions allow you to grant different levels of read or write access depending on the role of the
employee. For example, an employee is only allowed to read their own compensation information, but an HR Admin
is allowed to edit it. You define these kinds of permissions by managing permission roles.
The cards seen by users in the employee profile are directly related to permissions and roles granted to those
users.
The permission categories are divided in User Permissions and Admin Permissions, which are further subdivided,
for example, Employee Data or Miscellaneous Permissions . Once selected, the list of permissions associated with
this category is displayed on the right side and in some areas, further divided into groups. For example, the HR
Information section contains groupings, for example, for Biographical Information.
Related Information
You can use role-based permissions (RBP) to control access to who sees what with regard to what users can see
and do in the system.
The cards seen by users in the employee profile are directly related to permissions and roles granted to those
users.
The permission categories are divided in User Permissions and Admin Permissions, which are further subdivided,
for example, Employee Data or Miscellaneous Permissions . Once selected, the list of permissions associated with
this category is displayed on the right side and in some areas, further divided into groups. For example, the HR
Information section contains groupings, for example, for Biographical Information.
Employee Central Effective-Dated Entities [page 127] Set field-level permissions for effective-dated cards and fields.
These cards are effective dated:
• Addresses
• Compensation Information
• Dependents
• Job Information
• Job Relationships
• Personal Information
Employee Views Allows users to view the sections in People Profile. Each item
under the Employee Views Section permission corresponds
to a section in People Profile. An item is automatically listed
under the permission category after you create a section.
Related Information
Assign permissions for cards that refer to non-effective dated entities. Non-effective dated means that the history
for the changes is not stored in the system (for example, for Phone Information).
The entries listed here refer to the different cards that have been defined as HRIS elements in the Succession Data
Model.
If necessary, you can use OnView rules to control who can see which fields in the cards listed here,
since you cannot use role-based permissions to set field-level View permissions for these cards. For more
information about how to create such rules, refer to the Example Employee Central Business Rules [page
238].
• Edit: The user can edit the card on the Personal Information or Employment Information page by selecting the
Edit link in the card.
Note that the labels depend on the labels defined in the Succession Data Model. If you have taken over the
standard Succession Data Model, the following entries are displayed under HR Information:
User Permissions Employee Data Biographical Information Admins with this permission can access
HR Information (personInfo) personal data of a user.
User Permissions Employee Data National ID Information Admins with this permission can access
HR Information (nationalIdCard) the national ID information of a user.
User Permissions Employee Data National ID (Restricted to only coun- Admins with this permission can only
HR Information try/region of legal entity) access the national ID information of
an employee relevant to the country
(nationalIdCard)
or region of the legal entity where the
employee is currently employed. For ex-
ample, an administrator responsible for
an employee currently employed in the
United States can’t view or add national
ID information related to other countries
or regions for the employee.
User Permissions Employee Data Phone Information (phoneInfo) Admins with this permission can access
HR Information personal data of a user.
User Permissions Employee Data Email Information (emailInfo) Admins with this permission can access
HR Information personal data of a user.
User Permissions Employee Data Business Email Address This entry is an exception. It refers to one
HR Information of the email types of the emailInfo
element: business email address.
Note
As business email is part of email
information, to grant employees the
View permission to business email
addresses, you must also grant
them the View permission to the
emailInfo element. The same
goes for the Edit permissions.
User Permissions Employee Data Social Accounts Information (imInfo) Admins with this permission can access
HR Information personal data of a user.
User Permissions Employee Data Primary Emergency Contact Admins with this permission can access
HR Information (emergencyContactPrimary) personal data of a user.
User Permissions Employee Data Spot Bonus Users with this permission can view the
HR Information (payComponentNonRecurring) Spot Bonus card on the Employment In-
formation page.
Note
Admins can also assign approval
workflows for changes done on the
Update Employee Records page.
User Permissions Employee Data Spot Bonus Edit Action Users with this permission can change
HR Information what data employees are allowed to
(payComponentNonRecurring)
change on the Employment Information
page.
User Permissions Employee Data Payment Information (paymentInfo) Admins with this permission can access
HR Information personal data of a user.
User Permissions Employee Data Work Permit Info (workPermitInfo) Admins with this permission can access
HR Information personal data of a user.
User Permissions Employee Data Global Assignment Details This entry is only displayed when Global
HR Information (globalAssignmentInfo) Assignments Management are active in
the system.
Note
Admins can also assign approval
workflows for changes done on the
Update Employee Records page.
User Permissions Employee Data Pension Payout Details This entry is only displayed when pension
HR Information (pensionPayoutsInfo) payouts are active in the system.
Note
Admins can also assign approval
workflows for changes done on the
Update Employee Records page.
User Permissions Employee Data Business Address Normally every employee needs a busi-
HR Information ness address. If a company assigns the
addresses to the employees and does not
want them to be editable by the employ-
ees, select only View permission here.
User Permissions Employee Data Pay Targets Admins and managers with this permis-
HR Information sion can view and edit the pay targets
section of the Compensation Informa-
tion .
Related Information
Assign permissions for actions and fields in the Global Assignment Details.
These permissions are found in User Permissions Employee Data Global Assignment Details
The fields listed are from the Succession Data Model for the HRIS element globalAssignmentInfo.
For this Global Assignment Details entry... ...select which permission is needed:
Global Assignment View View allows the user to view the Global Assignment Details on
the Employment Information page.
Global Assignment Edit Link Edit allows the user to make changes to the Global Assignment
Details directly on the Employment Information page.
This requires the user to also have the Global Assignment View
permission.
Note
Approval workflows cannot be added to changes done us-
ing the Edit link.
Global Assignment Add Edit allows the user to add a global assignment by navigat-
ing from the Employment Information page to the Update
Employee Records page using the Take Action menu.
Global Assignment Edit/MSS Edit allows the manager to edit a global assignment by navi-
gating from the Employment Information page to the Update
Employee Records page using the Take Action menu.
Note
Approval workflows can be assigned for changes done on
the Update Employee Records page.
Global Assignment End Edit allows the manager to end a global assignment by navi-
gating from the Employment Information page to the Update
Employee Records page using the Take Action menu.
Global Assignment Delete Edit allows the manager to delete a global assignment by navi-
gating from the Employment Information page to the Update
Employee Records page using the Take Action menu.
Assignment Type Edit allows the admin or manager to update this field.
Planned End Date Edit allows the admin or manager to update this field.
Actual End Date Edit allows the admin or manager to update this field.
Assignment Start Date Edit allows the admin or manager to update this field.
Payroll End Date Edit allows the admin or manager to update this field.
Related Information
These permissions are found in User Permissions Employee Data Employment Details
The fields are from the Succession Data Model for the HRIS element employmentInfo. Only the HRIS fields with
visibility "both" or "view" are available for setting permissions. Termination-related fields are also included.
Employment Details MSS View to allow the user to view the Employment Details.
Note
Approval workflows can be assigned for changes done on
the Update Employee Records page.
Employment Details Edit Edit allows the user to edit the Employment Details on the
profile by selecting Edit button.
Add New Employment Edit allows the user to add multiple employments for one em-
ployee.
Bonus Pay Expiration Date Hide this field from the user interface by deselecting View and
Edit.
Change Primary Employment The field defines whether the admins are allowed to change the
employment classification of an employee in the Employment
Details rather than in the Manage Data UI.
Hire Date Edit allows the admin or manager to update this field.
Termination Date Edit allows the admin or manager to update this field.
Original Start Date Edit allows the admin or manager to update this field.
Seniority Start Date Edit allows the admin or manager to update this field.
Payroll End Date Edit allows the admin or manager to update this field.
Last Date Worked Edit allows the admin or manager to update this field.
Regret Termination Edit allows the admin or manager to update this field.
Eligible for Salary Continuation Edit allows the admin or manager to update this field.
Eligible for Stock Edit allows the admin or manager to update this field.
Stock End Date Edit allows the admin or manager to update this field.
Salary End Date Edit allows the admin or manager to update this field.
Benefits End Date Edit allows the admin or manager to update this field.
Service Date Edit allows the admin or manager to update this field.
Initial Stock Grant Edit allows the admin or manager to update this field.
Professional Service Date Edit allows the admin or manager to update this field.
Initial Option Grant Edit allows the admin or manager to update this field.
New Assignment Company Edit allows the admin or manager to update this field.
Is Contingent Worker Edit allows the admin or manager to update this field.
Seniority Date Edit allows the admin or manager to update this field.
New Primary Employment Edit allows the admin or manager to update this field.
Related Information
Assign permissions for the Change Job and Compensation Info page.
The HR Actions section controls mainly who has access to the Update Employee Records page for actions defined
in the Succession Data Model.
Update Employment Records (displayed as Take Action but- This option overrules all other permissions in this section. It
ton) controls whether the user can see and use the Take Action
button from the Employment Information page.
View Higher Grades This option defines whether a manager can view an employee's
job classification and pay grade if it is higher than the manag-
er's. This option is valid for Manager Self-Service scenarios,
but it not valid in the History.
Report No-Shows This option allows the admin or manager to report no-show
new hires within 30 days of the expected start date of the
employee.
Add New Employee This is an hris-action from the Succession Data Model. It de-
fines if the user can access the Add New Employee link in the
Admin Center.
Manage Leave of Absence This option allows admins or managers the Take Action button
for legacy LOA.
Return from Leave of Absence This option allows admins or managers the Take Action button
for legacy LOA.
Note
Permissions to access the Update Employee Records page for Global Assignments are set in User
Permissions Employee Data HR Information .
Define whether a user has the permission to view changes for effective-dated entities in the future.
These permissions are found in User Permissions Employee Data Future-Dated Transaction Alerts
You can define whether a user has the permission to view future changes for effective-dated entities when the user
selects the Pending future change… link.
Note
Unlike effective-dated entities such
as Compensation Information, if the
pay date (issue date) of the non-re-
curring pay component (non-effec-
tive dated entity) is in the future, the
record is shown on the UI only if the
View permission is granted.
Related Information
Define whether a user can see if a workflow has been initiated, but not yet approved.
These permissions are found in User Permissions Employee Data Transactions Pending Approval
Work Permit Info workPermitInfo View means the pending approval link is
shown, but you cannot select it to get to
the details of the workflow request.
Define the permissions to view the workflow history from the History page of certain effective-dated entities..
These permissions are found in User Permissions Employee Data View Workflow Approval History
Related Information
Assign View or Edit permissions for individual event reasons. This helps distribute different functions within the
company to the correct people.
These permissions are found in User Permissions Employee Data Event Reasons .
• HR admins can be the only ones given access to data changes and this action has no workflow attached.
• HR admins have access to transfers outside the team.
• Managers only have access to transfer to/from their team.
• Payroll admins only have access to out-of-cycle salary increases.
There are many types of event reasons, for example, data changes, termination, job changes, global assignment,
benefits, paid or unpaid leave, hire or rehire, transfer, and so on.
Related Information
You can find these permissions in User Permissions Employee Central Effective Dated Entities .
Permission Type
There are five different permissions you can select for effective-dated cards and fields:
• View Current: The user can see only the current field value of an effective-dated entity. When the user looks at
the History page, the past data record for this field is not displayed.
• View History: The user can see past values on the History page. This permission also includes the View Current
permission, so that the user can also see the current field value.
• Edit/Insert: The user can edit an effective-dated entity by inserting a new data record for it which is effective as
of a certain date. As the user does not really change the data record itself (then it would just overwrite the past
data record), past data records are still available in the History. The field is also available for editing when a new
data record is inserted.
• Correct: The user can make corrections on the History page.
• Delete: The user can delete an effective-dated entity. This permission is only applicable at card level, not at field
level.
The above permissions can be set on three levels, and accordingly are validated in different ways.
Card actions control the user access level to the entire card and block buttons. Permissions at card level allow
users to:
Note
Use this level of permissions when you want to associate an approval workflow with the changes done in this
card.
The below table gives information about how to set block-level permissions in some common scenarios.
Employees and admins view records. In the line [Card Name] Actions: No icon is displayed in the cards.
The View Current permission Users can view current records.
Employees update their records on the In the line [Card Name] Actions:
The icons (Edit) for Editing UI and
Editing UI and view the change history.
• The View Current permission (History) for History UI are both dis-
• The View History permission played in the card.
Admins update the change history. In the line [Card Name] Actions:
Only the icon (History) for History UI
• The Edit/Insert permission is displayed in the card.
• The View Current permission Users can do the following:
• The View History permission
• View current records
• View the change history on the His-
tory UI
• Choose the Insert New Record but-
ton on the History UI to add a history
record
• On view of UIs
• On delete
• On correct/Insert
The table below lists the effective-dated cards in Employee Central, and provides notes about permissions for each
card.
Edit Link permissions control what users can do in the Manager and Employee Self-Service pages.
• On view of UIs
• On save in MSS
Field-level Permissions
Field-level permissions control each field’s specific ability to be maintained. The fields also include country/region-
specific fields that are prefixed by the 3-letter ISO code (for example, FRA for France, DEU for Germany, and so on).
• On view of UIs
• On save of UI data
For a complete list of all listed fields, refer to the fields listed in your Succession Data Model and country/region-
specific Succession Data Model. If a field is configured in both data models, only the field from the Succession Data
Model is shown in this list.
Show/Hide User
You can show the name of the user next to the user name in the Last modified by field in the History pages of
effective-dated HRIS elements. Showing the user name rather than the user ID in the History page makes it easier
to identify employees who last changed the record.
If the Platform Feature Settings Hide Username setting is not active in the system, then the person who
made the latest changes is shown with their full name and their user ID.
Related Information
Employee Views permissions allow you to view sections in the People Profile.
These permissions are found in User Permissions Employee Views Employee Views Section .
Under the Employee Views Section permission, each item listed corresponds to a section in the People Profile. The
items vary depending on the sections configured in your system.
Related Information
You can use role-based permissions (RBP) to control access with regard to which admin can view or edit which
data.
Role-based permissions allow you to grant different levels of read or write access depending on the role of the
employee. For example, an employee is only allowed to read their own compensation information, but an HR Admin
is allowed to edit it. You define these kinds of permissions by managing permission roles.
Under Administrator Permissions, the following permission categories are relevant for Employee Central:
Manage System Properties These permissions ensure that access and validations are
properly set up.
Manage Foundation Objects These permissions ensure that users can import and work with
foundation objects and translations for Job Codes.
Manage Foundation Object Types These permissions are control what the admin is allowed to
do on the Manage Organization, Pay and Job Structures page.
Grant permissions for each individual foundation object.
Manage User These permissions ensure that users have the correct access
to all they need in Employee Central. This is especially impor-
tant for the integration between Recruiting, Onboarding 1.0,
and Employee Central.
Metadata Framework These permissions ensure that users can work with generic
objects in the Metadata Framework (MDF).
Note
What is the difference to the Manage Data permission?
Manage Business Configuration These permissions ensure that users can work with the Busi-
ness Configuration UI, which allows them to access the Suc-
cession Data Model as well as the country/region-specific
Succession Data Model from the UI rather than having to go
through Provisioning.
Remember
As a customer, you don't have access to Provisioning. To
complete tasks in Provisioning, contact your implementa-
tion partner or Account Executive. For any non-implemen-
tation tasks, contact Product Support.
Employee Central API These permissions ensure that users can work with the SOAP-
based application programming interfaces (APIs) for Employee
Central. These are relevant for integrating Employee Central
with other software products.
The Foundation APIs are relevant for foundation data, the HRIS
APIs for person and employment data.
Manage Time Off These permissions ensure that users can work with Time Off
and the Time Sheet.
Manage Time
For more information about Time Off, refer to the Implement-
ing Employee Central Time Off guide on the SAP Help Portal.
Manage Positions These permissions ensure that users can work with Position
Management.
Manage Compensation These permissions ensure that users can work with Employee
Central compensation data.
Manage Pay Scale
For more information, refer to the Implementing and Configur-
Manage Deductions ing Employee Compensation Data in Employee Central guide
on the SAP Help Portal.
Manage Spot Awards
Related Information
Set permissions to ensure admins have access to the correct pages to complete their work.
Here you define permissions for the admin that cover many aspects of the system, for example, creating &
updating company settings as well as processes. Allowing admins the rights to update settings for mobile and
security areas is also done here.
Related Information
• Import Foundation Data: Grants access to the Import Foundation Data link in the Admin Center.
• Import Translations: Allows the admin to import translations for the jobCode foundation object, using the
Import Translations link in the Admin Center. For more information, refer to Importing Data Translations for
Legacy Foundation Objects.
Related Information
Set permission to ensure users can work with foundation object types.
You can define permissions for the admin that refer to the different types of foundation objects. Foundation objects
are created, edited, and deleted in the Admin Center. To access the page, in the Tools Search field, select Manage
Organization, Pay and Job Structures.
The following permissions are relevant here and refer to what the admin is allowed to do on the Manage
Organization, Pay and Job Structures page:
• View: The admin can only view the corresponding foundation object type.
• Create: The admin can create a foundation object of the selected type.
• Insert: The admin can create a new data record for a foundation object type, by selecting Insert New Record.
• Correct: The admin can correct foundation objects by selecting Take Action Make Correction in the
History page.
Related Information
Set permissions to ensure that users have the correct access to all they need in Employee Central. This is
especially important for the integration between Recruiting, Onboarding 1.0, and Employee Central.
The following scenarios may be relevant for you to help you make the correct selections:
• Add New User: Grants access to the Add New Employees link in the Admin Center.
Note
The Add New Employee screen does not respect the role-based permissions you set up here. Instead it
respects the settings from the data models with regards to whether a field or card is visible or editable.
• Rehire Inactive Employee or Rehire Inactive Employee with New Employment: Grants access to the Rehire
Inactive Employee link in the Admin Center.
• Rehire Inactive Employee with New Employment (by 'match' in New Hire) or Rehire Inactive Employee (by
'match' in New Hire): Grants access to the Match pop-up in the New Hire screen.
• Include Inactive Employees in the search: Enables the search for inactive users on the Employee Files page and
in the directory search.
• Import Employee Data: Grants access to the Import Employee Data link in the Admin Center.
• Restrict fields of type Worker
Fields of the type Worker (for example, supervisor in Job Information or HR/matrix manager in Job
Relationship, and so on) respect target groups defined in permissions. This means that, if configured, users
can only add managers that are included in the target group defined in the permissions.
Note
The admin can only access the workflow requests for the target population to which the admin role has
been granted access.
• Manage Workflow Groups: Grants access to the Manage Workflow Groups link in the Admin Center.
Related Information
Set the read-only permission for the name and external code fields of the Metadata Framework (MDF) Foundation
Objects (FOs) and set the rest of the fields to No Access. This grants Value Help Read Only permissions for
everyone.
Context
These permission settings allow all users to view and select information on the New Hire, Employee Self Service
(ESS), and Manager Self Service (MSS) pages.
Without these settings, users will not be able to view or select values from a drop-down list associated with a field of
the MDF FO (also referred to as value help). For example, if the setting is not applied to the Legal Entity MDF FO, the
user will not be able to view or select any Legal Entity value from the drop-down lists.
Procedure
1. We will now set Read Only permission for the name field. In this example, select Business Unit Name from
the Field dropdown and apply the Read Only permission.
2. Now, repeat this for all other fields displayed in the Field dropdown but set Permission to No Access, as
shown below.
Related Information
Add a new parameter to a dynamic group filter to allow managers and admins access to employee data prior to
their internal transfer or hire date.
Context
Note
This feature works only when permission roles are granted by permission groups, and only for permission
groups. This feature does not work for predelivered roles such as Managers or Everyone (All Employees).
Creating permission groups for each manager is not feasible since it would result in thousands of additional
permissions group to be updated whenever a new employee joined the company as a manager.
There is a new parameter for managers and admins with correct permissions to see a pending transfer or hire prior
to the transfer date to add employee data and complete the hire process. This parameter represents the number of
days that the receiving parties (admins or managers) can see the employment records before the change.
Add a new parameter called extend by n days to the criteria in the dynamic group filter. The parameter for the
dynamic group filter is always added on HRIS element level (Job Info) rather than on field level (department). For
example, if a department or cost center are used as filter criteria to determine the permission group, and you add
a parameter with a value of 90 days, it will allow users with the right permission group for that cost center or
department to access the employee data 90 days before the organizational change takes effect.
For example, for the filter criteria Department = Finance, the parameter extend by 90 days is added to allow a
potential receiving manager with access permissions to employees in the Finance department to access the data
90 days before the transfer date.
For entities with multiple changes each day such as Job Information, Compensation Information, or Pay
Component Recurring, only the last record (EFFECTIVE_LATEST_CHANGE = true) is taken into account when
the permission group is built.
Procedure
Do not add multiple <extend by n days> filters to the same HRIS element.
5. The <extend by n days> filter is defaulted. Enter the number of days that the receiving parties (admins or
managers) can see the employment records before the organizational change.
6. Choose Done and save your settings.
Results
Once the filter is created, you create a permission group or update an existing group to grant them access to see
the employee data.
In addition, we recommend granting the Administrator Manage Hires Include Inactive Employees in the
search permission to access future hires or inactive users.
Related Information
Give a permission group access to a specific target population of employees who have pending organization
changes.
Prerequisites
The permission group to which you want to grant access exists in the system.
For example, you have a group called Job Information - Department - Extend by 90 Days. This means, that when
executed, the query would select employees with department of finance from today until 90 days from today.
A user with access to a predefined permission group can now view the profiles of users who will move to this
department any time within the next 90 days.
Context
Note
When configuring a permission group (PG) using this parameter, the preview will only show the ‘active’
employees in the permission group. Employees still inactive at the definition point in time will not show up.
Nevertheless if they match the criteria, then they will be part of the permissions group and correctly selected
during runtime.
For entities with multiple changes each day such as Job Information, Compensation Information, or Pay
Component Recurring, only the last record (EFFECTIVE_LATEST_CHANGE = true) is taken into account when
the permission group is built.
5. For 1, leave the default setting Grant role to Permission Group as is.
6. For 2, select Target population of, then select the None selected checkbox. Choose Select.
7. In the Groups list, select the permission group and then select Finished.
8. For 3 and 4, you can leave the default settings as is. Select Finished to save your settings.
Information in Employee Central is organized around the type of data it is, for example, personal information or
employment information. This information is then shown on the People Profile in organized cards. Those cards are
comprised of multiple entities.
An effective-dated entity means that the data is valid only for a specific period and is subject to change more often
than other data.
Personal Information
Personal Information This is information about an individual Imports, Editing UI, History UI
Addresses Employees can add multiple addresses Imports, Editing UI, History UI
as well as multiple types of addresses.
Dependents Employees can add multiple dependents Person Relationship Imports, Editing UI,
along with their data. History UI
Phone Information Employees can add multiple phone num- Imports, Editing UI
bers as well as multiple types of phone
numbers.
Email Information Employees can add multiple email ad- Imports, Editing UI
dresses as well as multiple types of email
addresses.
Social Accounts Employees can add multiple social media Imports, Editing UI
accounts.
National ID Information Employees can add multiple ID types and Imports, Editing UI
their numbers.
Employment Information
Job Information Managers can add, update, or delete job Imports, History UI, MSS
data, time information, and other infor-
mation for an employee.
Job Relationships Managers can specify the employer's HR Imports, History UI, MSS
Business Partner, legal advisors, and oth-
ers besides the primary manager.
Compensation Managers can change the salary, bonus, Imports, History UI, MSS
eligibility for benefits, and other informa-
tion.
Recurring Pay Components Managers can add, update, or delete re- Imports, History UI, MSS
curring pay components such as for the
base salary or a company car allowance.
Employment Information Managers can change the first date Import, Editing UI
works, stock eligibility, and other infor-
mation.
Termination Information Managers can add a termination date for Imports, MSS
an employee.
Non-Recurring Pay Components Managers can add a spot bonus for an Imports, MSS
employee.
Related Information
Personal Information entities are data that relates to individual people, and can be used to identify people.
Learn more information about the entity Personal Information in Employee Central.
Global Information
Global Information is a part of the Personal Information card, if the globalInfo HRIS element is configured in the
BCUI or the Succession Data Model (SDM). However, there are no HRIS fields in the SDM for the globalInfo. For
each country/region-specific field needed, fields for the globalInfo HRIS element can be added in the BCUI or
Country/Region-Specific Data Model.
OnInit rules can be configured under both SDM or Country/Region-Specific Data Model. However, with respect to
execution, only one rule for each country/region is executed. You can have different rules for different countries or
regions in the Country/Region-Specific Data Model. However, if there is more than one rule for the same country/
region, then only one rule is executed. If multiple rules are needed, the logic must be set within the same rule.
Special characters are not supported in picklist IDs for Personal Information.
For telephone numbers in Personal Information, we have now introduced validations to prevent employees from
adding nonprintable characters at the beginning or end. Empty spaces before or after the number are now
automatically removed when the number is saved.
These validations are not run against existing telephone numbers in the system. You do not have to update all
existing telephone numbers.
Personal Information can be configured in both the Succession Data Model (SDM) and the Business Configuration
UI (BCUI). The configurations should be the same.
However, an admin can create a customized version in the BCUI, for example, personalInfo_employee. If
personalInfo_employee exists in BCUI, then Personal Information on the People Profile will refer to the
configuration of personalInfo_employee in BCUI only rather than that of personalInfo in SDM. This is however
only supported on the UI and not in Imports or APIs.
Removing Flags
In the Global Information section of the Personal Information, the flag of the country/region is displayed next to the
country/region name by default.
Forward Propagation of Personal Information and Global Information on History UI [page 146]
On the History UI of Personal Information and Global Information, forward propagation of changes in field
values is supported only when you choose Insert New Record to update the history records.
Forward Propagation of Personal Information and Global Information on Editing UI [page 148]
Forward propagation of changes in field values is supported on the Editing UI of Personal Information and
Global Information when you add or edit records.
Record Suppression for Personal Information and Global Information on the UI [page 151]
On the History UI and Editing UI of Personal Information and Global Information, if you update or delete a
record, it doesn't affect the "last modified date" and "last modified by" information of other records in the
card.
Related Information
Prevent users from deleting Global Information on the Editing UI of Personal Information and Dependents so that
the information is available for replication in a Payroll system.
Prerequisites
You have the Administrator Permissions Manage System Properties Company System and Logo Settings
permission.
Context
Procedure
Results
Users can't save the changes if they perform the following actions on the Editing UI:
Forward Propagation of Personal Information and Global Information on History UI [page 146]
Forward Propagation of Personal Information and Global Information on Editing UI [page 148]
Record Suppression for Personal Information and Global Information on the UI [page 151]
On the History UI of Personal Information and Global Information, forward propagation of changes in field values is
supported only when you choose Insert New Record to update the history records.
The updated field is propagated to future records until one of the future records has a field value that is different
from the original field value.
Remember
Records in these examples only include some of data fields to demonstrate changes.
Example
You insert a record with a start date on January 1, 2016 and change the last name from "Armstrong" to "Smith".
Result:
The updated field value "Smith" is forward propagated and stops on December 31, 2019, because the last
name of the record starting from January 1, 2019 is "Moore" and is different from the original last name of the
previous record, which is "Armstrong".
Example
You insert a record with a start date on January 1, 2016 and change the number of children from "0" to "1".
Result:
The updated field value "1" is forward propagated and stops on December 31, 2019, because the number of
children starting from January 1, 2019 is "2" and is different from the original value of the previous record, which
is "0".
Related Information
Forward propagation of changes in field values is supported on the Editing UI of Personal Information and Global
Information when you add or edit records.
The updated field is propagated to future records until one of the future records has a field value that is different
from the original field value.
The following examples describe the behavior of forward propagation on Centralized services.
Remember
Records in these examples only include some of data fields to demonstrate changes.
Example
The existing records are continuous and have no data gap in between.
You set the start date as January 1, 2016, and do the following changes:
Result:
The changed field values are forward propagated, which stops on December 31, 2018, because the field values
of <Custom String 1> and <Number of Children> starting from January 1, 2019 are different from the
original field values of the previous record.
Example
You set the start date as an existing start date, January 1, 2015 and update the <Number of Children> in
Global Information to 1.
Result:
Personal Information remains unchanged. The changed field value in Global Information is forward propagated.
Example
There is no record of Global Information from January 1, 2017 to December 31, 2018.
You set the start date as January 1, 2016 and update the <Number of Children> in Global Information to 1.
Result:
The updated record of Global Information is not forward propagated because there is a data gap starting from
January 1, 2017.
Related Information
On the History UI and Editing UI of Personal Information and Global Information, if you update or delete a record, it
doesn't affect the "last modified date" and "last modified by" information of other records in the card.
Personal Information and Global Information have a parent-child relationship. Scenarios related to the suppression
are as follows:
• When you edit the parent entity, only the data of the parent entity is updated.
There is no change to the "last modified date" and "last modified by" information for the records of its child
entity.
• When you edit a record of child entity, the "last modified date" and "last modified by" information of this
record and its parent entity is updated.
There is no change to the "last modified date" and "last modified by" information for any other records of child
entity.
• When you delete a record of child entity, only the "last modified date" and "last modified by" information
of its parent entity is updated.
There is no change to the "last modified date" and "last modified by" information for any other records of child
entity.
Related Information
4.1.2 Addresses
The default address format is displayed for all countries or regions. To display the address in a format specific to a
country or region, you can instead create the Simple Address Format for the country or region.
For more information, see Setting the Address Formats in People Profile.
The address is an effective-dated entity, meaning that as of the rehire date, you are making a change, and deleting
the address record as of that date. So the address card will capture that change as effective from rehire date, which
is why you see a blank record in address info as of rehire date.
In cases where an employee changes or deletes any address information, or has no address for a specific amount
of time, then this can be reflected on the History UI.
Example
User A was hired on January 1, 2014 and most likely starting on that same date, so there will be a home address
record that starts on the same date as the hire date. Now, the employee moves from the current home address
from January 1, 2016. Then employee edits for the address with an effective date of January 1, 2016 and deletes
the home address. (The employee address card has no other address type). Now, there will be no address
shown in the UI.
In Addresses History, employees can undo the changes they've made by deleting the corresponding change history
entry. However, the deletion action can't be undone, therefore you can't restore a deleted address record.
Forward Propagation
Note that forward propagation does not occur if the country field of an added or edited address differs from the
next record. As forward propagation works at the field level and the same field may have different meanings for
different countries, allowing forward propagation across records with varying countries could lead to confusion.
On the History UI of Addresses, forward propagation of changes in field values is supported only when you choose
Insert New Record to update the address history.
The updated field is propagated to future records until one of the future records has a field value that is different
from the original field value.
Example
You insert a record with a start date on January 1, 1999, set the address type as "home", and the postal code as
"30000".
Result:
The new record of home address is forward propagated and stops on January 1, 2021, because the home
address from January 1, 2021 is different from the original previous home record, which doesn't exist.
Example
You insert a record with a start date on May 1, 2020 and change the postal code of the billing address from
"10000" to "20000".
Result:
The updated field value "20000" is forward propagated and stops on December 31, 2020, because the postal
code of the record from January 1, 2021 is blank and different from the original postal code of the previous
record, which is "10000".
Example
You insert a record with a start date on May 1, 2020 and change the postal code of the billing address from
"10000" to "30000".
Result:
The updated field value "30000" is forward propagated and stops on December 31, 2020, because there's no
record from January 1, 2021 to April 30, 2021.
Related Information
Forward propagation is supported on the Editing UI of addresses when you add or edit a record.
The updated field is propagated to future records until one of the future records has a field value that is different
from the original field value or there is a data gap.
The following examples describe the behavior of forward propagation on Centralized services.
Remember
Records in these examples only include some of data fields to demonstrate changes.
Example
You set the start date as January 1, 1999 and do the following changes:
Result:
Example
The existing records are continuous and have no data gap in between.
You set the start date as May 1, 2020 and change the postal code of the billing address from "10000" to
"20000".
Result:
The existing records are continuous and have no data gap in between.
You set the start date same as the earliest start date, January 1, 1999 and change the postal code of the billing
address from "10000" to "20000".
Result:
Example
In the existing records, there's a data gap between January 1, 2021 and April 30, 2021.
You set the start date as May 1, 2020 and change the postal code of the billing address from "10000" to
"30000".
Result:
The updated field value "30000" is forward propagated and stops on December 31, 2020, because there's no
record from January 1, 2021 to April 30, 2021.
Related Information
You can prevent users from deleting a certain type of addresses on the Editing UI of Addresses so that the
addresses are available for replication in a Payroll system.
Prerequisites
You have the Administrator Permissions Manage System Properties Company System and Logo Settings
permission.
Context
Procedure
Mandatory Fields
The <relationship> and <name> fields are business keys for Emergency Contact, and must be enabled and set
to mandatory. Besides, the <primary_flag> field must be enabled and set to mandatory.
Avoid creating duplicate records for emergency contacts. You would expect errors if adding multiple emergency
contacts with the same name and relationship for an employee.
Tip
You can add alternate fields, such as the Alt Phone field, for an emergency contact in one record instead of
duplicating the contact. For more information about the fields for the Emergency Contact, see Emergency
Contact.
Context
By default, mandatory field validation covers no more than the following fields for emergency contacts, depending
on your field configuration:
However, you can extend the validation to cover all mandatory fields in the details section of the Emergency
Contact.
Procedure
4.1.4 National ID
Temporary IDs
Admins can provide an employee's temporary national ID in the National ID Information if that employee does not
have a valid national ID during the hire process.
Mandatory Fields
Related Information
When entering or editing work permit information on the Work Permit card, make sure that you meet the following
prerequisite and requirements.
Prerequisite
Go to Manage Business Configuration to enable Country, Document Type, Document Number, and Issue Date
in order to view and edit these fields.
These four fields on the UI are mandatory and must not be left empty.
Data Validation
Values entered for the four fields - Country, Document Type, Document Number, and Issue Date - are joined
to user ID to form a business key that uniquely identifies a work permit. So, don’t enter two records with identical
Country, Document Type, Document Number, and Issue Date values. At least one of these four fields must have
different values between the two records.
In the admin tool Managing Business Configuration (BCUI), these business key fields are validated to ensure they
are enabled and set to mandatory. If not, they can be made mandatory automatically upon user confirmation.
Tip
When Centralized services are enabled to support work permit saving on UI, related workflows can also be
triggered with XML rules, which is consistent with the legacy behavior.
The validation mechanism checks compliance of not only the current record being saved, but also all other
records associated with the user. All non-compliant records must be corrected before the current record can be
successfully saved.
Example
Suppose that a user has several existing non-compliant work permit records and is trying to enter a new one:
Existing record Logged-in us- United States Null 2283D2FBC20 2021-10-01 Key field empty
1 er's ID 21
Existing record Logged-in us- United King- Work Permit 4098D2FBC20 2020-04-09 Same business
2 er's ID dom 20 key as record 3
Existing record Logged-in us- United King- Work Permit 4098D2FBC20 2020-04-09 Same business
3 er's ID dom 20 key as record 2
Existing record Logged-in us- United Arab Work Permit 2298GB23020 2022-10-28 Same business
4 er's ID Emirates 22 key as new re-
cord
New record be- Logged-in us- United Arab Work Permit 2298GB23020 2022-10-28 N/A
ing entered er's ID Emirates 22
To successfully save the new record, the existing, non-compliant records 1-4 must all be corrected.
The following two checks are available in Check Tool Employee Central Core Employee Central Core :
Work Permit is among the several personal information entities whose final approval is supported by Centralized
services. With Centralized services enabled, if users try to approve a workflow whose triggering work permit record
doesn’t exist anymore, they'll be prevented from approving this workflow and advised to send back or withdraw it.
The legacy behavior would be let the users approve the workflow and create a new but incomplete work permit
record.
Employment-Based or Person-Based
The Work Permit is now employment-based by default. This means people with multiple employments only see
records from their current employment. To see additional records, they have to switch to other employments.
You can deselect the option Keep the Work Permit card in People Profile user-based in Company System and Logo
Settings to let them view the data consolidated on person level. With a person-based Work Permit, people can
view work permit records related to all their employments after logging into any account corresponding to those
employments.
When the latest People Profile is enabled, there is another option that controls how work permits of employees
having concurrent employments (CE) are accessed: Enable Person-Based Work Permits in Latest People Profile
for Concurrent Employment. Selecting this option allows CE users to view work permits associated with all their
employments but to edit only those associated with their current employment.
Mandatory Fields
4.1.7 Email
The email addresses you added are by default validated against the RFC 822 standards. If you do need to turn
off the validation, you can select Disable Email Address Validations in Company System and Logo Settings. Among
others, the following are validated for email addresses:
Mandatory Fields
You can delete a time period with the Delete button on the History UI for addresses, personal information, and
global information without affecting records in later or previous time records.
Note
Forward propagation is not supported when you use the Delete button.
The following examples describe how data changes when you use the Delete button on the History UI.
Example
You delete the records of two address types: Home and Shipping with the start date on January 1, 2012.
Result:
• The Home and Shipping records with the start date on January 1, 2012 are deleted.
• No forward propagation occurs.
• The records in later time period are not affected.
Example
You delete the Billing record with the start date on January 1, 2014.
Result:
• The Billing record with the start date on January 1, 2014 is deleted.
Example
Number of Chil-
First Name Last Name Country/Region dren Start Date End Date
You delete the record of personal information with the start date on January 1, 2017.
Result:
• The record of personal information with the start date on January 1, 2017 is deleted.
• The record of global information with the start date on January 1, 2017 is deleted.
• No forward propagation occurs.
Number of Chil-
First Name Last Name Country/Region dren Start Date End Date
You delete all records in the time period with the start date on June 21, 2021.
Result:
• The Billing and Home records with the start date on June 21, 2021 are deleted.
• The records in previous time period are not affected.
Enable attachments for a person entity so that employees can upload documents for a certain type of personal
information.
Context
You can allow employees to upload attachments for the following person entities:
You can also enable attachments on Personal Information, Global Information, Biographical Information, National
ID, and Addresses for dependents with the Manage Business Configuration tool.
Procedure
Here is a little more information about some of the features and functions in Employee Central.
General
The data displays a user's employment information, including the company and start date.
• Effective-Dated Entities
• Job Information
Allows the tracking of all job changes of the employee.
• Compensation Information
Shows generic compensation-related data and contains the assignment of specific pay components that
are either recurring payments or targets as well as associated amounts.
• Job Relationships
Allows the recording of globally-defined relationships between the employee and another person in the
company.
• Non-Effective-Dated Entities
• Employment Information
Records data specific to the employment with the company, for example, the hire date or termination
details.
• One-Time Payment Information
Allows the recording of one-time payments such as one time bonus or recognition payments including
associated amounts and date paid.
Note
For an effective-dated entity, when you insert a new record, the end date of the previous record is automatically
set to the day before the effective start date of the new record. And the new record is automatically assigned an
end date of 12-31-9999. However, the Last Modified Date changes only when the record is edited (through UI or
Import).
Person Type
You can create a data model for the Employee person type for Employment Information. They are then taken into
account for the Profile, Take Action, Workflows, and History, but not for Imports or APIs.
Related Information
Types of Employment
Here is a little more information about some of the features and functions in Employee Central.
General
As part of Employment Information, Job Information stores data related to an employee's function within the
company. It is defined during the hiring process. It is an effective-dated entity and no gaps are allowed, meaning
that an employee must always have a current Job Information record. All changes to records are available in the
history. Multiple changes for each day using sequence numbers are allowed. Changes to an employee's data should
be done using the Action menu options rather than from the History UI to ensure that all follow-on processes are
triggered and prevent data inconsistencies. The employment status of the user controls which actions can be done,
for example, a user with the Inactive status can't be terminated or book time off.
It is partially configurable in the Business Configuration UI (BCUI). It can be defined either globally, country/region-
specific, or person type specific.
History
The History UI offers a comprehensive display of all records pertaining to an effective-dated entity within the
system for each user in their chronological order. An important feature is that key changes between two records
can be easily identified without manual comparison of the records. The History UI not only shows what changed
and when, but also by whom or by which process. Next to displaying data, the History UI allows admins to
edit existing data records, to insert new ones, and to delete existing ones. The History UI is strictly separately
permissioned.
To access the History UI of an entity in People Profile, you choose the icon (History).
For employees on a leave of absence (LOA), you can define an expected return date. This field can be enabled and
made visible in either the Succession Data Model or in the Business Configuration UI. Once enabled, you can see
the Expected Return Date field in Job History for records with the Paid Leave and Unpaid Leave event (these event
reasons that start a leave of absence).
To see the field in Advanced Reporting, you must set the visibility to Both.
Permissions must also be enabled for this field in Permission Settings User Permissions Employee Central
Effective Dated Entities .
Event Reasons
Event Reasons are a system hard-coded field and therefore are not enabled or configured in the data model.
However, if you need to trigger onChange business rules from the Event Reason field, you must enable the <event-
reason> field in either the Succession Data Model or in the Business Configuration UI.
You can propagate job code values to the Job Information from the Work Schedule to allow admins to choose
custom codes for the company.
Update the Job Code object definition so that the custom string has the following settings:
This ensures that the selectable values for the Work Schedule are then identical in the job code instances as well as
in the Job Information.
You must then update the Work Schedule values for the different job codes in the Manage Data Job
Classification screen.
You can sync field values from position management to Job Information using business rules.
The notes and attachments fields are always cleared when a new Job Information record is created. Unlike most
other fields, these two values are never copied over into new records, since they generally refer to one particular
record (for example, documents attached to the Hire record or a note about a Suspension record).
Check Tool
You can also use the Check Tool to find any inconsistencies. We recommend selecting checks available under the
following sections:
• Check Tool System Health Tab Employee Central Core Association Area
• Check Tool System Health Tab Employee Central Core Invalid Effective End Date for FO/GO Area
• Check Tool System Health Tab Employee Central Core Job Information Area
• Check Tool System Health Tab Employee Central Core Object Relationship Area
• Check Tool System Health Tab Employee Central Core Picklist Area
• Check Tool System Health Tab Employee Central Core Picklist Usages Area
• Check Tool System Health Tab Employee Central Core Succession Data Model Area
Related Information
• To ensure that active employees don't have inactive managers on the start date of the inserted or edited Job
Information record. The system shows a warning message if an employee with an active employment has a
supervisor with an active employment record on the effective start date of the Job Information record, but the
supervisor becomes inactive before the end date of that record.
• When event reason or event is changed in an existing Job Information record, better data consistency is
ensured by adding additional checks.
• To ensure the employment status doesn't change when the event or event reason is changed.
• To ensure that the event reason selected in the History UI is always used and not overwritten by changes from
onSave rules.
• To ensure that exactly 1 hire record exists for each user, which is also the first record. This is performed during
each save action regardless of which record is touched or newly created. This validation also ensures that the
hire record cannot be deleted.
After adding a global assignment, the effective start date is defaulted from the hire date.
• To ensure that the start date of past, present, or future-dated hire records can only be changed using the Hire
Date Correction tool.
• To ensure that working days for each week is greater than or equal to 0, or less than or equal to 7.
• To ensure that only the Set action is used in rules where Job Information or Job Information Model is the target
object.
• To ensure that a warning message is raised when a termination record is modified or subsequent record after
the termination if there is no rehire.
• Derivation to ensure that the start and/or end date of Employment Information will always be adjusted
whenever a Job Information Hire/Termination/Rehire record is modified.
• The system shows a warning message if an employee with an active employment has a supervisor with
an active employment record on the effective start date of the Job Information record, but the supervisor
becomes inactive before the end date of that record.
• To ensure that the event reason selected in the History UI is always used and not overwritten by changes from
onSave rules.
• To ensure that exactly 1 hire record exists for each user, which is also the first record. This is performed during
each save action regardless of which record is touched or newly created.
When a termination record is deleted from the Job History UI, the system clears termination-specific fields,
end-date related fields as well as custom fields in Termination Details:
• OK to Rehire
• Regret Termination
• Attachment ID
• Eligible for Salary Continuation
• New Primary Employment ID
• End Date
• Benefits End Date
• Payroll End Date
• Last Date Worked
• Bonus Pay Expiration Date
• Salary End Date
• Stock End Date
In systems with Position Management enabled, the system validates some data when the Job Information History
of an employee is changed or when there's a Job History Import.
Related Information
Forward propagation means that a change in the value of a field in an object is also made (propagated) to future
records for the same object. The forward propagation of this field change stops as soon as one of the future records
has a field value that is different than the original field value.
Forward propagation also considers associated parent and child values and makes changes to future records as an
association-group change if both the parent and the child fields are changed in a newly inserted record. This means
that if a parent and child field both change in a new record, the fields in this group will be forward propagated
together as far as the parent field allows, regardless of future changes in the child field. Once the parent value
cannot be propagated further, propagation of the child value also stops.
If a single field out of a group of associated fields changes in a new record, this field is forward propagated on its
own until a future record has a different value in this field than the original value before the change, or until the new
value is no longer associated with its parent or child field values in a future record because future field values are
validated for respective parent-child associations before propagation.
If a child field has two or more immediate parent fields, and several parent values as well as the child value change
in a newly inserted record, this field group is forward propagated if all parent fields can be forward propagated, that
is if future records have the same value as the respective field’s original value before the change. If at least one
parent field has a different value in the closest future record, the entire field group is changed only in the newly
inserted record, and is not propagated forward.
When forward propagation makes changes to future records, then the Last modified timestamp and user of the last
change are also changed in these future records. Forward propagation for Job Information is on by default in the
system and cannot be switched off, except for imports, APIs, and Off Cycle Event Batch jobs where it is optional.
Note
If you add new records with information that is the same as in the existing records, the future effective-dated
records aren't updated.
Example
There is a future change for an employee where they have a promotion consisting of a grade change already
entered into the system. They transfer into a new department 1 month before the promotion takes effect. The
change to the department is forward propagated to the promotion record.
There is a future change for an employee where they have a promotion due to a transfer to a new division and
department including a grade change already entered into the system. Their location stays the same. They are then
moved into a different department and their location changes as part of an office reorganization one month before
the transfer/promotion takes effect. Forward propagation of the department change stops for the promotion
however the location change continues to be forward propagated.
Example
There is a future dated change where an employee is changing location and departments. The location is changed
1 month before the department change takes effect. If required, you should make the change to the location before
and after the transfer of the department, because it is not done by forward propagation.
Example
There are two records with the same value for the parent field (Building) and Office is the associated child field. The
second record represents a change to the child value (Office) within the same building.
Forward propagation takes into account parent-child associations and propagates changes forward for the entire
field group when a parent field value matches its original and future value even if its child field values don't match.
In this example, there are multiple direct parents. The child field Department is associated with two parents, Cost
Center and Division. These three fields are forward propagated as a group only if both parent fields can be forward
propagated.
Forward propagation now considers parent-child associations and makes changes to the future record if all parents
allow the propagation. Here, Division allows but Cost Center doesn't. Consequently, the field group is not forward
propagated at all.
Related Information
Forward Propagation of Personal Information and Global Information on History UI [page 146]
Forward Propagation of Addresses on History UI [page 153]
Forward Propagation of Addresses on Editing UI [page 155]
Forward Propagation of Personal Information and Global Information on Editing UI [page 148]
Forward Propagation of Data with Imports
Forward Propagation in Employee Central Compensation Information
This means that a change to these fields is not made to future records. Here's a list of the fields that are not forward
propagated in Job Information:
allow-delete
attachment-id
change-reason
change-source
change-reason-external
country-of-company
created-on
created-by
data-source
effective-latest-change
end-date
event-reason
item-id
last-modified-on
last-modified-by
notes
start-date
seq-number
timeInCompany
timeInDepartment
timeInJob
timeInLocation
timeInPayScaleLevel
timeInPosition
wfConfig
Ensure that the system correctly calculates FTE for pay range calculations.
Context
If the standard-hours field is enabled in the configuration, the system will always calculate the FTE based on Job
Information Standard Hours vs Object Standard Hours (Legal Entity or Location or Job Classification) depending
on configuration. This ensures that the FTE value is never null. However, if you have manually updated the FTE
value or set it using a rule to a value other than null or zero, it will not be overwritten by the automated calculation.
If the FTE field is not visible to the logged-in user for UI transactions, the application will reset the FTE value to null
so that it is recalculated.
The system will always derive the standard hours value used to calculate FTE from the following (in this order):
• jobInfo.standard-hours / jobInfo.Position.standardHours
Note
Only if Employee Central Position Management is enabled and the standardHours field is visible in the
Position object.
• jobInfo.standard-hours / jobInfo.job-code.standardHours
• jobInfo.standard-hours / jobInfo.location.standardHours
• jobInfo.standard-hours / jobInfo.company.standardHours
This means, that if the job code has a standard hours value, this wins over location, which wins over legal entity. If
the system finds no standard hours value, then it will move on to the next object and so on, until it finds a value. If
no reference value can be found, the calculation may still result in 0.
If you do not want to use the standard/hard-coded method for calculating FTE, then you will need to configure
the system differently to calculate the FTE. You can use business rules to meet this requirement. If you need to
calculate FTE based on many different scenarios, for example, you need FTE to be 0 if the employee is on a leave of
absence, then you need to configure this scenario using business rules and a custom-double field.
Note
Only remove the <standard-hours> field. Do not remove the FTE field, since it is also used for compa ratio
and range penetration calculations.
Tip
The default decimal rounding in the system is based on the principle of bankers rounding. For other rounding
methods, you need to create a rule with round function. For more information, refer to the Round rule function
documentation.
11. Select Take Action Make Correction and then select the trash can icon to the right of the <standard-
hours> field and save your changes.
12. Once the <standard-hours> field is deleted, add a custom decimal field (custom-double) field to jobInfo and
use this as your field for Standard Hours instead.
Create the Rule (Always Needed)
13. Create a new business rule using the Calculate Full-Time Equivalent (FTE) rule scenario. You can set as an
onChange (on the custom <standard-hours> field) and/or an onSave rule (on jobInfo element) so that the
FTE can be calculated differently depending on the requirement/scenario.
Alternatively, you can use the Calculate FTE based on Standard Hours() rule function in the rule. It will use the
<standard-hours> field in Job Information and lead to similar results as the hard-coded calculation.
Here is a little more information about some of the features and functions in Employee Central.
General
Job relationships can show hierarchical relationships, meaning there is a reporting line between the granted user
and the target user. These are job relationships between employees and their managers as well as employees
and their second managers or alternate managers. However, job relationships can also show non-hierarchical
relationships, which are single-level relationships. These include the relationship of an employee to the HR
manager, the matrix manager, additional manager, and custom manager.
The standard relationships can be used by the system to, for example, route workflows or Performance
Management forms. This means that customer-defined job relationships are not supported for workflow routing.
Job relationships are either entered into the system during the new hire process or during an import. They can also
be added later in the Job History UI, using the Manager Self-Service (MSS) action, or using Employee Central Quick
Actions - Change Job Relationships.
Job relationship records are effective-dated records to cover the employment history from hire to termination,
although, gaps are allowed. Making multiple changes to the records each day is not supported.
They can be partially configurable in the Business Configuration UI (BCUI), but must be defined globally, since a
country/region-specific job relationship is not supported.
• HR Manager
• Second Manager
• Matrix Manager
• Additional Manager
• Custom Manager
• Delegate 1
Someone who can act on behalf of the manager against all of their direct reports excluding the manager.
• Delegate 2
Someone who can act on behalf of the manager against all of their direct reports excluding the manager.
• Future Manager
This relationship is applicable only for internal hires.
You can update a job relationship from the employee's profile by going to Take Action Change Job and
Compensation Info . Then under Change Job and Compensation Info, select Job Relationships. Select the new
relationship and save your changes.
Picklists
Use the predefined picklist for Job Relationships found in the in the Software Download Center .
Customers can manually add new job relationship types to their picklist using the Picklist Center. For more
information, refer to Picklists in SAP SuccessFactors.
Job relationship entries must be synced between Employee Central and the Employee Profile. For more
information, refer to Picklist Configuration for Employee Status and Job Relationship Type.
Position Management
You can define matrix relationships for a position rather than job relationships for a person. When an employee
is assigned to a position, in other words, becomes the incumbent, the employee automatically has these job
relationships. That way, you don't have to create job relationships for each employee individually.
For customers newly implementing Position Management (from the 2H 2024 release), we recommend using 1
picklist for both Job Relationships and Matrix Relationships. Existing customers who have already implemented
both Employee Central and Position Management must continue to sync the Job Relationships and Matrix
Relationships picklists to ensure data consistency.
Relationships between positions can also be defined in the position org chart. These relationships can be
synced automatically into job relationships for position incumbents as well. For more information, refer to Define
Synchronization Position to JobInformation.
Fields of the type Worker (for example, supervisor in Job Information or HR/matrix manager in Job Relationship,
and so on) respect target groups defined in permissions. This means that, if configured, users can only add
managers that are included in the target group defined in the permissions.
To enable this feature, please go to Admin Center Company System and Logo Settings and select the feature
Enable target group based filtering for Worker fields. If checked, Worker type fields value dropdown list will based on
the target group settings in role based permission. If not checked, all users will be available in the dropdown list.
• To ensure that the start date is not before the first Job Information Hire record.
• To ensure that active employees don't have inactive related users on the start date of the new Job
Relationships record, an error message is raised. To ensure that active employees don't have inactive related
users during the validity of the new Job Relationships record, a warning message is raised.
• To ensure that the start date as well as adding or deleting records can't be done together in one step. The start
date must be moved first and then the grid records can be changed afterwards.
• To ensure that an employee can't be their own manager or other standard relationship type.
However, for custom relationship types, the system raises a warning rather than an error.
Forward propagation means that a change in the value of a field in an object is also made (“propagated”) to future
records for the same object. The forward propagation of this field change stops as soon as one of the future
records has a field value that is different than the original field value and does not stop at any gap. Field forward
propagation, however, stops at any gap between two existing records.
Forward propagation for Job Relationships is on by default in the system and cannot be switched off.
Note
If you add new records with information that is the same as in the existing records, the effective-dated records
aren't updated.
The default language is propagated to fields such as job classification. This means that the logon language is
not taken into account.
Note
For entities containing employment-based information, data is not propagated between employment records.
Example
There is a future change for an employee where they have a promotion consisting of a grade change already
entered into the system. They transfer into a new department 1 month before the promotion takes effect. The
change to the department should be made both before and after the date of the promotion.
Example
There is a future change for an employee where they have a promotion due to a transfer to a new division and
department including a grade change already entered into the system. Their location stays the same. They are
then moved into a different department and their location changed as a part of an office reorganization 1 month
before the transfer/promotion takes effect. The change to the department and location should be made before the
promotion/transfer and the department change will stop correctly for the promotion/transfer however the location
change will continue to be propagated.
Example
There is a future dated change where an employee is changing location and departments. The location is changed 1
month before the department change takes effect. You should make the change to the location before and after the
transfer of the department, because it is not done by forward propagation.
Forward propagation means that a change in the value of a field in an object is also made to future records for the
same object. Field forward propagation, however, stops at any gap between two existing records.
Forward propagation for Job Information is on by default in the system and cannot be switched off, except for
imports, APIs, and Off Cycle Event Batch job where it is optional.
Here is some additonal information about the fields that are not forward propagated for Job Relationships. This
means, that a change to these fields is not made to future records.
allow-delete
created-on
created-by
end-date
item-id
last-modified-on
last-modified-by
start-date
wfConfig
The "last updated" by source information is provided on records created or changed using business processes or
input channels running on Centralized services. For other changes, the information is not available and the field is
not shown on the UI.
The system shows through which business process the last change was made, for example, imports or transferring
direct reports. This source information can help explain why records are created by a user who does not have direct
permission for this change.
Last Modified source details are shown for the following records:
• Job Information
• Job Relationships
• Compensation Information
For records not saved using a process enabled on Centralized services, the system still shows which user last made
changes on which date.
If two users attempt to edit the same record at the same time, the system 'locks' one person out of saving their
changes.
If two users are editing a record at the same time, it becomes a case of “first change wins”. That is, the first user’s
changes are applied, but the second user receives an error message. The second user then has to refresh the
screen and submit their changes again when the first user is finished.
This restriction is called optimistic locking. It ensures that no conflicting changes can be made at the same time.
Learn the configurations and behaviors of Employee Central entities in the latest People Profile experience.
People Profile, your main entry point to Employee Central, is redesigned. It now features Profile Preview, Spotlight,
and Full Profile. While most Employee Central entities function similarly in both the legacy and latest People Profile,
there are a few important behavioral changes to note when you enable the latest version.
Note
The redesigned Editing UI and History UI are not available yet in the latest People Profile. To edit data or access
the History UI, users will be redirected to the legacy experience.
Compensation Information (including Recurring and Non-Recurring Pay Components) [page 194]
Here is a little more information about some of the changes to Compensation Information, Recurring Pay
Components, and Non-Recurring Pay Components in the latest People Profile experience
Here is a little more information about some of the changes to Personal Information in the latest People Profile
experience.
There are a few differences between the legacy and latest People Profile:
Logic to display fields on block or card Displays all fields, including empty fields. • If Global Information is unavailable,
the card displays first 5 non-empty
fields of Personal Information.
• If Global Information is available,
the card displays first 4 non-empty
fields of Personal Information and
up to 3 country/region entries from
Global Information.
Field grouping on details UI Fields are not grouped. Fields are grouped into two sections on
the details UI:
Alternative fields Some HRIS elements have alternative If an onView rule is set to change a
fields, for example, addresses and ad- field's attribute, it also changes the at-
dresses in alternative languages. If an tribute of the corresponding alternative
onView rule is set to change a field's field.
attribute, it doesn't impact the attribute
of the corresponding alternative field.
Here is a little more information about some of the changes to Biographical Information in the latest People Profile
experience.
There are a few differences between the legacy and latest People Profile:
Here is a little more information about some of the changes to Addresses in the latest People Profile experience.
There are a few differences between the legacy and latest People Profile:
Alternative fields Some HRIS elements have alternative If an onView rule is set to change a
fields, for example, addresses and ad- field's attribute, it also changes the at-
dresses in alternative languages. If an tribute of the corresponding alternative
onView rule is set to change a field's field.
attribute, it doesn't impact the attribute
of the corresponding alternative field.
Here is a little more information about some of the changes to Contact Information in the latest People Profile
experience.
There are a few differences between the legacy and latest People Profile:
Permissions Users must have both Email Information Users can view business emails when
and Business Email permission to view
they have the view permission for Busi-
business emails.
ness Email. Email Information permission
is not required to view business emails.
Here is a little more information about some of the changes to Emergency Contacts in the latest People Profile
experience.
There are a few differences between the legacy and latest People Profile:
Permissions Users with view permission for Emer- These users can access the information.
gency Contacts but not for Addresses
cannot access the address information of
an emergency contact.
5.6 Dependents
Here is a little more information about some of the changes to Dependents in the latest People Profile experience.
There are a few differences between the legacy and latest People Profile:
How section titles are defined Titles are fixed and cannot be changed by Titles are defined in BCUI.
customers.
How onView rules work • onView rules that are bound to the • onView rules that are bound to the
personRelationship element personRelationship element
only work on the quick view page, work on both cards and the details
not on the details UI. UI.
• onView rules that are bound to de- • Rules can change field values and
pendent’s child elements don't work attributes of the parent element
consistently. personRelationship and of
child elements.
• onView rules bound to dependent’s
child elements don't work.
Alternative fields Some HRIS elements have alternative If an onView rule is set to change a
fields, for example, addresses and ad- field's attribute, it also changes the at-
dresses in alternative languages. If an tribute of the corresponding alternative
onView rule is set to change a field's field.
attribute, it doesn't impact the attribute
of the corresponding alternative field.
Here is a little more information about some of the changes to Job Information in the latest People Profile
experience.
The Job Information card shows data about the organzation that an employee is assigned to, details about their
current job, as well as any time-related information (if Time Off is enabled in the system). Each of these 3 can be
shown or hidden as needed. It is also possible to configure separate help texts for them.
There are a few differences between the legacy and latest People Profile:
Navigation Links You can navigate from the Position field The latest People Profile does not sup-
to Position Org Chart as well as Perform- port this feature.
ance Management Form field to Perform-
ance Management form document.
Employee Status field The Employee Status field is shown at the The Employee Status field is shown as
top of the Job Information block. first field in Job Information section on
full Details page.
Related Information
Job Data
Time Information
Showing or Hiding Full Profile Cards
Configure mappings from Internal Job History to the Work Experience card so that the internal career history of an
employee is displayed on the Work Experience Spotlight card.
Prerequisites
Context
The Work Experience card on Spotlight shows a timeline of internal and external work experience for employees.
Please be aware of the following:
• Person-based: These work experience records are specific to a person, not a user. So if users have permission
to view the records for one assignment of a person, they can view the records for all assignments of the person.
• Data sources: This card uses field mappings to display data from two sources: custom background elements
and Internal Job History.
Complete this task to display Internal Job History on Work Experience card.
Field-level mappings from Internal Job History to the Work Experience card are predefined as follows:
start-date startDate
end-date endDate
job-title jobTitle
department department
company company
location location
Procedure
Tip
Only the rules of Display Internal Job History rule scenario are shown. If you want to create another rule,
choose the "+" button.
• Enable Mapping: decide if you want to enable the mapping right now.
4. Save the changes.
Results
You've created mappings. If you've enabled a mapping, the source data will be displayed on the Work Experience
card.
Next Steps
To allows users to view the data from Internal Job History on Work Experience card, grant target users the User
Permissions Employee Central Effective Dated Entities Job Information Actions (View Current) permission.
Please note that field-level permissions for Job Information are not applicable.
Here is a little more information about some of the changes to Work Permit Info in the latest People Profile
experience.
There are a few differences between the legacy and latest People Profile:
Viewing work permits of users with con- Enabling the setting Keep the Work Enabling the setting Enable Person-
current employments (CE users) Permit block in People Profile user-based Based Work Permits in Latest People
allows all users (not just CE users) to Profile for Concurrent Employment allows
view only work permits associated with CE users to view work permits associ-
their current employment. ated with all their employments.
Here is a little more information about some of the changes to Job Relationships in the latest People Profile
experience.
There are a few differences between the legacy and latest People Profile:
Field Order Job relationships are listed in random or- There are no links to the Org Chart or
der by the system. Performance Management forms.
Related Information
Job Data
Here is a little more information about some of the changes to Compensation Information, Recurring Pay
Components, and Non-Recurring Pay Components in the latest People Profile experience
There are a few differences between the legacy and latest People Profile:
Compensation Information Appearance of Amount and Amount and Currency are dis- The currency is now included
One-Time Payments Currency fields played as separate fields. with the Amount value.
Recurring Pay Components Value Rounding and Decimal For the value in the Amount For the Amount and
Non-Recurring Pay Compo- Places and Calculated Amount fields Percentage fields in recurring
nents in recurring pay components pay components and non-re-
and non-recurring pay com- curring pay components, the
ponents, the system rounds system rounds the values
the values based on the based on the Max Fraction
Max Fraction Digits setting Digits setting for the relevant
for the relevant pay compo- pay component in Manage
nent in Manage Organization, Organization, Pay and Job
Pay and Job Structures or Structures or for the pay
for the pay component value component value (Amount)
(Amount) field in Manage field in Manage Business
Business Configuration. If no Configuration. If no setting is
setting is found, the system found, the system default is 3
default is 3 decimal places. decimal places.
Compensation Information Pie chart for pay component The pie chart for pay compo- Users can visualize the pay
groups (PCG) nent group (PCG) showing pay component groups and pay
components did not exist. components that make up
an employee's compensation
package.
Compensation Information Info icon for Pay Component The Info icon (question mark) No Info icon is shown, but in-
Group, Compa Ratio, and is shown next to value that stead the value is shown in
Range Penetration indicates that there is more blue indicating that there is
information about the calcu- more information. The user
lation details/formula of the has to select the value for fur-
value. ther details about the calcula-
tion details/formula.
Compensation Information Compensation Widgets Depending on a user's permis- The Compensation Widgets
sions, three widgets were dis- are not included in the Full
played in the Compensation Profile view.
Information block:
Compensation Information Generating Compensation In- If enabled, you can select If enabled, you can select
sights to have AI-generated insights to have AI-generated insights
into an employee's compen- into an employee's compen-
sation when using Joule or sation when using Joule or
from the Compensation Infor- from the Tips proposed from
mation block in the Profile. the Compensation Informa-
tion tab.
Related Information
Compensation
Employee Central Compensation
Business rules are a way to add application logic to determine the outcome of a change made to particular data in
the system. This means that business rules can be set up to trigger certain actions when data is added, changed, or
deleted from the system.
You can also set up business rules in Employee Central. Rules follow the logic 'If this data is changed in a certain
way, then the system reacts in this way', for example, when changing a specific field or saving the Job Information
for a newly hired employee.
The system also has rule scenarios to help configure the business rule in the correct way for certain scenarios.
For example, for a rule for a hire or rehire, the rule scenario restricts the base object to only either Employment
Information or Employment Information model. This helps avoid issues later.
You can use rule contexts. A rule context refers to the specific situation or condition in which a rule is applied, such
as during data operation or import. A rule scenario, on the other hand, defines the sequence of rule parameters
and the objects available for use in the rule. In other words, a rule scenario provides the framework for the rule to be
executed, while a rule context determines when and how the rule is applied.
Note
However, hiding all fields in a card using a business rule is not supported and will potentially cause
unexpected behavior in the system. You must have at least one field on this object enabled to avoid
inconsistent behavior.
Note
Business rules only work for HRIS elements and MDF objects. Elements for the Employee Profile such as
standard and background elements are not supported.
Rule scenarios help you create rules correctly, based on the rule context and parameters for a given scenario.
Generate Assignment ID External You can use this scenario to create rules that generate the
value for Assignment ID External based on MDF Sequence ob-
jects. Create a single rule only based on this scenario. For more
information, refer to the Assignment ID topic in the Implement-
ing Employee Central Core guide on the SAP Help Portal.
Generate Employee ID for Hire/Rehire You can use this scenario to create rules that generate an Em-
ployee ID from the Metadata Framework (MDF) Sequence and
assign it to the User ID field of the Employee Information ob-
ject during the Hire/Rehire with new employment process. You
must first register the rule for the Hire/Rehire Configuration
object. If you have enabled the Onboarding feature, you must
also register the rule for Onboarding Configuration object.
Trigger Rules for Hire/Rehire You can use this scenario to create rules for the Hire/Rehire
process using the Employee Information or Employee Informa-
tion Model base object. In Manage Business Configuration,
rules created using this scenario can be used for all event
types.
Trigger Event Reason Derivation You can use this scenario to create rules that derive the event
reason for Job and Compensation Information Models.
Generate Employee Central Alerts You can use this scenario to create rules that generate Em-
ployee Central alerts for HRIS Elements. In Manage Business
Configuration, rules created using this scenario can be regis-
tered only for the saveAlert event type.
Enforce New Employment for Rehire You can use this scenario to create rules that validate business
requirements for rehire with new employment and display an
error message if the conditions are not met.
Trigger Workflows You can use this scenario to create a rules that trigger work-
flows to approve data changes. In Manage Business Configura-
tion, rules created using this scenario can be registered only
for the onSave event type.
Display Internal Job History You can use this scenario to create rules to display the Internal
Job History on the People Profile page.
Validate HRIS Elements You can use this scenario to create rules that validate HRIS
Elements and display messages.
Calculate Full-Time Equivalent You can use this scenario to create rules that calculate the
full-time equivalent for a user using the base object Job Infor-
mation Model.
Trigger Cross-Entity Rules You can use this scenario to create rules that make changes to
a target object based on the source object.
Trigger onPostSave Events for Job Information You can use this scenario to create rules that trigger events
after changes to Job information are saved. In Manage Busi-
ness Configuration, rules created using this scenario can be
registered only for the onPostSave event type.
Trigger onChange Rules for HRIS Elements You can use this scenario to create rules that trigger changes
to HRIS Elements. In Manage Business Configuration, rules
created using this scenario can be registered only for the on-
Change event type.
Trigger onSave Rules for HRIS Elements You can use this scenario to create rules that save changes to
HRIS Elements. In Manage Business Configuration, rules cre-
ated using this scenario can be registered only for the onSave
event type.
Trigger onInit Rules for Hire/Rehire You can use this scenario to create rules that initialize HRIS
Elements during all Hire/Rehire processes (for both old and
new employment) using the Employee Information Model base
object. In Manage Business Configuration, rules created using
this scenario can be used only for the onInit event type.
Trigger onView Rules for HRIS Elements You can use this scenario to create rules that defaults the value
for a field or change field properties or calculate fields that are
transient (this means that the result is not a fixed value stored
on the database but is calculated during rule execution when
the user calls up the page). In Manage Business Configuration,
rules created using this scenario can be used only for the on-
View event type.
Trigger an Off Cycle Event Batch You can use this scenario to create a rule for an Off Cycle Event
Batch object using Job Information Model or Employment De-
tails Model as the base object. This rule is executed during the
Off Cycle Event Batch Processing Job.
Trigger Event for Off Cycle Event Batch You can use this scenario to create rules with the Execute op-
eration for an Off Cycle Event Batch object using Job Informa-
tion Model or Employment Details Model as the base object.
The rule is executed during the Off Cycle Event Batch Process-
ing Job.
Rule Scenarios
Example Business Rules for Compensation
Rule Scenarios Available in Position Management
Rule Scenarios for Time Off
Business rules are very important to keep business processes running, so making sure they are configured
correctly is key. You can improve the system performance during rule execution by following some guidelines.
Less is more
Before you create a new rule in the system, check the existing rules to see if any can be tweaked to cover any new
business requirement.
For example, if you need to default a value on the Job Information of the new hire process. Before immediately
adding a new business rule, perform a quick assessment to understand how best to configure the requirement.
Typically, there is at least one onInit new hire business rule that is already defaulting values on Job Information or
setting the visibility of existing fields. This existing business rule can be tweaked to add the new requirement rather
than creating a new one.
Remember that these rules are needed for to sustain long-running business processes and that customers don't
want to create a support ticket for everything that may go wrong. Try to create meaningful rules that are set up to
last.
Order Matters
For complex business rules, it may be unavoidable to have a scenario where 30, 40, or more onSave business
rules need to be configured. As the business rules begin to stack up, there may be performance issues with the
application when saving transactions. To reduce the impact, prioritize IF conditions so that the broader conditions
are processed first. For example, if you have a requirement that a field should default to a specific value for all union
employees in the USA, the first IF statement should be the condition that narrows down the criteria the most. This
allows the system to skip the subsequent IF conditions for non-US employees, therefore cutting down processing
time for the business rule. While this simplistic example will not show a performance improvement, for customers
with complex IF statement rules, the processing time grows exponentially.
• Combine business rules wherever possible. The system processes IF/ELSE IF statements faster than
processing multiple, separate business rules.
• Prioritize IF conditions.
• Access fields directly on the Base Object of the rule whenever possible, rather than navigating to another
object to access the field. The latter approach takes the system longer to process the condition.
Try to figure out ways to ensure that business rules don't need to be changed once set up.
Hire/Rehire Scenario
You can create rules that define the event reason according to what change is done to an employee’s data, so
that the system automatically selects the appropriate event reason. Depending on the event reason, the employee
status is updated, if necessary. These rules are for Job Information and Compensation Information only. For
transactions where the Save action is enabled on Centralized services, no status changing event reasons can be
derived for Job Information records.
You can create event reason derivation rules using business rules.
If you don’t create derivation rules, the user has to manually select the event reason from the UI every time the
user makes a change to the employee data that is linked to an event. However, this is time-consuming and more
error-prone, since the employee status depends on the event reason that is selected.
The Provisioning setting Enable Business Rules for Event Reason Derivation must be enabled. This means that the
fields Event and Event Reason are not displayed on the Manager Self Service (MSS) Take Action page. It will not
have an impact on the History UIs. When creating a business rule, we recommend that you select the Event Reason
Derivation rule scenario since this restricts the base objects and Set condition of the rule to avoid rule configuration
errors.
Tip
We recommend that you use the Event Reason Derivation scenario while creating a new rule.
Here are a few recommendations to configure business rules for event reason derivation:
• Check if the event reason field's value is null before setting it through the business rule. This avoids overwriting
the event reason accidentally.
• All onSave rules configured for an entity or element are evaluated. The value of the event reason set by the
rules is considered by system. Therefore, ensure that the rules are defined in an appropriate sequence. Event
reason derivation is triggered first, then HRIS element validation, and then workflow derivation is triggered.
Note
If the event reason derivation is divided into multiple rules, then once the Job Information rules are
processed, the system processes them in the same order as how they are assigned in BCUI.
Tip
We recommend to only configure one workflow derivation scenario-based rule in HRIS elements.
We recommend to only configure one event reason derivation scenario-based rule in Job Information or
Compensation Information.
• If the event reason is not set by a rule, the system issues an error and there is little that you can do to resolve
this situation. Therefore, it's a good practice to configure a rule that checks whether the event reason is null or
not and then set it with a default value (for example, Data Change) if it's null.
• If the event and event reason are selected, these values are saved regardless of whether an onSave rule tries to
overwrite the event reason.
Migrated Rules
If you had XML rules in your system, they are now migrated to business rules. They can be found in the list on the
Configure Business Rules page and contain the term "ERD_migrated_rule".
For any new event reason derivation rules, create them using business rules with the Event Reason Derivation rule
scenario.
Consider a case where both the Job Information and Compensation Information entities are processed on the
Manager Self Service (MSS) Take Action page.
1. The system tries to get the event reason set on the Job Information entity first. If it is set on the Job
Information entity, then the event reason is used.
2. If no event reason is set on Job Information, the system tries to derive the event reason set on the
Compensation Information entity. If it’s set, then the event reason is used.
3. If the system encounters a case where the event reason is neither set on the Job Information nor on the
Compensation Information entity, it raises an error message and this is displayed on the screen.
To find event reason derivation rules that have been created using the Basic scenario, you can run
the check All rules for event-reason derivation are assigned to an application-specific rule scenario
(EventReasonDerivationNoBasicRules) in the Check Tool. The check is available in Migration Tab Employee
Central Core: Rules . Based on the results, you can then choose the next step to automatically migrate the eligible
rules to the Event Reason Derivation rule scenario. There's no impact on the working of the rules post migration.
Related Information
You can create business rules to define conditions that should be met before a specified workflow is triggered for
an object when an event or data change is added to the system. For more information, refer to Triggering Workflows
with Business Rules.
Rule Handling for Event Reason Derivation and Workflow Derivation Rules
The system processes the onSave rules based on the order defined in the Manage Business Configuration with the
exception that the rules configured for event reason derivation and workflow derivation from the rule scenarios are
executed after all the other rules are executed.
For rules for Personal Information, where event reason derivation is not applicable, National ID rules are executed
first and Workflow Derivation rules are executed last.
For Employee Central objects, the base object defines what you can enter in the rule; for example, to set field
properties, you have to choose a Model base object. At the same time, the base object defines what event types you
can use in a later step when you assign the rule to the Employee Central object in the data model. For example, you
cannot use onView events for changes done on the Add New Employee screen.
Here's an overview of how base objects, events and pages in the system belong together:
Employee Files • Changing a field value (see onChange event) Employee Central Object (Person or
Employment • Saving a page (see onSave event) Employment Object)/[Employee Central
Information/Personal • Viewing a transient field (see onView event) Object] Model
Information
For example:
• Compensation Information
• Compensation Information Model
• Job Information
• Job Information Model
• Dependents Model
Note
Select a Model base object to set
field properties in the rule (for more
information, refer to About Model Base
Objects [page 204]).
Add New Employee • Opening a page (see onInit event) Employee Information/Employee Details Model
• Changing a field value (see onChange event)
• Saving a page (see onSave event) Note
Select Employee Details Model to set
field properties in the rule (for more
information, refer to About Model Base
Objects [page 204]).
Manage Organization, • Opening a page (see onInit event) Foundation object, for example:
Pay and Job Structure
• Changing a field value (see onChange event) • Location
• Saving a page (see onSave event) • Event Reason
Note
• Hidden fields
• Foundation Objects
Related Information
Understand which field properties you can use for Employee Central model base objects.
For Model base objects, you can set the following properties:
• Required
• Visibility
• Previous Value
• Value
• Required
You can make a field required or not by entering true or false accordingly.
Fields that are required in the data model should not be set to 'not required' in the rules. This would lead to
errors. Here is a list of the required fields you should not override using rules:
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
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
externalCode
status
• Visibility
You can enter the following values:
• both: Field is visible and editable.
• view: Field is read-only.
• none: Field is not visible on the user interface.
• Previous Value
Use this property when you want to compare an old value with a new value, for example, when a rule is
triggered only when a certain value is changed to a new value. You can also define that any data change to a
specific field triggers the rule by setting up the rule as follows:
New value is not equal to previous value
For example: FTE.Value is not equal to FTE.Previous Value
Note
When you use Previous Value in the THEN condition, do not use Set as output type; it will be ignored by the
system, as you cannot change a previous value using the previous property.
• Value
Use this property when you want to combine setting field properties with setting default or conditional values.
When you select Value, you have to select the corresponding value in the dropdown menu when creating the
rule.
Note
We do not recommend having dependencies between Set commands in the same rule. The dependent Set
command is unaware of the changes made by previous Set commands in the same rule. If you require
those dependencies, we recommend that you split the rule.
The field type defines which function you can select in a business rule for a certain field. For Employee Central
objects, this field type differs from the Employee Central object data type for the different HRIS elements.
Here is a mapping of the Employee Central object data types to the business rule field types, where the column
defines the following:
• Employee Central Object Data Type: This is the data type that you can find in the Data Object Tables in
Employee Central guide. This is based on the database field data type.
• Business Rule Field Type: This is the field type that is used on the Configure Business Rules page.
• Manual Entry Value for Field Type: This defines what the user can enter or choose from on the Configure
Business Rules page.
Employee Central Object Data Type Business Rule Field Type Manual Entry Value for Field Type
(Foundation object, for example: Value Dropdown list for user to select from
department, division)
(Enum, for example: Gender, which has a Enum Dropdown list for user to select from
picklist)
Find out which rule event you can use for a rule that you want to be triggered by a user action on a certain page in
Employee Central. The following table gives an overview of the relationship between events and pages on the user
interface in Employee Central.
• Edit • Edit
• Edit • Edit
• Edit • Edit
• Personal Infor- • Employment
mation Information
Note
The Termi-
nate ac-
tion does
not supprt
onView
rules.
There are different event types for HRIS element and HRIS fields in business rules. Events define which user action
in the system triggers rule execution.
Note that the base object you've selected for creating a rule restricts which event you can choose.
Use this
Rule is triggered event Assign the rule event
when... type: to: Use this event to:
Page is loaded onInit HRIS element Set field properties (for example, making fields mandatory, or
hiding fields), or to default values that you want to be shown as
soon as the user calls up a page.
Note
OnInit rules work only in Hire/Rehire scenarios and for
foundation objects (in Manage Organization, Pay and Job
Structures). Since these rules are for new hires, they do
not work for existing users.
Page is saved onSave HRIS element Validate user entries when the user wants to save the changes.
Field value is changed onChange HRIS field Trigger rules as soon as the user changes a field.
Note
Beware that onChange rules are not supported for hidden
fields, except for Employee Central Quick Actions.
Page with transient field onView HRIS element Default the value for a field or to change field properties.
is loaded
Calculate fields that are transient (this means that the result
is not a fixed value stored on the database, but is calculated
during rule execution when the user calls up the page).
Note
Check the Behavior for onView Rules section after the
table.
Change to relevant em- saveAlert HRIS element Send alerts to remind users of coming system events.
ployee records is saved
Only for these elements:
• Compensation Information
• Recurring Pay Components
• Non-Recurring Pay Components
• Job Information
• Employment Details
• Global Assignment
• Work Permit Information
After changes to an ob- onPostSav HRIS element Trigger events for Intelligent Services.
ject have been saved e
Note
Since onPostSave rules are triggered after an entity is
changed, if field values are compared, please note that the
previous value is now the current value.
Note
Setting up business rules in the system can be tricky. Here are some answers to common questions to help you
avoid any issues that may arise.
Assign rules to all HRIS elements You can assign rules only to HRIS ele- You cannot assign rules to the
ments contained in the Succession Data userAccountInfo HRIS element.
Model, the country/region-specific Suc-
cession Data Model, or the Corporate
Data Model.
Assign more than one rule for the same Yes, you can assign several rules for the Not applicable
HRIS element or HRIS field same HRIS element or HRIS field in the
data model.
Use correct base object Use the current correct entity for the Do not add additional base objects as
base object. parameters in the rule to access other
elements in the same rule. To do this, add
Rules with Employee Information and
it to the If condition.
Employee Information Model are trig-
gered only during new hire flow.
Create cross-entity rules Cross-entity rules can set values for Do not create new Compensation Infor-
mation records using cross-entity rules.
fields in a different entity. Currently it is
supported only for specific employment-
related entities.
• Job Information
• Compensation Information
• Employment Information
• Job Relationships
• Pay Component Recurring
• Pay Component Non-Recurring
Use rules to set field properties You can set field properties only with: Do not use an OnSave rule to set field
properties.
• OnInit rules - to default field proper-
ties during new hire flow
• OnChange rules - to change field
properties based on value from a
field
• OnView rules - to hide fields in read-
only mode of the card.
Use rules to set valid field properties You can use rules to change two field Not applicable
• true
• false
Note
You can't set values for fields of a
Foundation Object.
Create country/region-specific rules Yes, you can create country/region-spe- Not applicable
cific rules. The country/region-specific
fields are listed under the corresponding
Employee Central object, preceded by
the country/region code (for example:
IND for India).
Note
For onSave and onInit rules, rules for
the base model and the Country/Re-
gion-Specific Succession Data Model
are triggered when conditions for
those triggers are met, meaning that
both rules for the base model and
the country/region-specific fields are
triggered. In cases where a field in
the base model does not have an ex-
plicit rule assigned, then the system
takes the rule trigger from the base
model. In cases where a field in the
Country/Region-Specific Succession
Data Model does not have an explicit
rule assigned, then the system takes
the rule trigger from the base model.
Assign a rule in the Succession Data Yes, you can assign a rule to the same Not applicable
Model, and then a rule for the same field HRIS field or HRIS element once in the
or the same element in the country/re- Succession Data Model, and another rule
gion-specific Succession Data Model in the Country/Region-Specific Succes-
sion Data Model.
Use pay component group sums in rules A pay component group sum is the total Not applicable
amount (sum) of the pay components
that are part of a specific pay component
group. You can use pay component group
sums in rules, for example, to perform
calculations.
Rules for recurring pay components Not applicable Do not create OnChange rules for recur-
ring pay components of type number to
change the visibility of individual fields.
Set value of position and position entry By default, the system always expects Not applicable
date fields during rehire the user to select value for position field,
and then the position entry date will be
calculated in the code.
Set onSave rules in the jobinfo ele- Not applicable If you set the event reason through an on-
ment Save rule, ensure that the expected event
reason has been set before the workflow
derivation rules are executed. This is to
make sure that the correct workflow will
be triggered.
Create rules for alerts You can create alerts to be triggered for If you use Employee Information as the
dates for certain events, for example, be- base object, note that the system can
fore a contract expires. only read values for the fields of the same
entity only.
Use previous values in rules The previous value property is available Not applicable
for all fields when the base object is a
model object.
Use country of company in rules Use the country listed in the Legal Entity Do not use the <country of company>
field, since this is stored in the database. field in the rule because it is a transient
field, meaning it is not stored in the data-
base.
Trigger rules for Person In the Business Configuration UI, there Not applicable
are 2 nodes for the Person entity,
Employee and Dependent. If a rule is con-
figured for the Person entity, it will not be
triggered in the system, due to the pres-
ence of the Employee node.
Use picklists in rules If you copy values from an MDF picklist to Not applicable
an Employee Central picklist, make sure
that the external codes on both sides
match.
OnInit rules OnInit rules work only in the new Hire Not applicable
wizard and for foundation objects (in
Manage Organization, Pay & Job Struc-
tures). Since these rules are for new
hires, they do not work for existing users.
Hire/Rehire rules We recommend using the Hire/Rehire For example, with Employment Details as
the base object, cross-entity rules cannot
rule scenario. This limits the base ob-
set values in another entity such as Job
ject to either Employee Information or
Information on the Add New Employee
the Employee Information model. This UI. You need to use Employee Informa-
ensures that all the objects involved in tion as the base object.
hire/rehire are available to the rule even
though they are not yet saved in the sys-
tem.
Operation in rules for Job Information Not applicable It is no longer possible to set up a busi-
ness rule that contains a CREATE or DE-
LETE operation on a Job Information re-
cord.
onChange business rule Not applicable The use of onChange business rules isn't
supported for foundation objects.
Run the Pay Scale Pay Increase back- The pay scale increase processes ONLY Don’t use any other rules, since they will
ground job two groups of rules not be triggered or executed.
Raise Smart Suite/Intelligent Services Use Job Information Model as the base You cannot use any other element as
events
object and assign the rule as an onPost- the base object, and you cannot assign
Save rule in the Succession Data Model. the rule as an onSave rule - the only sup-
ported event is onPostSave.
Troubleshooting
Here are some further tips to help you troubleshoot any issues with rules:
1. Enable the rule trace from the Admin Center, and make sure that the rule is actually triggered.
2. If the rule is not triggered, then check that it has the proper base object and that it is associated with correct
event.
Note
Remember that rules for Hire and Rehire must only use Employment Information or the Employment
Information Model as the base object.
3. Make sure no additional parameters are added to the rule that are used in one of the If/Set statements
4. Make sure that to group all If statements for Compensation Information before grouping the If statements for
Job Information.
5. If the rule is accessing other entities with navigations from Employment Details, make sure those other objects
are in the same object. For example, in case of new hires, other objects are not yet saved to the database, so
those navigations will not work.
6. If the rule sets values to other entities, make sure cross-entity rules are supported for those entities. As of now,
cross-entity rules are supported for employment-related entities only.
7. If the rule base object is Employee Information or Employee Information Model, those rules will be triggered on
new hire/rehire only.
11. Caution
We recommend that every rule is tested once it is created to ensure that it works as required.
12. In some cases, you may need to change the order in which rules are executed to ensure that the rule works as
required.
For employment-related HRIS entities only, you can set up rules so that when one entity is changed, the system
updates a related entity. These are called cross-entity rules.
• Job Information
• Job Relationship Information
• Compensation Information
• Recurring Pay Component
• Non-Recurring Pay Component
• Employment Details
• Termination Details
• Dependents Information (Latest People Profile only)
The source/target direction is very important. The source element must be the base object of the rule.
• Changes to Job Information (for example, company, location and/or, employee class) that then update
Compensation Information
• Changes to Job Information that then update Job Relationships
• Changes to Job Information (for example, pay scale level, FTE) that then change (create, update, delete)
Recurring Pay Components
• Changes to Compensation Information (custom field with annual salary) to update amounts in a Recurring Pay
Component
Addtionally, only Job Information supports cross-entity rules that create Generic Objects. It is also possible to have
cross-entity rules between Generic Objects, where they are trigger when changes are saved to the source object.
If the source entity is modified in the UI, API, or in an import, then onSave rules for cross-entity rules are supported.
For onChange rules, both entities must be selected in the Change Job and Compensation Information page in
Manager Self-Service UIs. Cross-entity onChange rules are not supported in APIs or imports.
If an object is changed based on cross-entity rules, then onSave rules are not triggered for that object (unless both
objects are visible on the card such as Compensation Information and Recurring Pay Components).
We do not recommend having multiple onChange rules for the same cross-entity pair.
OnChange rules are triggered recursively; that is, if the user changes field 1, and an onChange rule on field 1
changes field 2, then the onChange rules on field 2 will be triggered, and so on.
If you use event reason derivation, then the event reason for the target entity is inherited from the source element.
When the base entity is an entity that has no event reason field, the event reason must be set by the cross-entity
rule that creates the Job Information or Compensation Information record. Otherwise the event reason won't be set
by the system, which results in an error. The exception here is in cases where a fallback event reason is configured
for cross-entity rules with Job Information as the target element. The event reason is derived from the fallback,
which avoids errors.
If you do not use event reason derivation, then the event reason is always inherited from the event reason in the
source element. It cannot be manually added to the cross-entity rule.
Global Assignments
When adding, editing, or ending a global assignment, cross-entity rules with Job Information as source
element and Employment Information, Compensation Information, Recurring Pay Components, Non-Recurring
Pay Components, or Job Relationships as target element are supported for Job Information Home Assignment
records.
When adding, editing, or ending a global assignment, cross-entity rules with Job Information or Compensation
Information as the source element and Employment Information as the target element for Job Information Host
Assignment records are not supported.
Concurrent Employment
Cross-entity rules with Employment Information as the source element and Compensation Information, Recurring
Pay Components, Non-Recurring Pay Components, or Job Relationships as the target element are not supported
for Concurrent Employment.
Here is an overview of which elements support cross-entity rules to other elements when the rule expression is
configured with the Create operation.
Note
Job Information and Compensation Information as the target element do not support updates to existing
records. Cross-entity rules with Job Information or Compensation Information as the target must only use the
Set command, which always results in the creation of a new record. Do not use the Create command to create
a new record.
Target Element:
Target Element: Compensation Target Element: Target Element: Target Element:
Target Element: Job Relation- Information Recurring Pay Non-Recurring Employment
Source Element Job Information ships Component Pay Component Details
Job Information Not Supported Supported: Not Supported Supported: Supported: Not Supported
Job Relation- Not Supported - Not Supported Not Supported Not Supported Not Supported
ships
Compensation Not Supported Supported: Not Supported Supported: Supported: Not Supported
Information
• onSave • onSave • onSave
• onChange • onChange
Cau-
tion
We recom-
mend navi-
gating di-
rectly from
Compensa-
tion Infor-
mation to
the Recur-
ring Pay
Component.
Do not navi-
gate to Em-
ployment
Details and
then to the
Recurring
Pay Compo-
nent.
Recurring Pay Not Supported Supported: Not Supported Not Supported Supported: Not Supported
Component
• onSave • onSave
• onChange
Non-Recurring Not Supported Not Supported Not Supported Supported: Supported: Not Supported
Pay Component
• onSave • onSave
Employment Not Supported Not Supported Not Supported Not Supported Not Supported Not Supported
Details (Active
Employment)
Employment Not Supported Not Supported Not Supported Not Supported Not Supported Not Supported
Details and Ter-
mination Details
(Inactive/Termi-
nated Employ-
ment with Em-
ployment Infor-
mation as
Source Ele-
ment)
Employment Not Supported Supported Not Supported Supported Supported Not Supported
Details and Ter-
mination Details
(Inactive/Termi-
nated Employ-
ment with Job
Information as
Source Ele-
ment)
Here is an overview of which elements support cross-entity rules to other elements when the rule expression is
configured with the Set operation.
These rules are triggered based on changes made in the Take Action menu, History UI, Imports, and APIs.
Note
Job Information and Compensation Information as the target element do not support updates to existing
records. Cross-entity rules with Job Information or Compensation Information as the target must only use the
Set command, which always results in the creation of a new record. Do not use the Create command to create
a new record.
Job Relation- Supported: Not Supported Not Supported Not Supported Not Supported Supported:
ships
• onSave • onSave
• onChange
Cau-
tion
We recom-
mend navi-
gating di-
rectly from
Compensa-
tion Infor-
mation to
the Recur-
ring Pay
Component.
Do not navi-
gate to Em-
ployment
Details and
then to the
Recurring
Pay Compo-
nent.
Employment Not Supported Not Supported Not Supported Not Supported Not Supported Supported:
Details (Active
Employment) • onSave
• onChange
Employment Supported: Not Supported Not Supported Not Supported Not Supported Supported:
Details and Ter-
mination Details • onSave • onSave
(Inactive/Termi- • onChange
nated Employ-
ment with Em-
ployment Infor-
mation as
Source Ele-
ment)
Rules Using the Set Expression for Dependents Information (Latest People
Profile only)
Here is a general overview of which elements support cross-entity rules to other elements to delete records. For
cross-entity rules, if a rule result deletes a record, then that record can’t be used to execute another rule.
Note
You cannot delete Job Information or Compensation Information records using the Delete function in a
business rule.
Target Element:
Target Element: Compensation Target Element: Target Element: Target Element:
Target Element: Job Relation- Information Recurring Pay Non-Recurring Employment
Source Element Job Information ships Component Pay Component Details
Job Information Not Supported Supported: Not Supported Supported: Supported Not Supported
Job Relation- Not Supported Not Supported Not Supported Not Supported Not Supported Not Supported
ships
Compensation Not Supported Supported: Not Supported Supported: Supported: Not Supported
Information
• onSave • onSave • onSave
• onChange • onChange
Cau-
tion
We recom-
mend navi-
gating di-
rectly from
Compensa-
tion Infor-
mation to
the Recur-
ring Pay
Component.
Do not navi-
gate to Em-
ployment
Details and
then to the
Recurring
Pay Compo-
nent.
Recurring Pay Not Supported Supported: Not Supported Not Supported Supported: Not Supported
Component
• onSave • onSave
• onChange
Non-Recurring Not Supported Not Supported Not Supported Supported: Not Supported Not Supported
Pay Component
• onSave
Employment Not Supported Not Supported Not Supported Not Supported Not Supported Not Supported
Details (Active
Employment)
Employment Not Supported Not Supported Not Supported Not Supported Not Supported Not Supported
Details and Ter-
mination Details
(Inactive/Termi-
nated Employ-
ment with Em-
ployment Infor-
mation as
Source Ele-
ment)
Employment Not Supported Supported Not Supported Supported Supported Not Supported
Details and Ter-
mination Details
(Inactive/Termi-
nated Employ-
ment with Job
Information as
Source Ele-
ment)
Add context to onSave and onChange rules in the Business Configuration UI to prevent triggering unnecessary
rules in a given context and to improve system performance.
Context
You don't have to add contexts to the rules. If no contexts are set, then the rules are triggered when the parameters
set in the rule are met. By adding a context, you restrict the situation where rules are triggered. This means that, all
rules aren't executed where rule contexts that are set to No.
These contexts are currently only for HRIS elements, not for MDF objects. The contexts are only for onSave and
onChange rules. If you select specific contexts, the rules will be exclusively triggered in the contexts checked. Rules
in all contexts not checked will be ignored. Rules in contexts that are not explicitly listed on the screen will be
triggered unaffected by any setting.
Note
Contexts only apply for onSave and onChange rules and do not apply for other types of rules (onView,
postSave, inInit, and so on).
For more information about the BCUI, refer to the Configuring Context for Business Rules in the Setting Up and
Using Business Configuration UI (BCUI) guide on the SAP Help Portal.
• Edit (MSS/ESS)
• History
• Imports
• Mass Changes
• Hire
• Onboarding
• Publish from Compensation Planning
• Report No-Shows
• Off Cycle Event Batch
• Termination
• API
Here are some recommendations for what situation the contexts are useful, for example:
The rules for Event Reason Derivation only make sense when making changes in ESS/MSS, so we recommended
restricting such rules to the ESS/MSS context by setting it to Yes while switching all other contexts to No.
If validation rules are only made for specific purposes such as in the context of Termination or New Hire, we
recommend setting only this exact context to Yes for such a rule.
The Edit (MSS/ESS) rule context is used for Global Assignment and Concurrent Employment.
This is supported
for inserting a new
record rather than
editing an existing
record.
Onboarding No No No No No
Promotion from No No No No No
Compensation
Planning
Note
The Onboarding rule context is applied on Onboarding data collection pages, for example, Personal Data
Collection page.
The Promotion from Compensation Planning rule context is used so that the system can differentiate
promotions done from within Compensation (on-cycle promotions) from those done from Employee Central
(off-cycle promotions).
For onChange rules, find the relevant field and select the Details link. Scroll down to the Trigger Rules section
and select the Details link.
4. In the Details pop-up, ensure that the Event Type is either onSave or onChange.
5. Select the Plus (+) icon to add a context.
6. In the Rules Contexts section, for each context, select Yes or No from the drop-down list.
Only after you add context to the rule, the default for all contexts is Yes, which means that the rules would only
be triggered in those screens.
If you change the setting to No, that means that the rule is not processed in that context for the HRIS element.
7. Select Done to exit the pop-up.
8. Save your changes.
You can autofill employee data and position attribute values based on organizational and employment grouping
criteria. You can configure complex selection criteria to achieve conditional defaults. By autofilling default values,
you can reduce the overhead of manual data entries resulting in consistent and accurate data.
Context
As an administrator, you want to define selection grouping criteria and assign default values to group items,
eliminating the necessity of representing logical conditions in business rules.
Procedure
1. Configure the HRIS elements, MDF objects, condition fields, default fields, groups (employer, employee,
default) and their items.
2. Create business rules for default fields of objects (HRIS elements and MDF objects).
3. Assign business rules to objects and their condition fields.
Before you create and assign rules that set defaults, you need to change object definitions and enter configuration
data so that you can specify default values and the mappings between objects.
Prerequisites
• You've determined the base objects (HRIS elements and MDF objects) and default fields for which you would
like to implement conditional groups and defaults.
• You know the data type and data source of the condition fields that determine the values of the default fields.
Context
As an administrator, you want to assign role-based permissions so that you can configure objects (MDF objects,
Foundation objects, and Picklists) and enter configuration data for default fields.
Default fields for these entities (base objects) are supported: Position, Job Information, Compensation Information,
and Employment Details.
Procedure
1. Log on as an administrator.
2. Assign the relevant role-based permissions to access the HRIS elements, MDF objects, and their fields.
Remember
The supported data types are MDF objects, Foundation objects, and Picklists.
f. Choose Done.
4. Enter configuration data for all the objects.
Note
You can also import configuration data using the import function.
Remember
For each condition field, ensure that you've added a custom field of the same data type and
source either to the Employer or Employee group. For example, a condition field for Legal
Entity of type Generic Object, has to have the same data type and source as its custom field.
• Default Field
• For configuring Employer and Employee groups and entries in each group. These objects are used to
group users based on the conditional fields and can be reused for conditional defaults.
• Employer Group Items
• Employer Group
• Employee Group Items
• Employee Group
• For configuring multiple entries with default values for default fields based on Employer and Employee
groups.
• Default Group Items
• Default Group
You can configure only 15 condition fields for each group. For example, 15 for Employer Group, 15 for
Employee Group.
You could start with dependent fields so that you can then add them to a parent field. For example,
condition fields and group items.
c. Choose Save for each object.
Next Steps
You need to create business rules for the HRIS elements, MDF objects, and their condition fields.
Related Information
These examples illustrate the configuration data and mappings between condition fields and default fields.
The selection criteria for default fields is based on these two groups:
• Employer Group (ER): Comprises Legal Entity and Location as condition fields.
• Employee Group (EE): Comprises Employee Class and Employee Type as condiiton fields.
Employer Group
Default Group
Related Information
Using a business rule, you can set default values for object fields (HRIS elements and MDF objects), based on
organizational assignment and employment classification.
Prerequisites
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.
• You've configured the objects and condition fields that are used to set the default fields.
Context
As an administrator, you want to set the defaults for fields of type MDF, Foundation, and Picklist. Fields from these
entities (base objects) are supported: Position, Job Information, Compensation Information, and Employment
Details.
For example, MDF entities such as Paygroup and Payscale, Foundation objects such as Location and Pay Grade,
Picklists such as Employee Class and Employment Type.
Here's what you need to do to create a business rule that sets a default value:
Procedure
1. Log on as an administrator.
• For HRIS elements: Select the approriate rule scenario from the Employee Central Core category.
• For MDF objects: Metadata Framework Rules for MDF Based Objects
Note
SAP recommends that you select the Metadata Framework category for MDF objects.
For MDF objects, from the Purpose list, select a rule intent:
• Initialize: To initialize all the keys in the fields with default values.
• Evaluate: To assign values to fields based on other field values during the Save operation.
Remember
Business rules are set for the Initialize, onInit, and onSave events of base objects. And for onChange, and
Evaluate events of an object's condition fields.
6. Choose Continue.
7. For the If field, SAP recommends that you choose Always True.
8. For the Then field, choose the Set operation.
Note
Note
Ensure that you select the same default field chosen for the Set operation.
12. For the other function parameters, select Job Information if your condition fields are from JobInfo else select
Position.
13. Choose Save.
Next Steps
To activate your business rule, you must assign it either to a base object or its condition fields.
Related Information
After you create a business rule, you need to assign it to an object or its condition fields so that the rule is triggered
for an associated event.
Prerequisites
• You've configured the objects and their condition fields that are used to set the default fields.
• You’ve created business rules for the object fields that you want to default.
Context
As an administrator, you want to assign business rules to events of condition fields and objects of type MDF,
Foundation, and MDF Picklist.
Fields from these entities (base objects) are supported: Position, Job Information, Compensation Information, and
Employment Details.
Here's what you need to do to assign your business rules to base objects and condition fields:
Procedure
1. Log on as an administrator.
Business rules are set for Initialize, onInit, and onSave events of base objects. And for onChange and
Evaluate events of an object's condition fields.
7. Assign your business rules based on their pupose and choose Done.
• Initialize: In the Rules section, select your rule from the Initialize Rules list.
• Evaluate: For a condition field, choose Details and select your business rule from the External Code list in
the Rules section.
For HRIS Elements
Note
For the OnInit and onSave events, you need to enable your business rule at the object level in the Trigger
Rules section.
Results
The rule is triggered when the values of the condition fields are changed or the base object is initialized or saved.
Here are a few examples of how you can use business rules in your system.
General
Once rules are created, they must be assigned to the element in Manage Business Configuration and the trigger
event selected.
You can create objects that have multiple instances for the same entity for a given user, for example, Phone
Information, Email Information, National ID, Recurring Pay Component, and so on.
To create an entity (of those listed in the previous line) using cross-entity OnSave rules, use the "Create" function in
the Then condition.
Here is an example of how to create a Recurring Pay Component object in the OnSave rule on Job Information.
If the rule tried to navigate to a non-effective-dated object, for example, Email Information or Pay Component
Recurring, enter the value for the filter. A best practice here is to filter by primary key. If you don't enter the value
for the filter, it may not be clear which instance of the same object is updated.
You can create data for a custom MDF objects when saving changes to Job Information. This means that instead of
having to manually create the data for the custom MDF object in the Manage Data page, you can create a rule that
does the same for you.
Do not add additional base objects as parameters in the rule to access other elements in the same rule. To do this,
add it to the If condition using the default navigation provided in the Employment Details element that is available
for each Employee Central base object.
You can use OnInit rules to set field properties such as required=true or visibility=false based on some business
conditions. This is generally used in new hire flow with Employee Information model as the base object.
If you want to set properties for a field using an OnInit rule, it should be assigned as an OnInit rule for that element
only. If the requirement is to set field properties for fields from multiple elements, you need to create one OnInit
rule for each element, for example, Job Information and Compensation Information. You can use fields from other
elements in the If condition, that is valid, but you should not try to set properties for fields from other elements in
the rule.
You can set up the system to ensure that an employee receives the correction salutation and gender settings.
In the And/Or condition, you can set the system to check the combination of Salutation & Gender. If there is any
discrepancy, then an error message is displayed.
You can automatically set the employee retirement date based on the employee age & pay grade when the HR
admin saves the new hire data.
You can set a default Business Phone as primary phone contact information & set the default business phone
number for all employees during creation of business phone data. Only the extension would need to be provided as
an input for Business Phone during data maintenance.
This is an onChange rule for the <phone type> field in phone information model object.
You can set up the system to format a phone number, so that numbers beginning with 0, are formatted to begin
with (0).
The If condition uses the Matches() function to check whether the phone number entered matches the defined
format. The format is defined as any number that begins with 0. The asterisk indicates zero or more occurrences
of the preceding element. The Then condition firsts uses the Format() function to format the number using the
template. The template is defined as (0)%s. This is a string starting with (0), where (%s = a string.)
The Then condition then makes use of the Substring() function to define the end of the string (%s) from the
template. The phone number is the string that the substring is taken from. The substring starts at index 2. The
length is optional and should be left ‘Null’ as there may be different length phone numbers. The index of a sting is
the position of a character in the string. Strings start at index 1.
You can automatically set the job title based on the job code selection.
In this rule, we are setting the job title value in employee job information from the value from the job classification
object level.
This is an onChange rule for the <job classification> field in job information.
You can set the system to validate the data integrity of data at position object level against what is there for an
employee at job information level. If they are different, an error message is displayed.
You can use a cross-entity business rule to create a record in Job Information for every change in Job Relationship
information for a user.
You can use a cross-entity business rule to end recurring deductions as of the termination date.
Use OnView rules to control who can see which fields in the non-effective dated cards and ensure data protection
and privacy for your users, since you cannot use permissions to set field-level View permissions for such cards.
This is an example of an OnView rule that controls the visibility of the <Date of Death> field in the Biographical
Information for a permission group.
This is an example of an OnView rule that controls the visibility of the <Date of Death> field in the Biographical
Information for a user.
An example where, based on the Location of the employee, you change the Location Manager (matrixManager) of
that user in the Job Relationships section.
When a cross-entity rule deletes a record from an entity, the deleted record shouldn't trigger any rules.
For example, for changes made using Manager Self-Service, if a Job Information rule deletes the base salary
recurring pay component, then the the base salary recurring pay component shouldn't be allowed to execute any
other rule.
For example, there is an onSave rule for the recurring pay component, where the base salary recurring pay
component creates another recurring pay component for meal allowances.
This rule contains Employment Details as a rule parameter, which is a single entry, and navigates from Biographical
Information to Employment Details, which is expected to be a list.
This rule configuration includes Job Information and the supervisor’s Job Information too.
This rule configuration includes the Biographical Information of the parents and dependents.
Related Information
Human Resource Information System (HRIS) synchronization is a one-way sync of employee data from SAP
SuccessFactors Employee Central to SAP SuccessFactors Platform user data. This sync directly updates basic user
information in Basic User Data File and personal information in the Extended User Data File. SAP SuccessFactors
Platform then distributes this data to other SAP SuccessFactors products.
Caution
If Employee Central is enabled, do not change user data by importing User Data File. Doing so can overwrite
data coming from Employee Central and cause data inconsistencies.
Remember
All employee data in Employee Central, whether effective-dated or not, can be synced. If it's effective-dated
data and with an effective date in the future, it's synced when that date becomes the current date.
The following diagram demonstrates how data is synchronized from Employee Central to Platform user data and
then consumed by other SAP SuccessFactors products.
Employee Central is the core HR system that manages employee information throughout their lifecycle in an
organization. But for customers with Employee Central, some of their talent processes can't use personal and
employment information directly from Employee Central and still rely on user data files in Platform.
To simplify this process, HRIS Sync automatically updates Platform user data with data from Employee Central
based on the mappings between target fields and source fields.
Picklist Configuration for Employee Status and Job Relationship Type [page 285]
The picklists of employe status and job relationship type must have correct non-unique external codes
so that they are synchronized correctly. Data models, picklists, and validation rules are available in the
Software Download Center.
HRIS Sync can be triggered automatically by certain actions taken on the UI, or it can be kicked off due to a
scheduled job.
Remember
All employee data in Employee Central, whether effective-dated or not, can be synced. If it's effective-dated
data and with an effective date in the future, it's synced when that date becomes the current date.
Note
HRIS Sync only synchronizes data for active Employee Central users, that is, for whom the isECRecord value
is set to 1. But HRIS Sync will still be triggered in real time by UI operations for inactive users, as these are
considered manual corrections made to inactive users.
HRIS Sync is immediately triggered upon the following changes made to the Employee Central records through UI
operations (Employee Self-Service, Manager Self-Service, and new hire process):
• A record is changed and the record being updated is effective at that time.
• A future-dated record is synced when its effective date becomes the current date.
This method only syncs the data from the HRIS Element that you are updating.
As an administrator, you can set up an HRIS Sync job using the tool Manage Scheduled Jobs in the Admin Center.
HRIS Sync jobs can also be set up in Provisioning to either trigger a sync on a regular schedule or trigger a one-time
sync.
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.
If your company instance has a recurring HRIS Sync job, it will be triggered by the updates made to the Employee
Central data through data import or API operations. To view the status of the job request automatically created for
the HRIS Sync job, go to the Admin Center Scheduled Job Manager Job Scheduler tab.
Remember
An HRIS Sync job that is triggered by data import or API operations does not start immediately. Instead, it waits
a maximum of 10 minutes before starting. Only one HRIS Sync job can run at a time.
In this way, all data changes made through data import or API operations during the waiting time are
synchronized through a single job execution.
Parent topic: Human Resource Information System (HRIS) Synchronization [page 255]
Related Information
The data to be synchronized from Employee Central to Platform user data are based on the sync mappings from
HRIS fields to the standard or userinfo elements of Employee Profile. The mappings are either hard-coded or
configured in the Succession Data Model.
Note
If an Employee Profile field is defined as a target field in a HRIS sync mapping, the field is not editable on the
UI for Employee Central users because the data is synchronized from a HRIS field. Users needs to update the
source HRIS field to trigger the sync of updates. But non-EC users with relevant permissions can still edit the
Employee Profile field on the UI.
Parent topic: Human Resource Information System (HRIS) Synchronization [page 255]
Related Information
The system synchronizes some Employee Central data based on the hard-coded sync mappings from HRIS fields
to standard and userinfo elements.
To avoid unexpected behaviors, don't delete nor duplicate hard-coded sync mappings.
Recommendation
We strongly recommend that you do not override hard-coded HRIS Sync mappings in the Succession Data
Model. But if your business processes require the override, note the cautions and rules while adding custom
HRIS Sync mappings.
Parent topic: Human Resource Information System (HRIS) Synchronization [page 255]
Remember
HRIS fields with visibility="none" aren't synced. The rule applies to both hard-coded and custom sync
mappings. Exceptions are noted where relevant.
extension
User(Internal) is Active if
EMPLOYMENT_STATUS is
Active, Paid Leave, Unpaid
Leave, or Suspended. Else, the
user is Inactive. External us-
er's status will not be updated.
rel-user-id NA (delegate 1)
Remember
(picklist external_code - dele-
For future hires, only the
gate 1)
job relationships records
that are effective on the
rel-user-id NA (delegate 2)
hire date are synced.
(picklist external_code - dele-
gate 2)
Remember
To ensure consistent sync
of Corporate Addresses
for all countries and re-
gions, follow this hard-
coded mapping for coun-
try/region-specific config-
urations as well.
middle-name mi • Male
• Female
salutation salutation
• Unknown
suffix suffix • Undeclared
• Other
gender gender
Note
marital-status married
The system doesn't syn-
chronize values from the
field
genderCountrySpec
ific in the HRIS element
globalInfo.
To meet your organization's needs, you can add custom sync mappings and override some hard-coded sync
mappings in the Succession Data Model either by using the Business Configuration UI (BCUI tool) or in
Provisioning directly in the XML.
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.
After you've updated sync mappings, run an HRIS Sync job so that all current data is correctly synchronized or
make minor changes on the UI to trigger real-time sync for certain changes.
Configuring HRIS Sync Mappings in the Succession Data Model [page 279]
Edit the Succession Data Model from Provisioning to configure HRIS Sync mappings to your organization's
needs.
Syncing the Termination Date Between Employee Central and Standard User Fields [page 281]
Set up HRIS sync mapping between Employee Central and the standard user field <companyExitDate> so
that you can use the DRTM data purge function to purge inactive users from the system.
Parent topic: Human Resource Information System (HRIS) Synchronization [page 255]
Related Information
Learn about the HRIS elements that can be customized in HRIS Sync mappings and the conditions around their
sync logic.
Caution
To avoid issues in the system, do not map HRIS fields to the following standard elements:
• loginMethod
• managerId
• username
HRIS Element Included in Hard-Coded Sync Support Full Sync or Delta More Information
Mappings Sync
Recommenda-
tion
We recommend that you
map personal email and
business email to dif-
ferent Employee Profile
fields. If both email types
are mapped to the stand-
ard element email, the
last modified record is
synced.
Recommenda-
tion
To avoid data inconsisten-
cies, we recommend that
you map homeAddress
data to User Info ele-
ments and don't over-
ride the hard-coded
corporateAddress
mapping with the
homeAddress mapping.
Job Information (jobInfo) Yes Delta You can override the hard-
coded sync mappings only for
the following jobInfo fields:
• department
• division
• location
• job-title
To avoid sync issues,
don't override the hard-
coded mapping from job
title to title with a
mapping from the HRIS
field position to the
field title.
• location
corporateAddress
country
We only recommend that
you override the harded-
coded mapping of the
country field with the
mapping from the
jobInfo field
country-of-
company to the Em-
ployee Profile field
country. The value of
country-of-
company is derived from
the
countryOfRegistra
tion field in the Legal
Entity.
Note
Don't override the hard-
coded mapping from the
HRIS field manager-id
to the standard element
manager-id.
Remember
• If there're multiple
records of work per-
mits, for example,
work permits of sev-
eral document types,
only the last modified
record is synchron-
ized via HRIS Sync.
• If there're multiple
last modified records,
then the record with
the latest issue date
is synchronized.
Note
Don't set any value for the
entity-type attribute
in the HRIS Sync map-
ping because this attrib-
ute is irrelevant and will
be automatically set as
WorkEligibility. So
you can't use this attrib-
ute to sync data for a spe-
cific document type. The
system maps a source
field to a target field
regardless of document
types.
Related Information
When configuring your HRIS Sync mappings in the Succession Data Model, keep these points in mind.
Remember
HRIS fields with visibility="none" aren't synced. The rule applies to both hard-coded and custom sync
mappings. Exceptions are noted where relevant.
Caution
To avoid issues in the system, do not map HRIS fields to the following standard elements:
• loginMethod
• managerId
• username
• userId
• jobCode
• hireDate
Note
As a unique and stable identifier for each user in the system, User ID is not changeable. Therefore, configured
mappings to userId will be ignored during HRIS Sync and the data won't be synced.
• You can define multiple HRIS Sync mappings () in the Succession Data Model.
• Under <hris-sync-mappings>, you can define mappings for multiple HRIS elements (<hris-element-
ref>).
• For one HRIS element (<hris-element-ref>), you can define multiple mappings (<hris-mapping>) for its
fields.
• You can't define duplicate HRIS Sync mappings (<hris-element-ref refid>).
• Each HRIS field (hris-field-ref) can only be mapped to one standard element (standard-element-
ref), one userinfo element (userinfo-element), or one user-info-record-key.
• Don't map HRIS fields to transient fields of which the values are calculated in real time.
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"/>
<standard-element-ref refid="custom02"/>
</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>
Note
Enable the Edit role-based permission for the userinfo-elements that you've configured in hris-sync-
mapping. The sync process only pushes data into userinfo-elements with the Edit permission.
The entity-type attribute is used to specify the type of information to sync for the HRIS elements <hris-
sync-mappings>homeAddress, emailInfo, phoneInfo, and nationalIdCard. The entity-type attribute is
mandatory and the isPrimary flag is not considered by the HRIS sync of these entities.
The entity-type< attribute is optional for the nationalIdCard entity. If the entity-type attribute is not
specified for this entity, the isPrimary flag is considered when national ID information is being synchronized.
In this case, the system syncs the record with isPrimary=True.
In this example of custom sync mapping for the element emailInfo, business, personal, and other email
addresses are synchronized to different fields. The value of entity-type attribute is based on a predefined
picklist assigned to the HRIS field email-type. The system identifies which type of information to map based the
external code of the picklist option.
Sample Code
<hris-element-ref refid="emailInfo">
<hris-mapping entity-type="B" >
<hris-field-ref refid="email-address"/>
<standard-element-ref refid="email"/>
</hris-mapping>
<hris-mapping entity-type="P" >
<hris-field-ref refid="email-address"/>
<standard-element-ref refid="custom15"/>
</hris-mapping>
<hris-mapping entity-type="O" >
<hris-field-ref refid="email-address"/>
<userinfo-element-ref refid="cust_EmailAddress"/>
</hris-mapping>
</hris-element-ref>
All refid attribute values must be valid and must already be defined in the Succession Data Model or the
Corporate Data Model.
Dates
• You can only sync an HRIS field of date type to a standard element of string type.
• You can use the date-format attribute to define in which formats dates are synchronized . You can only use
the following date formats, which are case-sensitive:
• Year in four digits: yyyy
• Month and year: MMM-yyyy
• Month: MMM
• Day and month: dd/MMM
• Month, day, and year: MM/dd/yyyy
• The date-format attribute allows you to sync only parts of the date. This is an example of sync mapping that
only syncs the day and month, but not the year for birthday information.
Data Types
• If fields fail data type validation (for example, mapping string fields to date fields), the Succession Data Model
XML file can't be imported.
• You can map any data type to a string field.
• If the standard element being mapped is a picklist, the HRIS field must be a picklist or a foundation object or a
territory (country/region) object.
• If the HRIS field is a picklist, it must be mapped to a field that has an identical picklist id.
user-info-record-key
• The user-info-record-key is used by other modules that need additional information for integration.
• The user-info-record-key is stored in the user directory and is consumed only through API.
• The key values aren't displayed on any UI.
• You can enter any string value for the user-info-record-key in the Succession Data Model, so it isn't a
refid. Whatever value you use here is used as a key in the user directory.
Recommendation
We strongly recommend that you do not override hard-coded HRIS Sync mappings in the Succession Data
Model. But if your business processes require the override, note the cautions and rules while adding custom
HRIS Sync mappings.
You can override the hard-coded sync mappings by adding a custom sync mapping as follows. By default, the HRIS
field department is mapped to the standard element department.
Sample Code
<hris-element-ref refid="jobInfo">
<hris-mapping >
<hris-field-ref refid="department"/>
<standard-element-ref refid="division"/>
In this case, even though your custom mapping now is considered in sync, the hard-coded sync mapping is still in
place. To avoid mapping an HRIS field to two Employee Profile fields, you're recommended to override the mapping
of source field as well. For example,
Sample Code
<hris-element-ref refid="jobInfo">
<hris-mapping >
<hris-field-ref refid="department"/>
<standard-element-ref refid="division"/>
</hris-mapping>
<hris-mapping >
<hris-field-ref refid="company"/>
<standard-element-ref refid="department"/>
</hris-mapping>
</hris-element-ref>
Caution
To avoid data inconsistency, don't map multiple HRIS fields to the same Employee Profile field.
To avoid issues in synchronization, do not duplicate hard-coded sync mappings. The system prevents anyone from
adding duplicate sync mappings to the sync-mappings section of the Succession Data Model.
For example, do not add mappings as follows because the HRIS field department already has a hard-coded
mapping:
Sample Code
<hris-element-ref refid="jobInfo">
<hris-mapping >
<hris-field-ref refid="department"/>
<standard-element-ref refid="department"/>
</hris-mapping>
</hris-element-ref>
However, you can have the HRIS field department mapped to another standard element:
Sample Code
<hris-element-ref refid="jobInfo">
<hris-mapping >
<hris-field-ref refid="department"/>
<standard-element-ref refid="custom01"/>
</hris-mapping>
</hris-element-ref>
Related Information
As an administrator, you can use the admin tool Business Configuration UI (BCUI) to configure HRIS Sync
mappings as needed and view all custom HRIS Sync mappings.
You can configure HRIS Sync mappings in the following ways in the BCUI:
• In the HRIS Sync Mappings section, which is dedicated to HRIS Sync mappings configuration:
• View all custom sync mappings
• Add, edit, and delete custom HRIS Sync mappings for any available HRIS elements
• In an HRIS Element section, add, edit, and delete custom HRIS Sync mappings for a specific HRIS field.
Adding Sync Mappings in the HRIS Sync Mappings Section [page 277]
Using Business Configuration UI, you can add all custom sync mappings from HRIS fields to standard
elements, user info elements, or user info record key elements in a single screen HRIS Sync Mappings.
Related Information
Using Business Configuration UI, you can add all custom sync mappings from HRIS fields to standard elements,
user info elements, or user info record key elements in a single screen HRIS Sync Mappings.
Prerequisites
• You understand the rules of configuring sync mappings. For more information, see Rules for Configuring
HRIS_Sync Mappings.
• You have permissions to use the admin tool Manage Business Configuration.
• If the target field is a userinfo element, make sure that the field has been defined in the data model. For more
information, see Creating a User Information Field for People Profile with BCUI.
Procedure
Field Description
Target Field Type Specify the type of target field you want to map to.
Optional: Entity Type Specify the type of information. It's required only when
you're mapping the HRIS elements homeAddresses,
emailInfo, or phoneInfo to standard elements or user
info elements
Optional: Entity Entity name. It's required only when you're mapping
the HRIS elements homeAddresses, emailInfo,
phoneInfo to standard elements or user info elements
After you've updated the sync mappings, run an HRIS Sync job so that all current data is correctly synchronized.
Task overview: Configuring HRIS Sync Mappings in Business Configuration UI [page 276]
Related Information
Using Business Configuration UI, you can add sync mappings for a specific HRIS field in the HRIS Element screen.
Prerequisites
• You understand the rules of configuring sync mappings. For more information, see Rules for Configuring HRIS
Sync Mappings.
• You have permissions to use the admin tool Manage Business Configuration.
• If the target field is a userinfo element, make sure that the field has been defined in the data model. For more
information, see Creating a User Information Field for People Profile with BCUI.
Procedure
Information on the right side shows details for the selected element.
• To map the HRIS field to a standard field, specify the standard field.
• To map the HRIS field to a user info field, specify the user info field.
• To map the HRIS field to a user info record key, enter a key value.
Specify the type of information. It's required only when you're mapping the HRIS elements homeAddresses,
emailInfo, or phoneInfo to standard elements or user info elements. For example, the entity type for
homeAddress element must be any of these values: home, shipping, mail, and business. To know more on
allowed values for entity types, select any field from Standard Field or User Info Field field and do not provide
value for the entity type field. Upon saving, a message appears, which displays a set of allowed values.
7. Select Done and save your changes.
Next Steps
After you've updated the sync mappings, run an HRIS Sync job so that all current data is correctly synchronized.
Task overview: Configuring HRIS Sync Mappings in Business Configuration UI [page 276]
Related Information
Adding Sync Mappings in the HRIS Sync Mappings Section [page 277]
Edit the Succession Data Model from Provisioning to configure HRIS Sync mappings to your organization's needs.
Prerequisites
• You've downloaded the Succession Data Model data model file in Provisioning and have the file open for editing
in a data model editor.
• You understand the rules of configuring sync mappings.
• If the target field is a userinfo element, make sure that the field has been defined in the data model. For more
information, see Creating a User Information Field for People Profile with BCUI.
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.
Using the Succession Data Model data model, you can do the following:
Procedure
1. Find the last <view-template> tag section in your Succession Data Model data model.
The <hris-sync-mappings> elements begin right after the last view template end tag (</view-
template>)
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"/>
<standard-element-ref refid="custom02"/>
</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-element-ref>
...
<hris-sync-mappings>
Related Information
Set up HRIS sync mapping between Employee Central and the standard user field <companyExitDate> so that
you can use the DRTM data purge function to purge inactive users from the system.
Prerequisites
Context
HRIS sync mapping for the termination date is not hard-coded, so you have to map the relevant fields between
Employee Central and the SAP SuccessFactors Platform. If this sync is not set up correctly, the data purge function
cannot work correctly.
If the standard element <companyExitDate> is not present in your Employee Export file, it is not enabled in your
system and you cannot complete this task. You need to add this field to your system first.
If you do not have access to the Business Configuration UI in your system, you can also submit a request to Product
Support to have the following XML added to your data model in the Provisioning application:
Sample Code
<hris-element-ref refid="employmentInfo">
<hris-mapping >
<hris-field-ref refid="end-date"/>
<standard-element-ref refid="companyExitDate"/>
</hris-mapping>
</hris-element-ref>
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.
If you do not see <companyExitDate> in the search box, it is not enabled in your system. You need to add it
before you can complete this task.
6. Leave the Entity Type field blank.
7. Select Done and then save your changes.
Results
The effective-dated end date of an employment in Employee Central is now mapped to the user's company exit
date in the SAP SuccessFactors Platform. This ensures the employment end date in Employee Central is used to
calculate data retention times.
Next Steps
After the sync mapping is added, make sure that the user (userId) used for HRIS Sync is granted View and Edit
permissions for this field.
Related Information
Learn how the system syncs field values according to the data types or field types of source and target fields and in
which language the data is sent to Platform user data.
Foundation Object field String field The name (externalName) If the name is empty, only the
and code (externalCode) object code is synced.
of the object instance regard-
less of any language settings
Foundation Object field Picklist field Option ID of the picklist value If the externalCode of the
object instance can't be found
in the picklist options, the
mapping value to standard el-
ement is set to null. Other
fields of the record can still
sync successfully.
When you configure HRIS sync mappings for the HRIS elements homeAddress, emailInfo, phoneInfo, and
nationalIdCard in the Succession Data Model, the entity-type attribute is used to specify the type of
information. The <isPrimary> flag is not considered by the HRIS sync of these entities.
If there are multiple records with the same entity type, the system syncs the last modified record.
Note
The entity-type attribute is optional for the nationalIdCard entity. If the entity-type attribute is not
specified for this entity, the isPrimary flag is considered when national ID information is being synchronized.
In this case, the system syncs the record with isPrimary=True.
Country/Region-Specific
If the HRIS field is a country/region-specific field, sync country/region names to Platform user data.
If there is no value in an HRIS field, the null value is synchronized to Platform user data.
Parent topic: Human Resource Information System (HRIS) Synchronization [page 255]
Related Information
The picklists of employe status and job relationship type must have correct non-unique external codes so that
they are synchronized correctly. Data models, picklists, and validation rules are available in the Software Download
Center.
Employee Status
You must define the HRIS field emplStatus (Employee Status) as a picklist in the eventReason Foundation
Object in the Corporate Data Model.
We recommend that you use the predelivered picklist employee-status. The external codes of its picklist values
and the corresponding employee status are as follows.
Non-Unique External Code Employee Status in Em- Active or Inactive Employ- users_sys_valid flag in Leg-
ployee Central ment acy Table
A Active Active t
S Suspended Active t
D Dormant Active t
F Furlough Inactive f
R Retired Inactive f
T Terminated Inactive f
O Discarded/Obsolete Inactive f
You can change the label of the predelivered picklist values. But any custom external code is regarded as inactive in
user data tables.
Note
Job Relationships
You must define the relationship-type field in the jobRelationshipInfo HRIS element as a picklist in the
data model. To sync the relationship types correctly into user data tables, the dedicated non-unique external codes
for widely known relationship types are defined. The sync logic regards the non-unique external code for each
relationship type as a fixed value. The system runs different sync logic based on the non-unique external code.
The non-unique external code for each default relationship type is as follows.
hr manager HR Manager
delegate 1 Delegate A
delegate 2 Delegate B
Once the HRIS Sync is run, you can set up job relationships between employees in the system.
Note
Do not configure multiple picklist labels that point to the same external code.
Parent topic: Human Resource Information System (HRIS) Synchronization [page 255]
Related Information
You can create, manage, and monitor scheduled jobs for HRIS Sync using Scheduled Job Manager in the Admin
Center.
Consider running a job to sync HRIS data from Employee Central to user data tables in the following situations:
• You updated sync configuration in the data model and want the new configuration to be applied to all the data
including the existing data.
• There are data inconsistencies between Employee Central data and data in user data tables. Data
inconsistency could happen for several reasons including, in the past if basic import was used to upload data to
the user data tables.
Note
This is an SAP SuccessFactors Business Beyond Bias feature. Use it to support processes that detect, prevent,
or eliminate the influence of bias, helping you achieve your diversity and inclusion goals.
• Sync HRIS Data: synchronize data changes in Employee Central from a certain date.
• Sync HRIS Data for Specific Users: synchronize all Employee Central data about certain users
Before you schedule a job for HRIS Sync in the Admin Center, be aware of the maximum times that a HRIS Sync job
can run each day.
Sync HRIS Data for Specific Users 3 times combined regardless of occurrence types
Note
Creating a Job Request to Sync HRIS Data for Specific Users [page 292]
Create a job request with the Scheduled Job Manager tool to sync all Employee Central data about the
employees listed in an FTP file to user data tables.
Parent topic: Human Resource Information System (HRIS) Synchronization [page 255]
Related Information
Create a scheduled job request in Scheduled Job Manager to sync data changes from Employee Central to user
data tables.
Prerequisites
Context
Recommendation
To avoid data discrepancies, when an HRIS Sync job is running, avoid changing any user data through OData
APIs or any other operations. You can find all in progress HRIS Sync jobs on the Admin Center Scheduled
Job Manager Job Monitor page.
Note
The maximum times that the job can run each day in the Admin Center:
Procedure
Job Owner The job owner must be the person who created this job
request.
Remember
The job owner must be an active user. Otherwise, the job
would fail. If the job owner of a recurring job becomes
inactive, create a new job request.
Option Description
Sync Changes Since the Last Successful HRIS Sync Job: Sync the following data changes:
<date when the last HRIS Sync job ran>
• The records that have changed since the last successful
HRIS Sync job
• The future-dated records that become effective on the
day when the job runs
Sync Changes from a Specific Date Sync the following data changes:
• The records that have changed since the day you se-
lected
• The future-dated records that become effective on the
day when the job is run
Note
Select a date from the last 7 days and also before the
date when the last HRIS Sync job ran.
5. In the Job Parameters settings, select appropriate options for Automatic Manager Transfer.
All options are enabled by default to ensure that Performance Management and 360 forms are automatically
routed whenever the hierarchy of employees and managers changes.
Option Result
Automatic insertion of new manager as next document The new manager becomes a part of the review process and
recipient if not already the former manager is removed from any further accounta-
bility.
Automatic Inbox Document Transfer to New Manager All the documents are moved from the former manager's
inbox to the new manager's inbox.
Automatic En Route Document Transfer To New Manager All the documents are moved from the former manager's En
Route folder to the new manager's En Route folder.
Automatic Completed Document Copy to New Manager All the completed documents of the employee are moved
from the former manager's Completed folder to the new
manager's Completed folder.
Automatic Process Owner Change To New Manager For The process owner is automatically changed from the for-
In-Progress Documents When Old Manager is Process mer manager to the new manager, when the in-progress
Owner (Only for 360) forms are transferred to the manager.
Automatic Process Owner Change To New Manager For The process owner is automatically changed from the for-
Completed Documents When Old Manager is Process mer manger to the new manager, when the completed forms
Owner (Only for 360) are transferred to the manager.
6. In the Job Parameters settings, select appropriate options for Automatic Document Removal.
Remember
These options only apply to the users whose status changes from active to inactive during the
synchronization.
Option Result
Remove Inactive Employees' In-Progress Documents Delete all in-process documents from the inbox of inactive
users.
Remove Inactive Employees' Completed Documents Delete all completed documents of inactive users.
Remove Inactive Employees' 360 Evaluation Documents Delete 360 participant evaluation forms for inactive users.
7. In the Job Occurrence section, define how frequently you want the job to run.
Note
If you've selected the job parameter Sync Changes from a Specific Date, you should select the occurrence
option One-Time.
8. In the Notification section, define who receives email notifications besides the job owner.
9. To finish, choose one of two options:
• Choose Submit to save the job request and submit it to the job scheduler, so that the job is scheduled to
run at the specified time.
Next Steps
You can monitor and manage the job request in the Scheduled Job Manager admin tool. See Related Information for
details.
After the job is completed, two entries are displayed on the Job Monitor tab in Scheduled Job Manager in the
following order:
1. A job named Triggered by the Job Request <Your Job Request ID> of the job type HRIS Sync: this is an HRIS
Sync job in Provisioning triggered by your job request.
2. The job request that you created
Tip
You can find more information about the job progress in the run details of the triggered job Triggered by the Job
Request <Your Job Request ID>.
Related Information
Creating a Job Request to Sync HRIS Data for Specific Users [page 292]
Future Hires in HRIS Sync Jobs [page 296]
Managing Scheduled Jobs in Admin Center
Creating a Scheduled Job Request in Admin Center
Create a job request with the Scheduled Job Manager tool to sync all Employee Central data about the employees
listed in an FTP file to user data tables.
Prerequisites
Note
No more than 1000 user IDs are allowed in a single CSV file.
Recommendation
We recommend that you use an SFTP server for stability and security.
Context
Recommendation
To avoid data discrepancies, when an HRIS Sync job is running, avoid changing any user data through OData
APIs or any other operations. You can find all in progress HRIS Sync jobs on the Admin Center Scheduled
Job Manager Job Monitor page.
Note
This job can be scheduled to run a maximum of 3 times each day in the Admin Center. The daily execution
times are counted based on server time.
Procedure
Setting Description
Job Type Select the option Sync HRIS Data for Specific Users.
Job Owner The job owner must be the person who created this job
request.
4. In the Job Parameters settings, select appropriate options for Automatic Manager Transfer.
All options are enabled by default to ensure that Performance Management and 360 forms are automatically
routed whenever the hierarchy of employees and managers changes.
Automatic insertion of new manager as next document The new manager becomes a part of the review process and
recipient if not already the former manager is removed from any further accounta-
bility.
Automatic Inbox Document Transfer to New Manager All the documents are moved from the former manager's
inbox to the new manager's inbox.
Automatic En Route Document Transfer To New Manager All the documents are moved from the former manager's En
Route folder to the new manager's En Route folder.
Automatic Completed Document Copy to New Manager All the completed documents of the employee are moved
from the former manager's Completed folder to the new
manager's Completed folder.
Automatic Process Owner Change To New Manager For The process owner is automatically changed from the for-
In-Progress Documents When Old Manager is Process mer manager to the new manager, when the in-progress
Owner (Only for 360) forms are transferred to the manager.
Automatic Process Owner Change To New Manager For The process owner is automatically changed from the for-
Completed Documents When Old Manager is Process mer manger to the new manager, when the completed forms
Owner (Only for 360) are transferred to the manager.
5. In the Job Parameters settings, select appropriate options for Automatic Document Removal.
Remember
These options only apply to the users whose status changes from active to inactive during the
synchronization.
Option Result
Remove Inactive Employees' In-Progress Documents Delete all in-process documents from the inbox of inactive
users.
Remove Inactive Employees' Completed Documents Delete all completed documents of inactive users.
Remove Inactive Employees' 360 Evaluation Documents Delete 360 participant evaluation forms for inactive users.
6. In the FTP Configuration section, enter information about the server access and file access.
Note
Select None for the field Encryption because encryption is not required for this job type.
Note
Select the occurrence option One-Time because it's not necessary to sync data for specific users
recurringly.
8. In the Notification section, define who receives email notifications besides the job owner.
9. To finish, choose one of two options:
• Choose Submit to save the job request and submit it to the job scheduler, so that the job is scheduled to
run at the specified time.
• Choose Save to save the job request, but not submit it. Configurations are saved but the job isn't scheduled
to run yet.
Next Steps
You can monitor and manage the job request in the Scheduled Job Manager admin tool. See Related Information for
details.
After the job is completed, two entries are displayed on the Job Monitor tab in Scheduled Job Manager in the
following order:
1. A job named Triggered by the Job Request <Your Job Request ID> of the job type HRIS Sync: this is an HRIS
Sync job in Provisioning triggered by your job request.
2. The job request that you created
Tip
You can find more information about the job progress in the run details of the triggered job Triggered by the Job
Request <Your Job Request ID>.
Related Information
Future-dated records that have events such as Hire, Global Assignment, Start Pension Payout, or Start Contingent
Worker are considered as records of future hires.
All Job Information records of the future hires are synced when the HRIS Sync job is run. If there are multiple
records in a time period, the last Job Information record in the time period is synced.
Note
If users have active records of Job Information with the Start Contingent Worker event, their future-dated job
information is not synced when the HRIS Sync job is run.
Related Information
Note
Centralized services is an umbrella term for a collection of specialized services governing different processes in
Employee Central.
Imports
With Employee Data Imports, Centralized services work together to enable different HRIS entities to support
functions like business rules, identical record suppression, forward data propagation, and so on. Business keys are
validated to ensure that duplicate records are not allowed.
For more information about imports, refer to Centralized Services for Employee Data Imports.
Centralized services support saving changes on the Editing UI of a supported HRIS entity. To access the Editing UI
of a card in People Profile, you choose the icon (Edit).
Save on the Editing UI using Centralized services supports features such as employee data deletion, forward
propagation, and identical record suppression. Data validation, such as Earliest Date validation, is supported for all
effective-dated entities.
Save on the Editing UI of the following HRIS entities is supported by Centralized services:
HRIS Entity
Addresses
National ID
• Phone Information
• Email Information
• Social Accounts
Emergency Contacts
Dependents
Employment Details
Global Assignments
Work Permit
Centralized services support saving changes on the History UI of a supported HRIS entity. To access the History UI
of a card in People Profile, you choose the icon (History).
Save on the History UI using Centralized services supports features such as employee data deletion, forward
propagation, and identical record suppression. Data validation, such as Earliest Date validation, is supported for all
effective-dated entities.
Save on the History UI of the following HRIS entities is supported by Centralized services:
Addresses
Dependents
Job Information
Job Relationships
Centralized services support saving changes on the MSS UI of a supported HRIS entity.
Save on the MSS UI of the following HRIS entities are supported by Centralized services:
HRIS Entity
Job Information
Job Relationships
Compensation Information
Termination
Related Information
Admins can set up the system to allow employees to update their own data.
Admins control the allowed transactions based on the permissions for those users. The list here is a recommended
set but users are able to edit any of their information based on permission settings as well as company
requirements.
Message Handling
Warning and error messages are grouped together by entity and child entity in a pop-up to help users better
understand and resolve issues. Messages can also be filtered by severity.
Notes
Notes are forward propagated, since they are person related. This means, that on the Edit UI, they will not be
cleared unless users manually change them.
Personal Information HRIS Edit Personal Information Change name, marital status,
salutation
Email Information HRIS Edit Email Information Add, change, or delete email
Phone Information HRIS Edit Phone Information Add, change, or delete phone
numbers
Social Accounts HRIS Edit Social Accounts Add, change, or delete social
media account data
Emergency Contacts HRIS Edit Emergency Contacts Add, change, or delete emer-
gency contact
Work Permit HRIS Edit Work Permit Information Add, change, or delete work
permit information
Payment Information MDF Edit Payment Information Add, change, or delete bank
details
Manager Self-Service (MSS) changes can be made using Actions Change Job and Compensation Info or
using the Edit button.
Admins control the allowed transactions based on the permissions for those users. Admins can set up the system
to allow managers to make certain changes for the employees who report to them.
Only records for event reasons with the Employee Status set to No Selection can be created in the Actions
Change Job and Compensation Info pages in the MSS UI.
Identical record suppression ensures data consistency and avoids duplicate records.
For effective-dated entities, if you're updating data that matches existing data for an employee on a given date, the
record isn’t changed. However, if you're updating data that matches existing data but on a different date, the record
is created.
Identification of records to suppress isn’t a part of the validation process. However, when business rules are
executed, if there are changes, then the record is saved. If the records are still identical even after rule execution,
then the record is suppressed.
In transactions that involve several entities, but where there are only changes to some of them, only the changed
entities are saved. If there are no changes to an entity, but the user wants to save, they see a warning message for
the unchanged entities since there are no changes to be saved for the entity.
Example
For example, in a transaction involving Job Information, Compensation Information, and a recurring pay
component, where there are only changes to the compensation data, then the system saves those changes
and displays a message to the user that no changes are saved to Job Information, since there are no changes to
that data.
Note
Record suppression is only supported for entities that allow multiple changes each day, such as Job
Information or Compensation Information.
Warning and error messages are grouped together by entity and child entity in a pop-up to help users better
understand and resolve issues. Messages can also be filtered by severity.
Notes
Notes are not forward propagated since they are transaction related. This means that on the Edit UI, they will be
cleared. For each event, the user has to enter new values.
Entities in MSS
Assignment
Employment
Job Information Actions Change Job and Change an employee's job, for example,
for a promotion or change the manager.
Compensation Info
Job Relationship Actions Change Job and Change the job relationship, for example,
add a matrix manager or HR business
Compensation Info
partner
Compensation Information Actions Change Job and Change the compensation data, for ex-
ample, pay group.
Compensation Info
Recurring Pay Component Actions Change Job and Add, update, or delete recurring pay
components such as for the base salary
Compensation Info
or a company car allowance.
Recurring Deduction Actions Manage Recurring Add a recurring deduction, such as to re-
pay a company housing loan.
Deductions
One Time Deduction Actions One Time Deduction Add a one-time deduction, such as for a
charity donation.
Alternative Cost Distribution Actions Manage Alternative Cost Add a new alternative cost distribution
record or modify the latest one, depend-
Distribution
ing on the selected start date. When do-
ing so, combinations of cost center and
percentage can be added, updated, or
deleted.
Employment Information Actions Terminate Set the termination data and reason for
an employee.
Related Information
Here is some information about rule handling in the system for Job Information, Job Relationships, and
Compensation Information.
General
1. Job Information
2. Job Relationship
3. Compensation Information
4. Recurring Pay Component
If the rule is not for workflow or event reason derivation, the rules are processed in this order and then the result is
saved.
If an object is changed based on cross-entity rules, then onSave rules are not triggered for that object (unless both
objects are visible on the card such as Compensation Information and Recurring Pay Components).
The system processes the onSave rules based on the order defined in the Manage Business Configuration with the
exception that the rules configured for event reason derivation and workflow derivation from the rule scenarios are
executed after all the other rules are executed.
Here is the new order in which the onSave rules will be executed:
• For rules for Personal Information, where event reason derivation is not applicable, here is the order: National
ID rules and Workflow Derivation rules.
• For rules for Job information, here is the order: Job information rules, Event Reason Derivation rules, and
Workflow Derivation rules.
• For saving changes made from Manager Self-Serivce for both Job Information and Compensation Information,
here is the order: Job Information rules, Compensation Information rules, Event Reason Derivation rules
for Job information, Workflow Derivation rules for Job Information, Event Reason Derivation rules for
Compensation Information, Workflow Derivation rules for Compensation Information.
• Manager Self-Serivce: for changes made to Job Information, Compensation Information, Recurring Pay
Components, Non-Recurrung Pay Components, Termination Details, Global Assignments, and Concurrent
Employment
• Add New Emplooyee: for New Hire, Rehire, and Fixed-Term Contract scenarios
• People Profile: for changes made to Personal and Global Information, Address Information, National ID
Information, Work Permit Information, and Biographical Information
Tip
We recommend to only configure one scenario-based rule for workflow derivation in HRIS elements.
We recommend to only configure one event reason derivation scenario-based rule in Job Information or
Compensation Information.
Create Function and Delete & Create Function (Recurring Pay Components)
• For rules that use the Create function to update an existing recurring pay component, the result is that the
recurring pay component is updated with the rule result. The values of any fields that are not filled explicitly by
the rule are taken from the existing record.
• For rules that use the Create function to create a new recurring pay component, the result is that the recurring
pay component is created.
• For rules that use the Delete and Create function to update an existing recurring pay component, the result
is that the recurring pay component is updated with the rule result. The values of any fields that are not filled
explicitly by the rule are taken from the existing record.
• For rules that use the Delete and Create function to create a new recurring pay component, the result is that
the recurring pay component is created.
The Delete function should only be used if the pay component should actually be deleted (meaning, it
should not exist after rule processing). The behavior of rules that first delete a pay component and then
create the same pay component is identical to that of rules that only create a pay component, meaning that
the Delete function is entirely unnecessary. We recommend removing this from the rule.
The Create function should be used if the pay component should always exist after rule processing.
The Set function can be used instead of the Create function to update fields in an existing pay component.
For more information, refer to Example Business Rules for Employee Central Compensation
If the start date of a record was overwritten as a result of an onSave business rule, the system saves the calculated
start date if it is later than the one in the previous record and earlier than the one in the subsequent record (if there
is any). Otherwise, the system now informs you that the record cannot be saved and requests you to manually
update the start date to the one that was calculated by the rule.
The start dates of Job Information and Compensation Information involved in one transaction are kept in sync by
the system to ensure that only consistent data is saved. The system takes the start date of the Job Information as
the date, as long as Job Information is part of the initial transaction and was not created by a cross-entity rule. The
start dates for Job Relationships are not automatically synced.
Related Information
You can define Employee Central Quick Actions using templates for commonly used Employee Self-Service
and Manager Self-Services. Using the templates, you can tailor use cases for your company and country/region-
specific requirements.
General
A template allows you to combine the relevant fields from multiple data models for the same base entity that
are required for a specific use case as well as limit the number of fields shown to the user to the ones relevant
Tip
The system allows you to configure several templates for each use case. However, an employee and a manager
should only have access to a single template for each use case. Templates are permissioned using role-based
permissions and their target populations.
For more information, refer to the Use Cases for Employee Central Quick Actions [page 308] topic.
1. Add permissions for admins to be able to create Quick Action templates (MDF config object).
2. Configure the template for the use case.
3. Add permissions of the newly created Quick Action Templates for employees and managers.
4. Repeat as necessary for other scenarios - up to 5 templates for each use case.
For more information about this process, refer to the Configuring an Employee Central Quick Action Template
[page 323] topic.
Once configured, the actions are listed in a structured and segmented list. However, any customer-defined actions
as well as the Print/PDF link are not included in the alphabetical list, but are placed at the end of the list.
Once configured, Employee Central Quick Actions are available from the following channels:
• Web Experience
• To view or change their own information, an employee selects Home Page Manage My Data . Fields
from profile are included here for your convenience.
• To view or change information for their reports, a manager selects Home Page Manage My Team .
• People Profile Actions Take Action
• Mobile (iOS and Android)
• To view or change their own information, an employee selects the Manage My Data quick action on the
home page.
• To view or change information for their reports, a manager selects Team More Actions
• Joule
• Microsoft Teams
• SAP SuccessFactors Work Zone
• onSave
• onChange
The system executes rules for all fields even if the field is not shown on the UI.
The system also ensures that the data model field attribute Visibility cannot be changed from View to Edit or the
Mandatory attribute cannot be changed from Yes to No.
Workflow Handling
Workflows and workflow derivation rules are supported in the Employee Central Quick Actions.
If a workflow is updated or resubmited, then the users are redirected to the existing Job Information or
Compensation Information record away from the Employee Central Quick Action. You can view all the details of
a workflow from Pending Workflows.
FTE Handling
If the standard-hours field is enabled in the configuration, the system will always calculate the FTE based on Job
Information Standard Hours vs Object Standard Hours (Legal Entity or Location or Job Classification) depending
on configuration. This ensures that the FTE value is never null. However, if you have manually updated the FTE
value or set it using a rule to a value other than null or zero, it will not be overwritten by the automated calculation.
If the FTE field is not visible to the logged-in user for UI transactions, the application will reset the FTE value to null
so that it is recalculated.
For more information, refer to the Calculating FTE [page 177] topic.
Related Information
Here is some information about the predelivered template use cases with the supported and mandatory fields
listed.
These predelivered use cases can be used as is or optimized for your company and country/region requirements.
In addition to the mandatory fields listed in the table, the template also supports custom fields for supported data
types. For mandatory fields with multiple fields possible, at least one of them must be added to the template. The
field used in the template is marked in bold; however, it can be replaced with any of the other required fields.
Maximum
Mandatory Supported Amount of
Fields (Default Fields (Default Fields Dis-
Name Base Object Fields in Bold) Fields in Bold) Event Best Practice played
Change Ad- Address Infor- All fields config- No configuration n/a ESS 12; if there are
dresses mation possible at the more fields, an
ured in BCUI.
moment. info message is
(Change in-
See the note at shown instead.
cludes the abil-
the end of the
ity to add or de-
table for more
lete a record)
details about
Addresses.
Note
The Ad-
dress Vali-
dation and
Typeahead
service is
not sup-
ported.
Change Email Email Informa- All fields config- No configuration n/a ESS 5 (the first 5 as
Addresses tion ured in BCUI. possible at the defined in the
moment. data model and
(Change in-
to which the
cludes the abil- user has per-
ity to add or de- mission).
lete a record)
In addition, all
custom fields
for supported
data types are
allowed.
Change Job Job Information At least one of • EEO Class Job Change MSS 8
the following
fields is re-
• Job Title
• Local Job
• Employee
Title Type
• Notes
• Employee
Class
• Employ-
ment Type
• Regular/
Temporary
• Is Shift Em-
ployee
• Shift Code
• Is Home
Worker
• Is Volunteer
• Contract
Type
• Worker Cat-
egory
• Contract
Number
• Contract ID
• Job Group
• Contract
Date
• Contract
End Date
Change Job Re- Job Relation- All fields config- No configuration Data Change MSS 5 fields (the first
lationships ships ured in BCUI. possible at the 5 as defined in
moment. the data model
(Change in-
and to which the
cludes the abil- user has per-
ity to add or de- mission).
lete a record)
Change Legal Personal Infor- At least one of • First Name n/a ESS 8
Name mation the following
fields is re-
• Middle
quired: Name
• Last Name
• First Name
• Middle
• First Name
Alt1
Name
• Last Name • Middle
Name Alt1
• Birth Name
• Formal • Last Name
Alt1
Name
• Second
• First Name
Last Name Alt2
• Business • Middle
Last Name Name Alt2
• Last Name
Alt2
• Second
Last Name
• Business
First Name
• Business
First Name
Alt1
• Business
First Name
Alt2
• Business
Last Name
• Business
Last Name
Alt1
• Business
Last Name
Alt2
• Formal
Name
• Formal
Name Alt1
• Formal
Name Alt2
• Birth Name
• Birth Name
Alt1
• Birth Name
Alt2
Change Cost Job Information • Cost Cen- • Notes Data Change MSS 8
Center ter • Cost Center
Change Phone Phone Informa- All fields config- No configuration n/a ESS 5 (the first 5 as
Numbers tion ured in BCUI. possible at the defined in the
moment. data model and
(Change in-
to which the
cludes the abil- user has per-
ity to add or de- mission).
lete a record)
• Position
• Is Eligible
for Car
• Manager
• Pay Grade
• Is Eligible
for Benefit
• Job Code
• Is Eligible
for Finan-
cial Plan
• Position
• Manager ID
• Pay Group
• Pay Scale
Area
• Pay Scale
Type
• Pay Scale
Group
• Pay Scale
Level
• Position
• Is Eligible
for Car
• Manager
• Pay Grade
• Is Eligible
for Benefit
• Job Code
• Is Eligible
for Finan-
cial Plan
• Position
• Manager ID
• Pay Group
• Pay Scale
Area
• Pay Scale
Type
• Pay Scale
Group
• Pay Scale
Level
Return from Fur- Job Information • Notes • Notes Data Change MSS
lough
All custom fields
of supported
data types
View Addresses Address Infor- All fields config- No configuration n/a - 12; if there are
mation ured in BCUI. possible at the more fields, an
moment. info message is
shown instead.
View Cost Cen- Job Information • Cost Cen- • Cost Center n/a -
View Email Ad- Email Informa- All fields config- No configuration n/a - 5 (the first 5 as
dresses tion ured in BCUI. possible at the defined in the
moment. data model and
to which the
user has per-
mission).
In addition, all
custom fields
for supported
data types are
allowed.
• Local Job
• Employee
Title Type
• Notes
• Employee
Class
• Employ-
ment Type
• Regular/
Temporary
• Is Shift Em-
ployee
• Shift Code
• Is Home
Worker
• Is Volunteer
• Contract
Type
• Worker Cat-
egory
• Contract
Number
• Contract ID
• Job Group
• Contract
Date
• Contract
End Date
View Job Rela- Job Relation- All fields config- No configuration n/a - 5 fields (the first
tionships ships ured in BCUI. possible at the 5 as defined in
moment. the data model
and to which the
user has per-
mission).
quired: Name
• Last Name
• First Name
• Middle
• First Name
Alt1
Name
• Last Name • Middle
Name Alt1
• Birth Name
• Formal • Last Name
Alt1
Name
• Second
• First Name
Last Name Alt2
• Business • Middle
Last Name Name Alt2
• Last Name
Alt2
• Second
Last Name
• Business
First Name
• Business
First Name
Alt1
• Business
First Name
Alt2
• Business
Last Name
• Business
Last Name
Alt1
• Business
Last Name
Alt2
• Formal
Name
• Formal
Name Alt1
• Formal
Name Alt2
• Birth Name
• Birth Name
Alt1
• Birth Name
Alt2
View Phone Phone Informa- All fields config- No configuration n/a - 5 fields (the first
Numbers tion ured in BCUI. possible at the 5 as defined in
moment. the data model
and to which the
user has per-
mission).
Note
• The system automatically takes the country of the company from the Job Information record. You can only
change the country using the ESS scenario.
• If there is no Job Information record for a user, you can't add an address. This can only happen if you try to
create an address before the hire date.
Note
For entities where a user can have several types of that entity, such as Job Relationships or Addresses, it is only
possible to update the record, but not the type of record.
For example, a user can update their Home address, but can't change the type from Home to Office.
For example, a user can update their emergency contact, but not the relation from Spouse to Other.
For example, a user can update a Job Relationship to a different person, but not the type from Matrix Manager
to Custom Manager.
To change not only the record but also the type of record, use the corresponding ESS or MSS transaction.
Related Information
Create an Employee Central Quick Action template with those fields needed for your use case.
Prerequisites
• All fields planned for the use case must be set to Enabled and Visible or Editable in the data model.
• You have the Administrator Permissions Manage Business Configuration Employee Central Quick Action
Template permissions to create, change, and view template configurations.
• We recommend that you have Event Reason Derivation set up in your system.
Context
Employee Central predelivers templates with preselected fields for the use cases. It is possible to change these
fields based on your specific requirements, as long as specific mandatory fields for the use case are included.
Tip
The system allows you to configure several templates for each use case. However, an employee and a manager
should only have access to a single template for each use case. Templates are permissioned using role-based
permissions and their target populations.
Procedure
Field Description
Use Case Select the use case you need from the drop-down list.
Note
Only for the Cost Center field, the system displays the
unique external code. It is not displayed for any other
field.
Quick Action Name The name of the template is defaulted by the system based
on the chosen use case and locale of the user.
You can add translations for the templates. For more infor-
mation, refer to the Managing Languages and Customizing
UI Labels guide.
Base Object This is defaulted by the system based on the chosen use
case.
Event Reason You can select the event reason from the drop-down list. The
system lists all event reasons valid as of today.
The system always takes the event reason from the tem-
plate, even if you have set up Event Reason Derivation (ERD).
The system does not check view permissions for event rea-
sons.
Note
The event reason is not displayed to the employee. The
event reason is always preset by the system and not
editable for the employees.
Use Case Identifier This is a system-generated ID for this use case. The field is
read-only and can't be changed.
4. The template shows the defaulted fields for the use case.
Note
You can add more fields if required, but the number of base fields and the country/region-specific fields
can’t be more than 8 for each country/region. If there are more than 8 fields to be displayed for the user,
then the system won't let you add any more fields.
Example
For the Change Location template, you could add the following fields:
• JobInformation: Location
• JobInformation: Timezone
• JobInformation_DEU: Travel Distance
• JobInformation_DEU: Custom_String1
• JobInformation_CHN: Work Location
• JobInformation_CHN: Travel Distance
This means that a user whose country of legal entity is in Germany sees 4 fields:
• JobInformation: Location
• JobInformation: Timezone
• JobInformation_DEU: Travel-Distance
• JobInformation_DEU: Custom_String1
Whereas a user whose country of legal entity is in China sees these 4 fields:
• JobInformation: Location
• JobInformation: Timezone
Field Description
Data Model Select the HRIS entity, for example, Job Information or Job
Information_DEU
Note
Note
Note
Legislatively sensitive personal data fields configured as masked are not supported with Employee Central
Quick Actions and can't be added to the template. This is checked by the system when saving the template.
In addition, if there is a masked field as part of the template or a use case that doesn't support the
configuration of fields, then any sensitive data field will not be displayed on the UI.
Next Steps
You can make up to five active templates for each use case, so repeat the above steps as necessary.
To access and change Employee Central Quick Actions, employees and managers need to have the following
role-based permissions:
Note
These Employee Central Quick Actions are intended for use as Employee Self-Services and Manager Self-
Services. We therefore recommend that they are set up by configuring the appropriate permissions and target
groups accordingly.
Permission Description
User Permissions Employee Central Quick Actions Select the templates for which users need access.
User Permissions Employee Central Effective-Dated Select this setting for users to view or change data using Em-
Entities Job Information Job Information Actions View ployee Central Quick Actions with Job Information as the base
Current entity.
User Permissions Employee Central Effective-Dated Select this setting for users to change data for a past date
Entities Job Information Job Information Actions View (before the start date of the record that is valid as of today).
History
User Permissions Employee Central Effective-Dated Select this setting for users to change data in Employee Cen-
tral Quick Actions with Job Information as the base entity.
Entities Job Information Edit Link Edit/Insert
This setting is required in addition to the Job Information
or
Actions View Current or Job Information Actions
User Permissions Employee Central Effective-Dated View History permission.
Entities Job Information Job Information Actions Edit/
Insert
User Permissions Employee Central Effective-Dated Select this setting for users to view or change data using Em-
Entities Personal Information Personal Information ployee Central Quick Actions with Personal Information as the
User Permissions Employee Central Effective-Dated Select this setting for users to change data for a past date
Entities Personal Information Personal Information (before the start date of the record that is valid as of today).
User Permissions Employee Central Effective-Dated Select this setting for users to change data in Em-
ployee Central Quick Actions with Personal Information
Entities Personal Information Edit Link Edit/Insert
as the base entity. This setting is required in addition
or to the Personal Information Actions View Current or
User Permissions Employee Central Effective-Dated Personal Information Actions View History permission.
Actions Edit/Insert
User Permissions Employee Data Future-Dated Select this setting for each entity to view and add future-dated
changes. For more information, refer to Employee Data Permis-
Transaction Alerts
sions - Future-Dated Transaction Alerts.
When the View History permission is granted, any data blocking configuration is respected by the system.
Once permissions are granted to the users, managers and employees can access these Quick Actions from the
Home Page cards, on their mobile device, or any of the other channels, such as Joule or Microsoft Teams.
Note
Since there are a few differences between using Employee Central Quick Actions and Manager or Employee
self-service (MSS/ESS) transactions, we have listed the differences to help you better understand when to use
which transaction.
Allowed Fields Only 8 fields allowed for each Quick Ac- All fields are allowed.
tion.
Changing the Entity Type It isn't possible to change the entity type, It is possible to change the type.
such as Job Relationship type or Emer-
gency Contact type.
Rules Both onSave and onChange rules are All rule types are supported.
supported. However, it is not possible to
Only visible fields are updated by on-
change fields from editable to read-only
(or the reverse) using rules for fields in- Change rules.
cluded in the Quick Action.
Note
Fields not visble on the UI that are
updated from onChange rules are
updated in the background.
Permissions For View and Change actions, View Cur- For more information about permissions
for these transactions, refer to the Re-
rent permissions needed in addition to
lated Information section.
other permissions.
Data Blocking Supported by Quick Actions. This means View History permission is not sup-
that the data blocking period is re-
ported. If the user has the Edit/Link per-
spected.
mission, all data can be seen.
Note
Most Quick Actions are supported
by all the mentioned channels. How-
ever, some of the Quick Actions are
only available on certain channels.
For example, Demotion is not yet
available to use with Joule.
Approval Workflows Shows the approvers of the first level. Shows the approvers of all levels.
Masked Fields Not supported by Quick Actions. Fully supported by Quick Actions.
Entity-Specific Details for Addresses The system automatically takes the Any country can be selected.
country of the company from the Job In-
Addresses can be added for start dates
formation record, meaning that the coun-
before, on, or after the hire date.
try cannot be changed.
Related Information
This section lists the deep links available for Employee Central.
A deep link is a direct link to a page, in which the URL contains all the information needed to go that page rather
than having to navigate to the page from the Home screen.
For more information, refer to the Deep Links guide on the SAP Help Portal.
/sf/employmentinfo Takes the user to the Employment Info selected_user(optional) = user sys id.
page
/sf/employeeupdate Takes the user to the Update Employee selected_user(optional) = user sys id.
Records page
/sf/orgchart?type=position Takes the user to the Position Org Chart selected_position=<position external
code>
/sf/personalInfo Takes the user to the Personal Info page selected_user(optional) = user sys id.
/sf/employeeterminate?selectques- Takes the user to the Terminate/Retire selected_user(optional) = user sys id.
tion=essMssTerminateActionControl- page
ler&selected_user=<username>
sf/timeoffworkbench Takes user to Time Off Workbench selected_user can be entered as a pa-
rameter. If it is not, the Workbench or
Administer Time is opened for the logon
user.
You can use the parameter to change the user ID in the URL to go directly to the page for that user.
Example
The link to a page to terminate a specific user may look like the following:
/sf/employeeterminate?selectquestion=essMssTerminateActionController&selected_user=
Use the Employee Central diagnostic tool to troubleshoot issues with HRIS elements in workflows as well as data
saved in Manager Self-Service (MSS), Employee Self-Service (ESS), and Add New Hire transactions when they are
made using the Edit, History, or Take Action options.
Prerequisites
Context
You want to view trace information for workflow transactions and save transactions with Centralized services.
For workflows, you can navigate to the transaction details of an individual workflow from the search results. For
Centralized services, the Snapshot View and the Rule Execution View provide a summary and rule execution details
for HRIS elements.
Remember
Procedure
Centralized Services For save transactions with Centralized Services, you must
first enable the Diagnostics Trace Configuration object in
3. In the Requested By field, you can search for the relevant employee.
4. In the Requested For field, you can search for the relevant employee.
5. Select a date range for the search.
6. Choose Search.
The system displays a list of transactions with the latest results listed first.
7. Select a desired result to view additional details.
Based on the selected transaction type, details of each stage of a transaction are available for workflows and
save transactions with Centralized services.
Use the search results in the Diagnostic Tool to navigate to the details of an individual workflow.
For the Workflows transaction type, you can see the processing details of an entire workflow in one view and
analyze issues such as the workflow trigger, approval, or email notification, if any. You can find most of the workflow
configuration information in the details page, such as the workflow configuration ID, workflow derivation rule ID,
current workflow status, and so on.
Trace information is captured from the date the Administrator Diagnostic Tool Workflows Diagnostics Data
permission is granted to access the Diagnostic Tool. Trace information is available for 10 days and is extended by 10
days from an action date, if any action is taken on a workflow.
Remember
Use this view to see a summary of a transaction's process stages after save transactions are executed.
For Centralized Services, you can see tabular record details for each stage of a save transaction after it is processed
in the background.
Note
• Data Changes: Shows the data entered or the field values changed manually by a user.
• Related Changes: Shows the other field or data changes due to the fields originally changed in the Data
Changes stage.
• Rules: Shows the record status after all the business rules are applied. Changes made to the fields or records of
an entity can be checked by comparing them with the previous Data Changes stage.
Note
The Snapshot View does not show rule names. You can navigate to Rule Execution View for rule execution
details. Only onSave rule changes are traced for now.
• End-Date Correction: This stage shows the changes to the end date field values relative to the record being
updated or added. Use this to check if there's an end date issue during a transaction.
• Forward Propagation: This stage shows the changes to future records after a record is updated due to an
added record. You can get insights on which field values were propagated and which were not propagated to
future effective-dated records compared to the new effective-dated record that is added.
• Save: This stage shows the saved records only when you choose Submit after a Save.
Use the Rule Execution View in the Diagnostic Tool to understand transaction details of records and rules that are
excluded as well as rules that are executed for HRIS elements using Centralized services. Rule execution details are
available for onSave rules only.
• Why wasn't a rule executed despite being configured in Manage Business Configuration?
• Why was a record not considered for rule execution?
• Why were changes not saved after a rule was executed?
• Which rule modified the fields?
• Which rule displayed a message?
• Which rule initiated a workflow process?
• Which rule derived an event reason?
• Identify the list of fields that were changed by a rule.
• Provide a chronological list of rule executions with timestamps.
• Identify the rules that did not alter any field data or attributes after rule execution.
• Excluded Records: Records that aren't processed or filtered out based on eligibility checks.
• Excluded Rules: Rules that aren't executed or filtered out based on rule contexts.
• Executed Rules: onSave rules that are executed after ineligible records and rules are filtered out.
You can search for an onSave rule or changed fields across the three sections in this view. In addition, you can also
navigate to this view from the Snapshot View.
HISTORY_UI History UI
ONB_NO_SHOW Onboarding
ONB_COMMON Onboarding
DEPENDENT_EDIT_UI Edit UI
All Ad Hoc reports are now enabled automatically when the corresponding module is enabled. There are several
report schemas available for Employee Central ad hoc reports. Some are end-user reports and others are purely
meant for admins.
Basic Information
This report shows employee HR data on a given date (by default, it considers today unless specified). For example,
reporting all employees hired on a certain date. This report can be run based on future dates as well. For example,
you could run a Termination report on Jan 01, 2013 to see how many future dated terminations are set to take place
on Jan 31, 2013.
Make sure to use filters to limit the size and scope of the report, such as filtering on a particular legal entity or
country.
Be mindful of the number of column sets you include in one report. For example, if you include Compensation or
Pay Component data (as employees tend to have more than one), you could end up with duplicate rows in the
report .
The report results are only as numbers. This is for performance reasons. If you want the corresponding labels or
external codes, select the columns in the relevant entity to generate a report with codes.
Note
Since the data displayed in the Compensation Information is transient (calculated when the page loads),
the displayed value is not stored in the database, and therefore not directly available in ad hoc reports.
To display this information in the Person and Employment (as of Date) report, you must have the HRIS
PayComponentGroup Sums Sync job scheduled in your instance.
When the job runs for the first time, it will likely take some time to complete. However, once completed, all
subsequent jobs that run (advised as once daily) will be much faster. Once the job is completed, the Person and
Employment (as of Date) report displays the calculated values when the selected column set is Employee Pay
Group Sums and a pay component group, such as AnnualizedSalary.
The pay component group sum is calculated only for active users with these statuses:
This report shows an employee’s Job Info for a range of dates; for example, reporting all Job Information and Status
changes within the give date period. For example, all Job Information and Status changes between Jan 01, 2012
and July 01, 2013 (in mm/DD/yyyy format).
This schema reports data based on the effective dates of the employees Job Information records. If you report on
Compensation Information, the report generates one row for each Job Info effective-dated record the employee
has, and NOT based on one row for each Compensation Info effective-dated record the employee has. For example,
if the employee has three Compensation Info records but six Job Info records, and you report on Job Information
using this report, you will see six rows for Compensation Information, because the Compensation Information
records are reported on based on the Job Info record effective dates, within the date range you specify.
If you add multiple column sets to the report, this increases the complexity of the report and you may need to run
the report offline for it to complete successfully.
This report shows an employee’s Compensation Information for a range of dates; for example, reporting on salary
changes between 01/01/2012 and 07/01/2013 (mm/DD/yyyy).
This schema reports on data based on the effective dates of the employee's Compensation Information records.
If you report on Job Information, the report generates one row for each Compensation Information effective dated
record the employee has, and NOT based on one row for each Job Information effective dated record the employee
has. For example, if the employee has three Job Information records but six Compensation Information records,
and you report on Job Information using this report, you see six rows for Job Information, because the Job
Information is reported on based on the Compensation Information record effective dates within the date range
you specify.
Do not include too many complex joins. For example, do not include Pay Component Non-Recurring data if there is
no need.
If you are getting multiple (duplicate) rows - please ensure for each Effective Dated column set, you include also
the Start Date and Sequence Number fields - this makes the report easier to understand when mashing a lot of
different table data together.
This report shows the non-recurring pay Components within a Date Range specified by the user; for example,
reporting bonus payments within a certain date range. You should only use this report to identify Spot Bonus/
One-Time Bonus information for a period.
Do not include too many complex joins. For example, do not include Pay Component Recurring data if there is no
need.
If you are getting multiple (what looks like duplicate) rows, please ensure that, for each Effective Data column set,
you also include the Start Date and Sequence Number fields. This makes the report easier to understand when a
lot of different table data is being mashed together.
This report shows all the inserts and corrections of an employee’s information in Employee Central, including
who made changes and when. An example would be reporting employee movements and flagging any historical
changes.
We recommend that you use this report to determine who inserted, deleted, or edited a record in the employee's
data in Employee Central. This is a very powerful report that shows one row for each Insert/Update/Delete of data
for each record that is reported on. Run this on only one area of Employee Central data at a time, for example: Job
Information (do not include Compensation Information, or other data). Make a separate report for Compensation
Information audit, or Personal Information audit, and so on.
• Insert = Represents the change was made using 'Take Action' or Inserting a record into the history
• Update = Can happen from either the 'Pencil' icon or from editing an existing record from the Employee History
• Delete = The record was deleted. Please note that you can view any Deleted record with this report
You must filter the report to ensure that you do not get too much data returned. No filter results in ALL audit data,
but will most likely cause the report to fail (since it is a LOT of data).
The report should only ever be run on a one-column set. Do not mix fields from different columns sets. Doing so will
skew the report when the tables are joined.
This report should not be used for any headcount or functional user reporting. It is purely an admin report used to
check who changed what and when.
You can export employee data so that it can be updated and reimported with any need to format it in an import-
friendly way. For example, if you needed to update Job Information records for multiple users, you would use this
report to extract the data.
If you need to create multiple export files on a regular basis, you can create a Multi Data Set report using only the
P&E Export schema, and include one column set for each domain. Then you can extract data for Job Info, Comp
Info, Home Address, and so on, into separate tabs.
Do not include multiple column sets (such as Job Information, Compensation Information, and so on). This report
is meant to be run against one column set at a time (all fields in Job Information column list, for example).
This report should not be used for any headcount/functional reporting. This report is purely an admin report to
allow export of data in an easy-to-use format for data imports.
Ensure that this report is always run with filters. It will likely fail when run with no filters if the employee/
employment population in the instance is very high.
Foundation Objects
You can export information directly from the Foundation Object tables that have been loaded to the system or
manually entered. For example, reporting directly on one or more particular Foundation Objects, such as returning
the details of all Locations and linked Organization Units (showing the relationship).
Use this report to export only the legacy Foundation Object data, in an import-friendly format. If you need to export
MDF-based Foundation Object data for import, please use Import and Export Data instead.
Do not mix and match the report schemas when creating multi-data set reports. For example, if you create a
multi-data set report using a Date Range and an As Of Date schema, the system generates the report based on
the As Of Date schema. The same is true if you include the Export schema within the above scenario (Export, Date
Range and “As of Date” schemas), then the report will actually run based on the Export report, and date range/as
of date will not be possible with the reports. You will also have unexpected results and behavior, as the system is
not designed to work in this way. If you do need to create multi-data set reports, please ensure you use the same
schema type for each domain you add to the report.
Cross-Domain Reporting
It is currently not possible to use this ad hoc Report feature with Employee Central 2.0 ad hoc report schemas.
All Employee Central ad hoc Reports can be scheduled to run and export to SAP SuccessFactors or external FTP
folders. To set up scheduled Employee Central ad hoc reports, please create the report you wish to have scheduled,
and then raise a support ticket with Product Support, who will help schedule the report for you. Please be sure
to provide Product Support with the timing the report should run under (what date/time should the report be
scheduled to run, how often), and also the name of the report and the user name of the owner of the report.
There are different options that can be enabled for Ad Hoc Reports.
Row-level permissions are enabled by default and cannot be disabled. This layer of security restricts the user
running the report, to be able to report on the target populations assigned by role-based permissions (RBP). Please
note that this will mean the user running the report will be able to report on any data for any user in their target
population.
This is specific to the report schema you are creating. The As of Date has 1 row for the Effective Date you report
on. If cell-level permission is turned off, then only row-level permission is applied, meaning the report will include
everyone in the target population of the user running the report. If cell-level permission is enabled, then the row
level will still include all the users in your target population, but then restrict what data you see in that cell in the row
for the targeted user.
Row-level permissions include historical and future-dated data. For period reporting = Date Range reports should
be used if you want to see all records in a period. For example, you have not enabled cell-level permission, and
a manager wants to run a Compensation report to see the pay component data of their direct reports. If the
manager's manager is in the target population, then they will see their manager's pay component data. If, however,
cell-level permission is enabled, then further restricting based on RBP, the manager will still see the columns but for
the row where their manager comes, there will be no values returned in those cells.
In Table reports, the cell level and field level permissions are supported only for the Employee Profile domain and
not for the other domains of the Employee Central schema.
The cell level and field level permissions are supported for the Employee Central schema only in Canvas reports
(Advanced Reporting).
All Ad Hoc reports are now enabled automatically when the corresponding module is enabled.
To reduce the size of SQL query, which helps reduce the query parsing time, the system is set for Ad Hoc Query
Trimming, which is enabled by default. It can be disabled in Provisioning if required.
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.
AdHoc Query Trimming supports only the following Ad Hoc Reports (Employee Central):
Switch on Alternative Cost Distribution (ACD) in your Employee Central system in order to use it.
Prerequisites
You have to set up generic objects, since alternative cost distribution is a generic object.
In the object definition for both Alternative Cost Distribution and Alternative Cost Distribution Item, in the Security
section, the Secured field must be set to Yes and the Permission Category set to Miscellaneous. Once the
object definition is updated, the permissions must be set in Manage Permission Roles User Permissions
Miscellaneous Permissions .
We recommend using secured objects. However, if you choose not to use secured objects, then you must set the
Manage Permission Roles Admin Permissions Metadata Framework Access to non-secured objects .
For more information, refer to the Generic Object section of the Implementing Employee Central Core guide on the
SAP Help Portal.
Procedure
Remember
Results
Enable cost centers for non-recurring pay components, independent of whether Alternative Cost Distribution is
enabled in the system. This allows you to assign a cost center other than the one an employee is assigned to, for
example, for a spot bonus.
Procedure
Results
Prerequisites
Ensure that the miscellaneous permissions have been granted in the object definition and that the card is visible.
Procedure
3. In the What changes are you proposing for (employee name)? screen, select Take Action Manage
Alternative Cost Distribution .
To avoid errors in the People Profile, configure the Alternative Cost Distribution as a Live Profile MDF Information
custom card with MDF Screen ID EmpCostDistributionUI .
Procedure
In the Custom Cards section, the Live Profile MDF Information appears.
5. Drag the Live Profile MDF Information card over to the Alternative Cost Distribution row and drop it in.
6. Add the MDF Screen ID, which is EmpCostDistributionUI.
Note
You must use this screen ID, otherwise the configuration will not work.
Add custom fields to the Configuration UI for Alternative Cost Distribution where needed.
Context
Note
If there are problems with the UI, it is possible to reset the whole configuration to the original standard settings.
You do this by selecting Delete. This only resets the UI rather than deleting it from your system. This only works
because this specific screen is delivered by SAP. Do not try this with other screens in the system!
Procedure
For more information about custom fields, refer to the Implementing the Metadata Framework guide on the
SAP Help Portal.
2. In the Manage Configuration UI screen, in the Id field, find the EmpCostDistrbutionUI with Alternative Cost
Distribution as the base object.
Tip
We recommend that custom fields only be added to the EmpCostDistrbutionUI, rather than to another
custom UI.
Next Steps
Once you have created the new fields, you can check them in the UI and add the required data for employees. Go
to an employee where you need to change the data. In the What changes are you proposing for (employee name)?
screen, select Take Action Manage Alternative Cost Distribution . Enter the new field as required and save
your entries.
Context
Alternative cost distribution is a generic object, so here's how you can import data for it:
Note
For more information about data imports, refer to the Implementing the Metadata Framework guide on the SAP
Help Portal.
Procedure
a. You can find the downloaded templates by going to the Admin Center Monitor Jobs .
Note
b. Select Download Status for each of the files, and open the CSV files.
c. Make your entries in the CSV files.
d. Save your changes.
3. Import the data.
a. To import your changed CSV files, go to the Admin Center Import Data .
b. On the Import and Export Data page, select Import Data as the action to perform.
c. Select CSV File.
d. In the File field, select the corresponding file templates. Make sure you first upload the changes done
to the Alternative Cost Distribution file, then the changes done to the Alternative Cost Distribution Item-
Alternative Cost Distribution file.
e. Select Validate first to check the file for any formatting errors.
f. If the file is valid, select Import.
Here's a look at some issues you might encounter when using Alternative Cost Distribution.
In Employee Central, a data purge job may fail for several reasons. One reason may be that the user being purged
has Employee Central data that the user performing/approving the purge does not have access to, for example,
Alternative Cost Distribution.
To resolve such cases, go to Manage Data and delete this additional data for the employee before submitting the
purge.
Note
The user performing the purge must have create/change/delete permissions for the Change Log for Data
Replication MDF Object.
No Permission Error
When you try to delete an Alternative Cost Distribution record, you receive the error "No permission to create
object!" You might receive this in the Alternative Cost Distribution or in the Manage Data screen. This may happen if
Payroll Integration is enabled in your system. To keep the payroll system aligned when alternative cost distribution
records are deleted, a Change Log for Data Replication is created by the system. If the user doesn't have permission
to create or change this log, then they will get the permission error.
• Grant the user create/change/delete permissions for the Change Log for Data Replication MDF Object.
• Find a user with existing permissions for the MDF object and then delete the Alternative Cost Distribution
record.
Some features and functionality included in earlier releases are no longer needed or are no longer supported
in the new release. The following sections describe features that are retired and the support for which will be
discontinued. As of the 1H 2023 release, there is nothing to be listed here.
With the 2H 2022 release, event reason derivation is only possible using business rules for Job Information and
Compensation Information.
The following sections on XML Event Reason are no longer relevant. However, they have been retained for reference
purpose only.
Additional Information
In previous releases, XML event reason derivation was migrated to business rules. Using the Upgrade Center, a
business rule was created under a new rule scenario for Job Information and Compensation Information objects
respectively. All the migrated rules start with the postfix 'migrated_rule'.
Example
compInfoModel_ERD_migrated_rule_1582621769177
The new business rules are automatically assigned to the respective HRIS objects in the system. You can find them
in your in your Succession Data Model or on the Business Configuration UI page.
Note
The placement of the migrated rule is always at the bottom of the list of rules attached to an HRIS element.
This order must always be kept. However, if you have rules for triggering workflows, they must be placed after
the migrated rule.
• The removal of the legacy Enable youCalc rules engine for HRIS switch.
• Decoupling of two switches, Enable Business Rules for Workflow Derivation and Enable Business Rules for Event
Reason Derivation. This means:
• If Enable Business Rules for Workflow Derivation is enabled, workflows are derived using business rules.
Otherwise, workflow derivation happens from the XML model.
• If Enable Business Rules for Event Reason Derivation is enabled, event reasons are derived using business
rules. Otherwise, event reason derivation is disabled.
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.
It is highly recommended that you test and validate the migration in your Preview environment before upgrading in
Production. If you face any issues, please contact Product Support.
Use Cases
Compensation Information
Use Case No. XML Rules Job Information Event Reason Event Reason
1 J1 J1 J1
2 C2 C2 C2
3 R3 R3 R3
7 D7 D7 D7
Legend:
• J – Job Information
• C- Compensation Information
• R- Job Relationship
• JR – Job Information and Job Relationship
• CR – Compensation Information and Job Relationship
• JC – Job Information and Compensation Information
• D – Default or Catch all
Note
In all the use cases, ensure that there is the primary condition to check if the existing event reason value is null
or blank.
Example
XML Rule:
Sample Code
<rule id="rule-PT1">
<trueoutput>POS_XFR</trueoutput>
<conditions>
<and>
Example
XML Rule:
Sample Code
<rule id="rule-7">
<trueoutput>PAYBEN</trueoutput>
<conditions>
<and>
<equal
id="compInfo.benefits-rate" inverse = "true"/>
</and>
</conditions>
</rule>
Use Case 3: Deriving the event reason based on the Job Relationship information of an employee.
XML Rule:
Sample Code
<rule id="rule-090">
<trueoutput>RELATIONSHIP</trueoutput>
<conditions>
<or>
<equal id="jobRelationsInfo.relationship-type.hr manager"
inverse = "true"/>
</or>
</conditions>
</rule>
Example
Use Case 4: Deriving the event reason based on the Job Information and Job Relationship of an employee.
XML Rule:
Sample Code
<rule id="rule-090">
<trueoutput>PAYXFR</trueoutput>
<conditions>
<or>
<equal id="jobInfo.pay-grade" inverse="true"/>
<equal id="jobRelationsInfo.relationship-type.hr manager"
inverse = "true"/>
</or>
</conditions>
</rule>
Example
Use Case 5: Deriving the event reason based on the Compensation Information and Job Relationship of an
employee.
XML Rule:
Sample Code
<rule id="rule-090">
<trueoutput>JOBSHIFT</trueoutput>
<conditions>
<or>
<equal id="compInfo.benefits-rate" inverse = "true"/>
<equal id="jobRelationsInfo.relationship-type.hr manager"
inverse = "true"/>
</or>
</conditions>
</rule>
Example
Use Case 6: Deriving the event reason based on the Job Information and Compensation Information of an
employee.
XML Rule:
Sample Code
<rule id="rule-6">
<trueoutput>PROPWP</trueoutput>
<conditions>
<and>
<greater
id="payComponentGroup.AnnualizedSalary" />
Example
Use Case 7: Deriving the event reason based on any data change.
XML Rule:
Sample Code
<rule id="rule-23">
<!-- Catch all-->
<trueoutput>DATACHG</trueoutput>
<conditions>
<or>
</or>
</conditions>
</rule>
Related Information
Learn about changes to the documentation for Implementing Employee Central Core.
2H 2024
New We have added information about Employee Central in the Latest People
changes to Employee Central entities on Profile [page 185]
the latest People Profile.
Added We have added information about opti- Optimistic Locking [page 184]
mistic locking in Job Information.
Changed We have reorganized some content in this Configuration Tasks [page 22]
guide for an easier set-up. Several topics
are now moved to the Configuration Tasks
section.
Changed We have a added a topic to explain Differences Between Quick Actions and
the system behavior differences between Self-Service Transactions [page 328]
Employee Central Quick Actions from
MSS/ESS transactions.
Changed We have moved the following topics to System Behavior for Editing UI of Em-
the Implementing and Managing the Em- ployment Details
ployment Lifecycle (from Hiring to Termi-
Business Rule Handling for Employment
nation) guide.
Details
• System Behavior for Editing UI of Em-
ployment Details
• Business Rules Handling for Employ-
ment Details
Changed We have removed the Enabling the Em- Deprecation of Partner API, SFAPI Ad-
hoc, and SFAPI for Simple Entities
ployee Central SOAP APIs topic.
Changed We have updated the note about external Characteristics of Foundation Objects
[page 29]
code in Foundation Objects.
New Email addresses are now validated by de- Email [page 163]
fault. We've also revised the information
about the validation rules.
New We have added information about using Using the Diagnostic Tool [page 333]
the new diagnostic tool for Employee Cen-
tral transactions.
Changed We have updated the information about Employee Central Quick Actions [page
the Employee Central Quick Actions. In
305]
addition, the Enabling Employee Central
Quick Actions topic was removed as the Use Cases for Employee Central Quick
feature is now automatically on in the sys- Actions [page 308]
tem.
Configuring an Employee Central Quick
Action Template [page 323]
Changed Saving changes for Dependents on the Centralized Services in Employee Central
Edit UI and the History UI is universally [page 297]
supported by Centralized services and re-
quires no settings.
Changed We have merged all the information about Employee Central Effective-Dated Enti-
permissions for Employee Central effec- ties [page 127]
tive-dated entities into one topic.
Changed Topics in the Entities in Employee Central Entities in Employee Central [page 141]
section have been reorganized and some
have been retitled.
Changed With all HRIS entities now universally sup- Centralized Services in Employee Central
ported by Centralized Services, we have
[page 297]
moved the Centralized Services in Em-
ployee Central topics to the HR Transac- Manager Self-Service (MSS) [page 301]
tions in Employee Central section. The
Manager Self-Service and Cross-Entity Cross-Entity Rules [page 219]
Rules topics are now updated with all
changes from Centralized Services as
well.
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 an 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.
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.
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.