Implementation Guide | PUBLIC

Document Version: 2H 2023 – 2024-01-17

Implementing Employee Central Core

© 2023 SAP SE or an SAP affiliate company. All rights reserved.

THE BEST RUN

Content

1 Employee Central Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1 Comparing Employee Central and Employee Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Where to Find Information about Other Employee Central Topics. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Recommended Implementation Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Recommended Implementation Sequence with Other Modules. . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Assignment ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Differentiating Between Person ID, UUID, User ID, and Assignment ID. . . . . . . . . . . . . . . . . . . . . 14
1.5 Components for SAP SuccessFactors Employee Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6 Data Protection and Privacy for Employee Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Configuring the System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1 Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Configuration Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Setting Up the Basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Setting Up Attachment Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Creating a Super Admin User in Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Data Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
MDF Foundation Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Generic Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Configuring Company System Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Configuring Employee Central Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Enabling the Employee Central SOAP APIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Configuring the Internal Job History Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Setting Up the Currency Exchange Rate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
User ID Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

3 Managing Role-Based Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

3.1 Permissions for Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
User Permissions for Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Administrator Permissions for Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Adding Value Help Permissions for Everyone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Accessing Future Organizational Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

4 Events and Event Reasons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

4.1 Events in Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.2 Event Reasons in Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
4.3 Creating Event Reasons for Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

Implementing Employee Central Core

2 PUBLIC Content
4.4 Creating a Fallback Event Reason Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.5 Configuring Country/Region-Specific Event Reasons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5 Creating Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5.1 Event Reason Derivation Business Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.2 Workflow Derivation Business Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
5.3 Business Rules in Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Rule Scenarios for Employee Central Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Optimizing Business Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Standard and Model Base Objects for Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Mapping of Employee Central Data Types and Business Rule Field Types. . . . . . . . . . . . . . . . . . 146
Overview: Rule Events in Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Common Problems for Business Rules in Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Cross-Entity Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Adding Contexts for Business Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Managing Conditional Groups and Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Example Employee Central Business Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

6 Entities in Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

6.1 Personal and Global Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Preventing Deletion of Global Information on Editing UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Data Deletion for Certain Person Entities on History UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196
Forward Propagation of Personal Information and Global Information on History UI. . . . . . . . . . 199
Forward Propagation of Personal Information and Global Information on Editing UI. . . . . . . . . . .201
Record Suppression for Personal Information and Global Information on the UI. . . . . . . . . . . . . 204
6.2 Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Forward Propagation of Addresses on History UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .206
Forward Propagation of Addresses on Editing UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Preventing Deletion of a Type of Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
6.3 Permissions for Personal Information and Addresses Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
6.4 Emergency Contact. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Enabling Mandatory Field Validation for Emergency Contacts. . . . . . . . . . . . . . . . . . . . . . . . . . 214
6.5 National ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
6.6 Work Permits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
6.7 Enabling Email Address Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
6.8 Enabling Attachments for Personal Information Entities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
6.9 Employment Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Business Rules for Employment Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
System Behavior for Editing UI of Employment Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
6.10 Job Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Data Validation for Job Information (MSS and History UI). . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Forward Propagation in Job Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Implementing Employee Central Core

Content PUBLIC 3
 Calculating FTE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
6.11 Job Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Data Validation for Job Relationships (MSS and History UI). . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Forward Propagation in Job Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
6.12 Last Updated by Source Details in History UIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

7 Human Resource Information System (HRIS) Synchronization. . . . . . . . . . . . . . . . . . . . . . . . 236

7.1 Triggering HRIS Sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
7.2 HRIS Sync Mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240
7.3 Hard-Coded HRIS Sync Mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Fields Hard-Coded for Syncing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
7.4 Custom HRIS Sync Mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Configurable Sync Mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
Rules for Configuring HRIS Sync Mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252
Configuring HRIS Sync Mappings in Business Configuration UI. . . . . . . . . . . . . . . . . . . . . . . . .257
Configuring HRIS Sync Mappings in the Succession Data Model XML. . . . . . . . . . . . . . . . . . . . 260
Syncing the Termination Date Between Employee Central and Standard User Fields. . . . . . . . . .262
7.5 Special Handling for Syncing Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
7.6 Picklist Configuration for Employee Status and Job Relationship Type. . . . . . . . . . . . . . . . . . . . . . 266
7.7 HRIS Sync Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Creating a Job Request to Sync HRIS Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Creating a Job Request to Sync HRIS Data for Specific Users. . . . . . . . . . . . . . . . . . . . . . . . . . 273
Future Hires in HRIS Sync Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

8 HR Transactions in Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

8.1 Employee Self-Service (ESS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
8.2 Manager Self-Service (MSS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Rule Handling with Manager Self-Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
8.3 Employee Central Quick Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282
Use Cases for Employee Central Quick Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Enabling Employee Central Quick Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Configuring an Employee Central Quick Action Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

9 Centralized Services in Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299

9.1 Cross-Entity Rules with Centralized Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
9.2 Manager Self-Service (MSS) Supported on Centralized Services. . . . . . . . . . . . . . . . . . . . . . . . . .309

10 Deep Links in Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

11 Mobile Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

11.1 Setting Up Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
11.2 Mobile To-Do Items in Employee Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

12 Ad Hoc Report Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Implementing Employee Central Core

4 PUBLIC Content
12.1 Permissions for Ad-Hoc Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
12.2 Ad Hoc Report Query Trimming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

13 Implementing Alternative Cost Distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

13.1 Enabling Alternative Cost Distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323
13.2 Enabling Cost Centers for Non-Recurring Pay Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324
13.3 Assigning Alternative Cost Distribution to an Employee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
13.4 Configuring People Profile Block for Alternative Cost Distribution. . . . . . . . . . . . . . . . . . . . . . . . . 325
13.5 Adding Custom Fields for Alternative Cost Distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
13.6 Importing Data for Alternative Cost Distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
13.7 Troubleshooting Alternative Cost Distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

14 Retired Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

14.1 Event Reason Derivation from XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Implementing Employee Central Core

Content PUBLIC 5
1 Employee Central Overview

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.

1.1 Comparing Employee Central and Employee Profile

Here is a brief overview to show the differences between Employee Central and the employee profile.

Employee Central Employee Profile

What does it do? Drives all core HR administration, trans- Drives all Talent and Learning proc-
esses.
actions and processes.

Is it effective dated? Yes No, it is snapshot data.

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.

Is multiple employment allowed? Yes Yes.

1.2 Where to Find Information about Other Employee

Central Topics

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

Advances Implementing Advances in Employee Central

Apprentices Implementing and Managing Apprentices in Employee Cen-

tral

Implementing Employee Central Core

6 PUBLIC Employee Central Overview
Topic Link

Business Configuration UI Setting Up and Using Business Configuration UI (BCUI)

Business Rules Implementing Business Rules in SAP SuccessFactors

Check Tool Using the Check Tool

Company Structure Overview Implementing and Managing the Company Structure Over-
view in Employee Central

Compensation Implementing Employee Compensation Data in Employee

Central

Concurrent Employment Implementing and Managing the Employment Lifecycle

(from Hiring to Termination) in Employee Central

Contingent Workforce Management Implementing Support for Contingent Workers in Employee

Central as Part of Total Workforce Management

Country/Region Specifics Country/Region Specifics for Employee Central

Data Model Field Information for Employee Central Data Model Field Information in Employee Central

Deductions Implementing and Managing Deductions in Employee Cen-

tral

Dependents Implementing Dependents in Employee Central

Document Generation Implementing Document Generation in Employee Central

Imports Employee Data Imports

Integration with SAP ERP SAP SuccessFactors Employee Central Integration to SAP
Business Suite

Global Assignments Implementing and Managing the Employment Lifecycle

(from Hiring to Termination) in Employee Central

Global Benefits Implementing Global Benefits in Employee Central

Managing Employment Implementing and Managing the Employment Lifecycle

(from Hiring to Termination) in Employee Central

Metadata Framework (MDF) Implementing the Metadata Framework (MDF)

Mobile SAP SuccessFactors Mobile Deployment Guide

SAP SuccessFactors Mobile Features

Payment Information Implementing Payment Information in Employee Central

Payroll SAP SuccessFactors Employee Central Payroll

Implementing Employee Central Core

Employee Central Overview PUBLIC 7
Topic Link

Pension Payouts Implementing Pension Payouts in Employee Central

Position Management Implementing Position Management in Employee Central

Service Center Implementing Employee Central Service Center

Time Off Implementing Time Management in SAP SuccessFactors

Workflows Implementing and Administering Workflows in Employee

Central

Related Information

Enabling Alternative Cost Distribution [page 323]

1.3 Recommended Implementation Sequence

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.

To help you with your implementation, we recommend following sequence of steps.

 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 .

For information on this step… See…

Step 1: Setting Up a New Account in Provisioning Configuration Tasks [page 21]

This section describes the steps to get started with your

implementation, including the different options you need to
select in Provisioning to enable Employee Central.

Implementing Employee Central Core

8 PUBLIC Employee Central Overview
For information on this step… See…

Step 2: Creating the Super Admin Configuration Tasks [page 21]

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 Refer to the SAP SuccessFactors Data Model Reference
Data Model Guide for information about how to set up the Country/Re-
gion-Specific Corporate Data Models.

Step 5: Setting up MDF Foundation Objects MDF Foundation Objects [page 71]

Generic Objects [page 85]

These sections describe how you can configure your MDF

Foundation Objects and custom Generic Objects. These sec-
tions also describe how you can set up the country/region-
specific configurations for MDF Foundation Objects.

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.

If you have defined associations in steps 3 and 4, make sure

that you update the field criteria in the Succession Data
Model.

Step 7: Configuring the Country/Region-Specific Succession Refer to the SAP SuccessFactors Data Model Reference
Data Models Guide for information about how to set up the Country/Re-
gion-Specific Succession Data Models.

Step 8: Importing the Picklists Implementing Picklists

This guide explains picklists and how to import the different

values that a customer sees when they select a dropdown
menu.

Step 9: Creating Foundation Objects Foundation Objects [page 26]

This section describes what foundation objects are including

how you can define them.

Implementing Employee Central Core

Employee Central Overview PUBLIC 9
For information on this step… See…

Optional: Configuring Position Management Implementing Position Management in Employee Central

This guide explains how to set up position management

in Employee Central. If you plan on using position manage-
ment, then it should be set up before creating business rules
since many business rules and event/workflow derivation
are based off of Position Management configuration (sync,
position change, and on).

Step 10: Configuring Business Rules Business Rules in Employee Central [page 139]

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 136]

This section describes how to set up the different rules. De-

pending on the attributes that change, the system automati-
cally determines the rule to apply.

Step 12: Creating Workflow Derivation Rules as well as Work- Implementing and Configuring Workflows in Employee Cen-
flows tral guide in the SAP Help Portal.

This guide describes what workflows are, when to use them,

and how to set them up.

Step 13: Setting Role-Based Permissions Permissions for Employee Central [page 99]

This section describes which permissions are specific to Em-

ployee Central and how you manage them.

Please refer to the Role-Based Permissions guide on the SAP

Help Portal for details on how to set up permission roles,
permission groups, and permission assignments.

Step 14: Importing Employee Data Employee Central Imports

This guide describes everything you need to know about

importing employee data.

Step 15: HRIS Sync Human Resource Information System (HRIS) Synchroniza-
tion [page 236]

This section describes how you can sync data from Em-
ployee Central to other modules.

Implementing Employee Central Core

10 PUBLIC Employee Central Overview
For information on this step… See…

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 absence as standalone or together with other Time Off
features. Depending on this decision, the setup varies.

You can find more information about how to set up leave

of absence in the Implementing Employee Central Time Off
guide on the SAP Help Portal.

Optional: Setting Up Payment Information Employee Central Payment Information

This guide explains how to set up the MDF-based payment

information for users in the system.

Optional: Setting Up People Profile People Profile

This guide explains how to set up the People Profile in your

instance.

Optional: Setting Up Global Assignments Configuring Global Assignments

This guide explains how to set up global assignments in Em-

ployee Central.

Optional: Setting Up Concurrent Employment Configuring Concurrent Employment

This guide explains how to set up concurrent employment in

Employee Central.

Optional: Setting Up Contingent Workforce Implementing and Managing a Contingent Workforce

This guide explains how to set up contingent workers in Em-

ployee Central.

Optional: Setting Up Document Generation Implementing Document Generation in Employee Central

This guide explains how to set up document generation in

Employee Central.

Optional: Setting Up Employee Central Advanced Reporting Employee Central Advanced Reporting: Standard Reports

This guide explains how to set up standard reports for the

different areas in Employee Central.

Optional: Setting Up Mobile SAP SuccessFactors Mobile Deployment Guide.

This guide describes how to set up & use Employee Central

on your mobile devices.

Implementing Employee Central Core

Employee Central Overview PUBLIC 11
For information on this step… See…

Optional: Setting Up Employee Central Payroll Implementing Employee Central Payroll

This guide describes how to set up Employee Central Payroll.

 Note
If you want to have the same IDs in the Employee Cen-
tral and Employee Central Payroll systems, we recom-
mend that you use numeric employee IDs in Employee
Central, because the PERNR is numeric in Employee
Central Payroll. 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 higher duty or temporary

assignments.

Optional: Setting Up Job Profile Builder Job Profile Builder

This guide describes how to set up the Job Profile Builder

tool.

1.3.1 Recommended Implementation Sequence with Other

Modules

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.

Employee Central Recruiting Onboarding

Recruiting Onboarding 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

Implementing Employee Central Core

12 PUBLIC Employee Central Overview
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 HXM 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.

Assignment ID (assignment_id_external) is unique, case-sensitive, visible, and can be given to an employee, a

contingent worker, or an intern. Assignment ID is used to identify users across the HXM Suite, in import and
export tools, in the user interface, in APIs, and in reports.

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
have used a business rule to generate assignment IDs, the system then creates assignment IDs based on the
rule and the assignment IDs might be different from the user IDs. When you create new users using the user
management tools such as Employee Import, Manage Users, or OData APIs, assignment IDs for these users are
also added to the system.

Assignment ID can be changed ONLY through the convertAssignmentIdExternal function import.

Why Assignment ID?

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 in Employee Central Integration

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

Implementing Employee Central Core

Employee Central Overview PUBLIC 13
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.

Check Tool for Employment Information

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.

1.4.1 Differentiating Between Person ID, UUID, User ID, and

Assignment ID

Read the following table to find the differences and relationships between person ID, UUID, user ID, and
assignment ID.

Relationship between these

Field Description Can this ID be changed? IDs

Person ID (person-id-exter- A unique identifier of a per- Yes UUID and person ID are in a
nal) son in Employee Central. Per-
one-to-one relationship.
son ID identifies a natural
person. An employee gener- User ID and assignment ID
ally has only one person ID are in a one-to-one relation-
throughout their time at the
ship.
company, since this ID is as-
sociated to each person. One person ID is associated

UUID (per-person-uuid) This identifier is generated No to one or more user IDs and
when person data is created assignment IDs.
in the system. UUID is in-
One UUID is associated to
troduced for integrating per-
son data in Employee Central one or more user IDs and as-
with other modules. UUID is signment IDs.
stored at a database level
only and is not visible on the
UI.

Implementing Employee Central Core

14 PUBLIC Employee Central Overview
 Relationship between these
Field Description Can this ID be changed? IDs

User ID (users-sys-id) A unique identifier of user No

entity. A person might have

one or more user IDs, for ex-
ample, in the case of global
assignments or concurrent
employments. If a customer
has only one employment for
each person in SAP Success-
Factors, the user ID can serve
as the person’s unique identi-
fier in the company.

Assignment ID (assignment- Assignment ID is actually the Yes

id-external)
"mutable user ID". It is visi-
ble to customers and can
be used to identify users. A
person might have one or
more assignment IDs, for ex-
ample, in the case of global
assignments or concurrent
employments. If a customer
has only one employment for
each person in SAP Success-
Factors, assignment ID can
serve as the person’s unique
identifier in the company.

In Employee Central, the as-

signment ID field can be
used to store a unique iden-
tifier. For example, in the
Employee Central integration
scenarios, customer store
the SAP ERP PERNR (per-
sonnel number) in this field.

Implementing Employee Central Core

Employee Central Overview PUBLIC 15
 Figure 1: Relationship Between Person ID, UUID, User ID, and Assignment ID

1.5 Components for SAP SuccessFactors Employee Central

Here is a list of the most used components for Employee Central

Component Description

LOD-SF-EC Employee Central

LOD-SF-EC-TIM Time Off

LOD-SF-EC-POS Position Management

LOD-SF-EC-WFL Workflows

LOD-SF-EC-GBF Global Benefits

LOD-SF-EC-RUL Business Rules and Event Derivation

LOD-SF-EC-HIR Hire, Rehire

LOD-SF-EC-JOB Job Information and Propagation

LOD-SF-EC-PAY Payment Information

LOD-SF-EC-TMS Time Sheet

Implementing Employee Central Core

16 PUBLIC Employee Central Overview
Component Description

LOD-SF-EC-MDF Metadata Framework

LOD-SF-EC-BCI (BCUI) Business Configuration UI

LOD-SF-EC-LOC Localization

LOD-SF-EC-CMP Compensation Information

LOD-SF-EC-PER Person Information

LOD-SF-EC-INT Integration - EC to RCM, ONB, CVP

LOD-SF-EC-EDP Employee Data Imports

LOD-SF-EC-DOC Document Generation

LOD-SF-EC-RBP Role-Based Permissions

LOD-SF-EC-CWF Contingent Workforce Management

LOD-SF-EC-CGA Concurrent Employment &Global Assignment

LOD-SF-EC-EMP Employment Information

LOD-SF-EC-HRS HRIS Sync

LOD-SF-EC-PP3 People Profile

LOD-SF-EC-SRV Employee Central Service Center

LOD-SF-EC-FOO Foundation Objects

LOD-SF-EC-AAD Advances and Deductions

LOD-SF-EC-MOB Mobile

LOD-SF-EC-ALR Alerts and Notifications

LOD-SF-EC-DPD Dependents Management

LOD-SF-EC-ADM Admin Tools

LOD-SF-EC-APM Employee Central Apprentice Management

LOD-SF-EC-CSO Company Structure Overview

Implementing Employee Central Core

Employee Central Overview PUBLIC 17
1.6 Data Protection and Privacy for Employee Central

Here are some data protection and privacy features specific to Employee Central rather than the entire HXM
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.

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 block.

The following core areas support read audit. Note that Address and Deductions do not support read audit.

Area Sub-area

Personal Information Person Information

Personal Information Personal Information

Personal Information Global Information

Personal Information Email Information

Personal Information Phone Information

Personal Information Social Account Information

Personal Information Primary Emergency Contact

Personal Information National ID Information

Implementing Employee Central Core

18 PUBLIC Employee Central Overview
Area Sub-area

Personal Information Work Permit Information

Job Information Job Information

Job Information Job Relationship

Job Information Employment Information

Job Information Compensation Information

Job Information Pay Component Recurring

Job Information Pay Component Non-Recurring

Change Audit

The following core areas support the change audit. This includes both effective and non-effective dated
entities.

Area Sub-area

Employment Information Employment Info

Employment Information Job Information

Employment Information Job Relationship

Employment Information Compensation Info - Pay Component Recurring & Spot Bo-
nus

Personal Information Address

Personal Information Biographical

Personal Information Dependents

Personal Information Email Info

Personal Information Emergency Contact

Personal Information IM Info

Personal Information National Id

Personal Information Personal Information & Person Global

Personal Information Phone Info

Implementing Employee Central Core

Employee Central Overview PUBLIC 19
Area Sub-area

Personal Information Work Permit Info

The following changes are included in the Change Audit report:

Entity Change Abbreviation

Non-Effective-Dated Create I

Non-Effective-Dated Change U

Non-Effective-Dated Delete D

Effective-Dated Create I

Effective-Dated Insert a new record in an existing record EDU

Effective-Dated Change to an existing record COR

Effective-Dated Delete EDD

 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.

Implementing Employee Central Core

20 PUBLIC Employee Central Overview
2 Configuring the System

2.1 Provisioning

Provisioning is an internal tool that Professional Services 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.

2.2 Configuration Tasks

To get started with the customer 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 the customer's 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

An instance has already been created for the customer.

Tasks

Do the initial configuration tasks in the following sequence.

Setting Up the Basics [page 22]

Setting Up Attachment Options [page 24]

Implementing Employee Central Core

Configuring the System PUBLIC 21
Creating a Super Admin User in Provisioning [page 24]

Configuring Company System Settings [page 91]

Configuring Employee Central Settings [page 91]

Enabling the Employee Central SOAP APIs [page 92]

Configuring the Internal Job History Block [page 93]

Setting Up the Currency Exchange Rate [page 95]

Creating the Employment Settings Configuration Object

Additional features you can enable based on your requirements:

• Check Tool

 Tip

We also recommend that you review the IT Landscape Requirements for SAP SuccessFactors guide for
information about the allow list for APIs, time synchronization, certificate renewals, and cookie handling.

2.2.1 Setting Up the Basics

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.

2. Select Edit Company Settings Company Settings .

3. Enable the company languages by selecting the checkboxes of the relevant language packs.
Make sure you select a minimum of one language pack.
4. Select the following Employee Central checkboxes:
• Enable the Attachment Manager
• Employee Profile Data Audit
• Employee Central Foundation Objects
• Enable Translation of Employee Central Foundation Objects - required Employee Central Foundation
Objects, Enable Generic Object and Enable the Attachment Manager

Implementing Employee Central Core

22 PUBLIC Configuring the System
 • Effective Dated Data Platform
• Enable Effective-Dated Fields in Basic Import
• Employee Central V2 (Event Reason Derivation) - requires Effective Dated Data Platform
• Enable Business Configuration in Admin Tools - requires Enables Generic Objects, Employee Central
V2 (Event Reason Derivation), Enable the Attachment Manager, Effective Dated Data Platform,
Employee Profile Data Audit
• Enable Generic Objects - requires Enable the Attachment Manager
5. Select the Role-based Permission checkbox:
• Role-based Permission (This will disable Administrative Domains)
• Dynamic Groups V2 (My Groups)
6. Select the data retention management checkbox:
• Enable Data Retention Management
Enter the minimum number of approvers required by the company

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 block (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 block, if you
want to enable the new Payment Information block, 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:

• Hide user name from UI

9. Scroll back up to the top and select Save Feature.

Implementing Employee Central Core

Configuring the System PUBLIC 23
2.2.2 Setting Up Attachment Options

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

Attachment Storage Allocation 1G

Attachment User Limit No Limit

Attachment Max Size 5M

Attachment Limit Notification Monitor Period Never

3. Save your settings.

2.2.3 Creating a Super Admin User in Provisioning

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

You have Provisioning access to the instance.

Implementing Employee Central Core

24 PUBLIC Configuring the System
  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. Log into Provisioning and select the company instance you wish to access.

2. Go to Edit Company Settings Company Settings .

3. Search or scroll down the page to find the section with "super admin" settings.
4. Provide all of the following information.

Setting Description

Admin Username Determines both Username and User ID of the super ad-
min user.

Admin Password Password with which super admin can access your sys-
tem.

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.

Admin Email Email address to which super admin receives notifica-

tions.

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
Partial 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.

Implementing Employee Central Core

Configuring the System PUBLIC 25
 Setting Description

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
notification to one address.

As a Provisioning user, it is your responsibility to

notify the customer and share this information with
more people if necessary.

5. Select Create Admin.

 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.

6. Save your changes.

Results

The super admin user account is created and the customer is notified at the email address provided.

2.2.4 Data Models

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.

2.2.5 Foundation Objects

Foundation objects are used to set up data that can be shared across the entire company, such as job codes,
departments, or business units. Foundation objects are sometimes referred to as “foundation tables”.

Foundation objects are the first objects you should load because some of the lists of values proposed in
employment information come from the Foundation Objects.

You can use Foundation Objects to populate data at the employee level. For example, if you assign a job code
to an employee, that employee’s record is then populated with all information based on the attributes of the job

Implementing Employee Central Core

26 PUBLIC Configuring the System
code. Additionally, the relationships that are configured between the Foundation Objects can be used to filter
the lists of values in Employment Information. For example, the list of pay components that are selectable on
an employee’s record can be filtered based on the country the employee is associated with as determined by
the employee’s Legal Entity.

Some Foundation Objects are predelivered for you in the Corporate Data Model. For a list of these object, refer
to Predelivered Foundation Objects in Corporate Data Model in the SAP SuccessFactors Data Model Reference
Guide on the SAP Help Portal.

Importing Foundation Objects

You need to import the data into the system using different methods and in a specific order. The import
methods are as follows:

• Foundation Data Imports

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

Accessing Foundation Objects

• 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.

Implementing Employee Central Core

Configuring the System PUBLIC 27
Check Tool for Associations

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

Importing Foundation Data

Employee Data Imports
Employee Data Import Process

2.2.5.1 Characteristics of Foundation Objects

Here's a summary of the features available in foundation objects.

Features

• Each foundation object consists of one or more fields. Some of them are required if you use the relevant
object.
• Each foundation object has a technical ID, called an hris-element-id. You cannot change this.
• For each foundation object, you must enter an external code. This is a short unique identifier.

 Note

Once you've entered the external code, do not change it, as this can lead to data inconsistencies.

• Each standard field within a foundation object also has a technical field ID. You cannot change this.
• However, you can change the labels of the foundation objects and the fields each object contains. The label
is the descriptor that appears on the user interface (UI).
• The order in which the fields are displayed on the UI is the same as the order in which you list them in the
setup of the foundation object.
For Legacy FOs only: The start date will always appear at the top of the screen.
• You can decide whether a field actually appears on the UI and, if so, whether:
• It is required or optional
• It is read-only or whether users can change or edit it
• Every foundation object contains custom fields. These are empty fields you can use to handle data not
covered by the standard fields.

Implementing Employee Central Core

28 PUBLIC Configuring the System
• Many, but not all foundation objects, are “effective dated”.
• For each foundation object, you can determine the relationship to other foundation objects through the use
of “associations”.
• The use of onChange business rules isn't supported for foundation objects.
• The search criteria for foundation objects can only be string texts. They cannot be picklists or generic
objects.

 Note

For example, if you configure the city field in the Corporate Data Model as a picklist for a country/
region X, you can’t use city in the search criteria for location. If you do, you won’t be able to search
locations by city for country/region X.

2.2.5.2 MDF vs. Legacy Foundation Objects

There are many similarities between MDF Foundation Objects and Legacy Foundation Objects. Both serve to
provide foundational data that organizations can use to structure their companies. Both provide the ability
to store attributes on the object level that can be referenced or propagated to the employee’s job and
compensation records.

However, MDF and Legacy Foundation Objects are built on two separate platforms, which result in different
ways of accessing, configuring, and managing the objects and corresponding data. Below is a table which
summarizes the key differences between the two object types.

Legacy Foundation Object MDF Foundation Object

Configuring the Object Provisioning Corporate Data Admin Center Configure Object

Model and CSF Corporate Data Model Definitions

 Remember
As a customer, you don't have ac-
cess to Provisioning. To complete
tasks in Provisioning, contact your
implementation partner or Account
Executive. For any non-implemen-
tation tasks, contact Product Sup-
port.

Implementing Employee Central Core

Configuring the System PUBLIC 29
 Legacy Foundation Object MDF Foundation Object

Managing the Object Values/Data Admin Center Manage Admin Center Manage Data
Organization, Pay, and Job

Structures .

 Note
You need the Manage Organization,
Pay and Job Structures permission
to access the Manage Organization,
Pay and Job Structures user inter-
face.

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

Type “Foundation Objects” Data

Mass Deleting Object Values/Data Manual deletion only using Admin Admin Center Import and Export

Center Manage Organization, Pay, Data

and Job Structures Use the “Operation” column to indicate

Alternatively, you can import the foun- which data should be deleted upon im-

dation data and switch the “status” port.

from “Active” to “Inactive”

 Note
You need the Access Manage
Organization, Pay and Job
Structures page permission to ac-
ces 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 cus-
tom fields you can create for MDF ob-
• String
jects. In addition to the data types sup-
• Date
ported for Legacy FOs, there are addi-
• Decimal tional field types available.
• Long
For more information, refer to the Im-
• Number plementing the Metadata Framework
guide on the SAP Help Portal.

Implementing Employee Central Core

30 PUBLIC Configuring the System
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 opposite is not true – all functionality that is supported for MDF Objects is NOT supported for Legacy
Foundation Objects. MDF Objects contain a plethora of additional supported capabilities, including the support
of business rules, field-level permissions, and more.

Related Information

Implementing the Metadata Framework (MDF)

Migrating to MDF Foundation Objects

2.2.5.3 Deleting a Foundation Object

To correct an error, you may need to delete a foundation object or a foundation object value at some point.

Context

If a Foundation Object value is required to be removed from the UI, it is vital to consider the following points:

• 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.

Implementing Employee Central Core

Configuring the System PUBLIC 31
Procedure

1. To manually delete a foundation object value, complete the following:

a. Go to Admin Center Manage Data .

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

a. Go to Admin Center Import and Export Data .

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

2.2.5.4 Forward Propagation for Foundation Objects

Some legacy Foundation Objects available in the Admin Center Manage Organization, Pay, and Job
Structures do not support forward propagation, whereas others do.

Table 1: Foundation Objects Where Forward Propagation is Supported

Foundation Object Supports Forward Propagation

Cost Center Yes

Business Unit Yes

Department Yes

Division Yes

Legal Entity Yes

Legal Entity Local Yes

Job Function Yes

Pay Group Yes

Pay Calendar Yes

Job Family (Deprecated) Yes

Job Classification Yes

Job Classification Local Yes

Implementing Employee Central Core

32 PUBLIC Configuring the System
Table 2: Foundation Objects Where Forward Propagation is NOT Supported

Foundation Object Forward Propagation

Dynamic Role No

Event Reason No

Frequency No

Geozone No

Location No

Location Group No

Pay Component No

Pay Component Group No

Pay Grade No

Pay Range No

Workflow No

2.2.5.5 Validations for Foundation Objects, Generic

Objects, Associations, and Picklists

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:

• Does the value exist? Is the value correct?

• Is the generic object or foundation object valid and active as of the effective date of the data change?

 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'.'

Using the Check Tool

You can also use the Check Tool to find any inconsistencies. We recommend selecting checks available under
the following sections:

Implementing Employee Central Core

Configuring the System PUBLIC 33
• 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 Object Relationship Area
• Check Tool System Health Tab Employee Central Core Picklist Area
• Check Tool System Health Tab Employee Central Core Picklist Usages Area

2.2.5.6 Requirements for Legacy Foundation Objects

Here are the requirements for the use of legacy foundation objects.

With Employee Central

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

• In Provisioning,
• Enable Employee Central Foundation Objects
• Activate the Enable Translation of Employee Central Foundation Objects setting

 Remember

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.

Without Employee Central

If you haven't enabled Employee Central, you can still use legacy foundation objects by following the preceding
steps.

 Remember

To use foundation objects without Employee Central, you must configure foundation objects, for example,
Location, in the Corporate Data Model.

Implementing Employee Central Core

34 PUBLIC Configuring the System
Related Information

Foundation Objects [page 26]

2.2.5.7 Associations

Associations define relationships between foundation objects.

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 for Associations

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:

• 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 73]

Implementing Employee Central Core

Configuring the System PUBLIC 35
2.2.5.7.1 Using Associations to Structure Your Business

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:

• Legal Entity and Business Unit

• Business Unit and Division
• Division and Department

We can also see the ONE-TO-ONE associations between the following objects:

• Location Group and Location

• Geo Zone and Location Group

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.

Implementing Employee Central Core

36 PUBLIC Configuring the System
2.2.5.7.2 Examples of Foundation Object Associations

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.

Source Target Multiplicity Description

Location Geozone ONE_TO_ONE A location can only belong to

one geozone. (Location is the
driving object.)

Legal Entity Location ONE_TO_MANY Several companies can have

the same location. (Legal En-
tity is the driving object.)

Business Unit Division ONE_TO_MANY A business unit can be asso-

ciated with several divisions.
(Business Unit is the driving
object.)

Implementing Employee Central Core

Configuring the System PUBLIC 37
Source Target Multiplicity Description

Division Department ONE_TO_MANY A division can be associated

with multiple departments.
(Division is the driving ob-
ject)

Business Unit Job Code ONE_TO_MANY A job code can be used

across several business
units. (Business Unit is the
driving object.)

Pay Range Geozone ONE_TO_ONE Companies generally have

different pay ranges for each
combination of Legal Entity,
Job Code, and Geozone.

Pay Range Pay Grade ONE_TO_ONE A pay range is generally asso-

ciated with one pay grade.

Pay Range Legal Entity ONE_TO_ONE Companies generally have

different pay ranges for each
combination of Legal Entity,
Job Code, and Geozone.

Pay Component Group Pay Component ONE_TO_MANY A pay component group can
contain multiple pay compo-
nents.

Pay Group Legal Entity ONE_TO_ONE A pay group is generally as-

sociated with one legal entity.

2.2.5.7.3 Configuring Associations

You need to fully understand the relationships between foundation objects in order to define them correctly in
the system.

With the migration of Foundation Objects to MDF FOs, the HRIS elements of the migrated objects are no longer
available in the Corporate Data Model XML as an association destination. This requires a solid understanding
of the association requirements, in order to configure the association in the correct manner. 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, see Working with
Associations, Field Criteria and Value Help [page 73] topic.

Implementing Employee Central Core

38 PUBLIC Configuring the System
Creating Associations Between Different Blocks

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 compensation info block based on job info criteria. 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 that is part of the payComponentRecurring block is filtered based on the field
payScaleGroup from the job info 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.

The next few sections describe how you can get associations to work for the following scenarios.

• Legacy Foundation Object filtering another Legacy Foundation Object

• Foundation Object filtering a Generic Object
• Generic Object filtering a Foundation Object
• Generic Object filtering another Generic Object

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.

2.2.5.7.3.1 Filtering Custom Fields in Foundation Objects

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

Implementing Employee Central Core

Configuring the System PUBLIC 39
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

1. Go to Admin Center Company Settings Company System and Logo Settings .

2. Under Company System Settings, select the checkbox Disable filter for custom fields of type Foundation
Object. To activate this setting, upload any data model in provisioning.
3. Save your settings.

2.2.5.7.3.2 Configuring a Generic Object to Filter Another

Generic Object Using Associations

It is possible to use one generic object as a filter for another.

Context

To understand the steps involved, consider the following example of the Generic Object
cust_MarketCategory being filtered by the Generic Object cust_FunctionalArea.

External Name Of Generic Object doing filtering cust_FunctionalArea

Technical Name of field on Position referencing Generic Ob- cust_FunctionalArea_field

ject doing filtering

Technical Name of field on Position referencing Generic Ob- cust_jobMarketCategory_field

ject being filtered

External Name Of Generic Object to be filtered cust_jobMarketCategory

2.2.5.7.3.2.1 Step 1: Configuring the Association to the

Generic Object to be Filtered

Configure the association on the Generic Object to be filtered.

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:

Implementing Employee Central Core

40 PUBLIC Configuring the System
Procedure

1. Create the Generic Objects that will do the filtering and be filtered.

2. Go to Admin Center Configure Object Definitions .

3. From the Search dropdown, select Object Definition and then select Job Market Category (the Generic
Object to be filtered) from the dropdown next to it.

The Configure Object Definitions page is displayed.

4. From the Take Action dropdown, select Make Correction.
5. Scroll to the Associations section at the bottom.
6. Select Details. We will now set the association for the child object, meaning the object to be filtered.
7. In the Name field, specify a name for the association.
8. In the Multiplicity field, select the type of association, either One to One or One to Many.
9. In the Destination Object field, select the Generic Object that will filter the values for this Generic Object on
the UI.

Results

A sample completed entry is shown below.

Implementing Employee Central Core

Configuring the System PUBLIC 41
2.2.5.7.3.2.2 Step 2: Attaching the Relevant Parent Generic
Object Values to the Child Generic Object

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

1. Go to Admin Center Manage Data .

2. From the Create New dropdown, select Job Market Category.
3. In the externalCode field, specify the name of the child Generic Object value to be filtered.
4. In the externalName field, specify the external name for this object.
5. In the effectiveStartDate field, specify the start date.
6. From the functionalArea dropdown, select the parent Generic Object value doing the filtering. In this case,
HR.
7. Save your changes.

Results

Implementing Employee Central Core

42 PUBLIC Configuring the System
2.2.5.7.3.2.3 Step 3: Defining Field Criteria for the Generic
Object Field Being Filtered

In the Succession Data Model, 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

1. Define the field criteria for the Generic Object being filtered in the Succession Data Model.
2. Save your changes.

Results

 Note

The field name of the internal code on the parent Generic Object can be derived from the
<internalCode> database field named found in the Configure Object Definition page.

 Note

The field-criteria attribute is not supported for the Country/Region-Specific Succession Data Model.

Implementing Employee Central Core

Configuring the System PUBLIC 43
2.2.5.7.3.2.4 Step 4: Defining the Field Criteria for the Child
Generic Object Being Filtered

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

1. Go to Admin Center Configure Object Definitions .

2. From the Search drop-down list, select Object Definition and then select Position from the drop-down list
next to it.

The Configure Object Definitions page is displayed.

3. From the Take Action drop-down list, select Make Correction.
4. In the Fields section, scroll to the Generic Object field to be filtered. In this case,
cust_jobMarketCategory_field.
5. Select the Details link to view the configuration.

Implementing Employee Central Core

44 PUBLIC Configuring the System
2.2.5.7.3.3 Configuring a Generic Object to Filter Another
Generic Object Using Field Criteria Only

It is possible to use one generic object as a filter for another using field criteria.

Context

It is possible to filter one-to-one associations.

2.2.5.7.3.3.1 Step 1: Configuring the Field to the Generic

Object to be Filtered

Configure the association on the Generic Object to be filtered.

Context

This allows you to attach the parent Generic Object doing the filtering to the child Generic Object being filtered.

Procedure

1. Go to Admin Center Configure Object Definitions .

2. From the Search dropdown, select Object Definition and then select the Generic Object to be filtered from
the dropdown next to it.

The Configure Object Definitions page is displayed.

3. From the Take Action dropdown, select Make Correction.
4. Scroll to the end of the Fields list and add a new field.

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.

Implementing Employee Central Core

Configuring the System PUBLIC 45
6. Save your changes.

2.2.5.7.3.3.2 Step 2: Attaching the Relevant Parent Generic

Object Values to the Child Generic Object

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

1. Go to Admin Center Manage Data .

2. From the Search dropdown, select the child object type and search for the object to be filtered.
3. From the Take Action dropdown, select Make Correction.
4. For the field to be filtered, add the parent value.

Implementing Employee Central Core

46 PUBLIC Configuring the System
5. Save your changes.

2.2.5.7.3.3.3 Step 3: Adding Field Criteria to Child Object in

the Data Model

In the Succession Data Model, 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

1. Go to Admin Center Manage Business Configuration .

2. Go to the child value field (the field to be filtered).
3. Select Details to add the criteria.
4. For Destination Field Value, select the identifier of the parent field in Job Information. For the Source Field
Name, add the field from Step 1: Configuring the Field to the Generic Object to be Filtered [page 45] .

Implementing Employee Central Core

Configuring the System PUBLIC 47
5. Save your changes.

Implementing Employee Central Core

48 PUBLIC Configuring the System
2.2.5.7.3.4 Configuring a Generic Object to Filter a
Foundation Object

It is possible to use one generic object as a filter for a foundation object.

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.

External Name of Generic Object doing filtering LegalEntity

Technical name of field on Position referencing the Generic company

Object doing filtering

Technical name of Foundation Object field on Position being location

filtered

Technical name of Foundation Object field on Job location

Information being filtered

Field name on Job Information referencing Generic Object company

doing the filtering

Foundation Object to be filtered location

2.2.5.7.3.4.1 Step 1: Adding an Association to the Generic

Object in the Foundation Object Element to
Be Filtered

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

In this example, the association is added to the location.

Implementing Employee Central Core

Configuring the System PUBLIC 49
2.2.5.7.3.4.2 Step 2: Attaching the Parent Generic Object
Values to the Foundation Object

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

1. Go to Admin Center Manage Organization, Pay and Job Structures .

2. From the Search drop-down list, select Location (the object whose values will be filtered) and then select
the relevant location from the drop-down next to it. For this example, let’s select London. The Configure
Object Definitions page is displayed.

Implementing Employee Central Core

50 PUBLIC Configuring the System
Implementing Employee Central Core
Configuring the System PUBLIC 51
2.2.5.7.3.4.3 Step 3: Defining Field Criteria in the Succession
Data Model for the Foundation Object Field
being Filtered (For Job Information)

Define field criteria for the foundation object field being filtered in the Succession Data Model.

Context

This specifies which Generic Object is doing the filtering and the field that references it on Job Information.

 Note

The field-criteria attribute is currently not supported for the Country/Region-Specific Succession Data
Model.

2.2.5.7.3.4.4 Step 4: Defining Field Criteria for the

Foundation Object Field to be Filtered (For
Position)

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.

Implementing Employee Central Core

52 PUBLIC Configuring the System
Procedure

1. Go to Admin Center Configure Object Definitions .

2. From the Search drop-down list, select Object Definition and then select Position from the drop-down next
to it.

The Configure Object Definitions page is displayed.

3. From the Take Action drop-down list, select Make Correction.
4. In the Fields section, scroll to the Generic Object field to be filtered. In this case, location.
5. Select the Details link to view the configuration.
6. Scroll to the Field Criteria section.
7. In the Source Field Name field, enter the external name of the Generic Object doing the filtering.
8. In the Destination Field Value field, enter the technical field name of the Generic Object field doing the
filtering on the Position object, for example, the technical name for company (GO doing the filtering)

9. Save your changes.

2.2.5.7.3.5 Configuring a Foundation Object to Filter Another

Foundation Object

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.

Name of the Foundation Object doing the filtering Location Group

Name of the Foundation Object being filtered Location

Implementing Employee Central Core

Configuring the System PUBLIC 53
2.2.5.7.3.5.1 Step 1: Adding an Association to the Foundation
Object to be Filtered

In the Corporate Data Model, add an association to the Foundation Object to be filtered.

Context

In this example, an association is added to the location.

2.2.5.7.3.5.2 Step 2: Attaching the Parent Foundation Object

Values to the Foundation Object

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

1. Go to Admin Center Manage Organization, Pay and Job Structures .

2. From the Search drop-down list, select Location (the object to be the subject of filtering) and then select
the relevant Location values that will filter the chosen Location from the drop-down list next to the Location
field. For this example, let’s select ACE_STO_BE.

The Foundation Object page is displayed.

3. Select Insert New Record.
4. Specify the Location Group for the child foundation object. This will update the page.

Implementing Employee Central Core

54 PUBLIC Configuring the System
5. Save your changes.

2.2.5.7.3.5.3 Step 3: Defining Field Criteria in the Succession

Data Model

Define field criteria in the Succession Data Model (SDM) for the Foundation Object field being filtered (in this
case, location).

This step is to be done for Job Information in the Succession Data Model. For the Position object, see the next
step.

Here, we are using a custom field in the field criteria, <custom-string2>, to refer to <locationGroup> since
locationGroup is not a standard field of Job Information.

Implementing Employee Central Core

Configuring the System PUBLIC 55
2.2.5.7.3.5.4 Step 4: Defining Field Criteria for the Foundation
Object Field to Be Filtered (For Position)

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

1. Go to Admin Center Configure Object Definitions .

2. From the Search drop-down list, select Object Definition and then select Position from the drop-down next
to it.

The Configure Object Definitions page is displayed.

3. From the Take Action drop-down, select Make Correction.
4. In the Fields section, scroll to the Generic Object field to be filtered. In this example, cust_locationGroup.

 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.

5. Select the Details link to view the configuration.

6. Scroll to the Field Criteria section.
7. In the Source Field Name field, enter the external name of the Foundation Object doing the filtering.
8. In the Destination Field Value field, enter the technical field name of the Foundation Object field doing the
filtering on the Position object.

Implementing Employee Central Core

56 PUBLIC Configuring the System
9. Save your changes.

2.2.5.7.3.6 Configuring a Foundation Object to Filter a

Generic Object

It is possible to use one foundation object as a filter for a generic 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.

Name of the Generic Object to be filtered cust_GradeLevel

Technical Name of Field on Position of Generic Object being cust_GradeLevel_field

filtered

Technical Name of Field on Position of Generic Object doing payGrade

filtering

Implementing Employee Central Core

Configuring the System PUBLIC 57
Name of the wrapper Generic Object required to connect FOWPayGrade
the Generic Object to be filtered to the Foundation Object
(Note that this is a pre-delivered wrapper. It is important
that you do not create or use a custom wrapper.)

Name of the association to the object doing the filtering cust_toFOWPayGrade

configured on the Generic object to be filtered (Note that
this association name follows the recommended naming
guideline. For ease of use, it is suggested that you follow the
same protocol: cust_to<Object External Code>.

Element name of the Foundation Object doing the filtering payGrade

in the Corporate Data Model

2.2.5.7.3.6.1 Step 1: Associating the Generic Object Wrapper

to the Child Generic Object

Associate the wrapper to the child generic object, which means the field that should have its values filtered.

Context

In the example, we associate the wrapper to cust_GradeLevel_field.

Procedure

1. Go to Admin Center Configure Object Definitions .

2. In the Search field, select Object Definition and then select Grade Level (the object whose values will be
filtered) from the drop-down next to it.
3. From the Take Action drop-down, select Make Correction.
4. Scroll to the Associations section at the bottom and create an association between the wrapper
(cust_toFOWPayGrade) and the Generic Object (Grade Level).

5. Save your changes.

Implementing Employee Central Core

58 PUBLIC Configuring the System
2.2.5.7.3.6.2 Step 2: Associating Values to be Filtered

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

1. Go to Admin Center Manage Data .

2. Choose the relevant values to be filtered and attach the values doing the filtering to this object.

3. Save your changes.

2.2.5.7.3.6.3 Step 3: Defining the Field Criteria for the

Generic Object Field Being Filtered

In the Succession Data Model, define the field criteria for the Generic Object field being filtered.

Context

This configuration ensures that the association works on Job Information.

Implementing Employee Central Core

Configuring the System PUBLIC 59
  Note

The field-criteria attribute is currently not supported on the Country/Region-Specific Succession Data
Model.

2.2.5.7.3.6.4 Step 4: Defining Field Criteria for the Generic

Object Field being Filtered

Define field criteria for the Generic Object field being filtered on the Position Generic Object.

Context

This step is to be done only when Position Management is enabled.

Procedure

1. Go to Admin Center Configure Object Definitions .

2. From the Search drop-down, select Object Definition and then select Position from the drop-down next to it.

The Configure Object Definitions page is displayed.

3. From the Take Action drop-down, select Make Correction.
4. In the Fields section, scroll to the Generic Object field to be filtered. In this example, cust_GradeLevel_field.
5. Select the Details link to view configuration.

Implementing Employee Central Core

60 PUBLIC Configuring the System
 Things to note for this scenario:
• When adding an association from a migrated GO to a Foundation Object, you must use one of the
pre-delivered wrappers like FOWPayGrade (Pay Grade Wrapper) instead of creating a custom wrapper.
However if OData or API features are enabled, it is important that you do NOT use a pre-delivered
wrapper for associations from other MDF objects to Foundation Objects. Pre-delivered wrappers can
be identified by their names: ‘<FO Name> Wrapper’ and their external code ‘FOW<FOName>’.
• If OData or API features are not enabled, it is possible to use pre-delivered wrappers as association
destination at more than one MDF object types. To do this you must manually remove the field criteria
for effective start date at the field “parent” of the FO wrapper type. There is the restriction that the FO
instances cannot be filtered by the parent’s effective start date.
• If a pre-delivered wrapper type is not used as association destination of CostCenter by an OData or
API customer, the pre-delivered wrapper type must be used to configure a Foundation Object to filter a
Generic Object.
6. Save your changes.

Implementing Employee Central Core

Configuring the System PUBLIC 61
2.2.5.8 Effective Dating

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.

2.2.5.8.1 Changing a Legacy Foundation Object

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

1. Go to Admin Center Manage Organization, Pay and Job Structures .

2. The Search drop-down menu, select Location
3. Locate the Location object you want to amend and select it. Once it has loaded on the screen, select Insert
New Record.
4. Set the start date for when the change should go into effect. By default, the date is today’s date.

Implementing Employee Central Core

62 PUBLIC Configuring the System
 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.

 Note

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.

5. Save your 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.

Implementing Employee Central Core

Configuring the System PUBLIC 63
2.2.5.9 Foundation Objects for Structuring Your Business

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.

Organization Objects A-Z

Object Object Type Description

Legal Entity MDF The legal entity table stores all the le-
gal entities of a company. No legal en-
tity can cover more than one country,
so the country in the legal entity de-
termines the country of employees as-
signed to the legal entity.

This MDF FO can also store country/re-

gion-specific information for each le-
gal entity in the country/region-specific
child object. There are 5 pre-delivered
countries: USA, DEU, ARG, ESP, FRA.
For all other countries, custom child ob-
jects have to be defined by the name of
cust_LegalEntity<country ISO code>.

For more information on adding coun-

try/region-specific fields, refer to Add-
ing a New Country/Region and Related
Fields to LegalEntity [page 82] in the
next chapter of this guide.

Business Unit MDF The level of the organizational hierar-

chy lower than the Legal Entity. It is
the Business area of the company, rep-
resenting one operating unit or repre-
senting the business function within the
Company (not geographical)

Cost Center MDF The cost center foundation object

stores all the cost centers of a com-
pany. Cost Centers are usually defined
in the ERP financial systems, and you
simply load cost center info from those
systems.

Implementing Employee Central Core

64 PUBLIC Configuring the System
Object Object Type Description

Division MDF The level of the organizational hierarch-

ical structure lower than the Business
Unit.

Department MDF It is usually necessary to divide a busi-

ness into a number of departments,
such as Sales and Marketing, Public Re-
lations, and Dispatch. This Foundation
Object enables you to do this.

GeoZone Legacy You can group locations into one geo-

zone. For example, you could create
the GeoZoneEurope West, containing
the locations UK, Netherlands, and Ger-
many.

This foundation object includes an Ad-

justment Factor field that where you en-
ter a percentage to indicate the adjust-
ment to the pay range for this GeoZone
due, for example, to differences in the
cost of living.

For example, if you decide that people

on the west coast of the US should
be paid 10% more than those on the
east coast and that the pay range for
people on the east coast is $100,000 -
$110,000, the pay range for people on
the west coast is $110,000 - $121,000.

Location Legacy The location Foundation Object stores

address information for all the physical
offices of a company. It supports inter-
national address formats.

 Note
For customers using the Team
Summary tile on the Home Page,
the business address must also be
configured so that an accurate lo-
cation can be displayed.

Implementing Employee Central Core

Configuring the System PUBLIC 65
Object Object Type Description

Location Group Legacy It is possible to combine locations into

location groups under the Location
Group Foundation Object. For example,
you might want to group all your offices
on the east coast of the United States
in a location group labeled “US East
Coast”. By default, the Location Group
object does not display on the employ-
ee’s job information record, but is used
strictly for reporting purposes.

 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 236] topics.

2.2.5.10 Foundation Objects for Handling Job-Related Areas

Some of the foundation objects (FO) can be used to handle job-related issues. This information states what
they do in the organization.

Job-Related Objects A-Z

Object Object Type Description

Job Classification MDF The Job Classification object stores all

job codes defined in a company and in-
formation associated with the job code.
Companies can have one universal job
classification, used for more than one
country.

Job Function MDF Several Job Classifications can have

the same Job Function. For example,
the Job Classifications "Developer" and
“Development Manager” could be asso-
ciated to the same Job Function “Engi-
neering”. By default, the Job Function
does not display on the employee’s Job
Information record, but is used strictly
for reporting purposes.

Implementing Employee Central Core

66 PUBLIC Configuring the System
Implementing Employee Central Core
Configuring the System PUBLIC 67
2.2.5.11 Foundation Objects for Handling Pay-Related Areas

Some of the foundation objects (FO) can be used to handle pay-related issues. This information states what
and how they are paid.

Pay-Related Objects A-Z

Object Object Type Description

Pay Component Legacy An employee’s pay is comprised of

more than one component, such as Ba-
sic salary, Target bonus, Company car
allowance, and so on.

For each pay component, a company

needs to define attributes such as:

• Is the pay component recurring or

one-time?
• If the pay component is recur-
ring, what is the frequency?
This can be set directly on the
pay component and propa-
gated to the employee’s re-
cord when the pay component
is selected, or it can be de-
rived from other attributes,
such as the Pay Group.
• Is the pay component an amount
or a percentage?
• If percentage, what is the per-
centage based on? For exam-
ple, is it based on how much of
a particular product the em-
ployee makes or sells?
• Is the pay component actual pay or
a target amount?
• Who has the ability to select or
view the pay component? This can
be controlled using RBP.
• Should the pay component be
used by the Compensation mod-
ule?
• Is the pay component taxable or
non-taxable?

Implementing Employee Central Core

68 PUBLIC Configuring the System
Object Object Type Description

Frequency Legacy Frequency is used by the PayCompo-

nent Foundation Object to determine
how often a pay component is paid - for
example, annually.

Pay Component Group Legacy It is possible to group pay compo-

nents into pay component groups. The
amount of a pay component group is
equal to the sum of the pay compo-
nents it includes. If the amounts in
question are in different currencies or
for periods of less than a year, the sys-
tem automatically annualizes them and
converts the currencies.

Pay Grade Legacy Pay Grade is a Foundation Object re-

lated to Job Classification. A Job Clas-
sification is connected by default to a
Pay Grade. This is optional and you can
turn it off in the Corporate Data Model
using the Grade field on the 'jobCode'
element. To do this, simply set the visi-
bility to “none”.

It can be used to identify when a trans-

action is lateral move, a promotion, or a
demotion.

Pay Range Legacy Pay Range is primarily used for the

calculation of Compa Ratio and Range
Penetration. The system stores mini-
mum, median, and maximum points of
a pay range.

Your company can define as many pay

ranges as required. The range generally
includes Pay Grade, Geozone, and Legal
Entity and are updated every year.

Pay Group MDF We recommend that you group people

who share the same payroll-related at-
tributes into one pay group. For exam-
ple, employees in Europe who are all
paid by SAP Payroll and paid bi-weekly
can be grouped into one European Pay
Group.

Implementing Employee Central Core

Configuring the System PUBLIC 69
Object Object Type Description

Pay Calendar MDF The PayCalendar Foundation Object

stores all the payroll periods within a
year. For example, June 1 – June 15
2016 could be one payroll period.

For more information, see the Implementing and Configuring Employee Payments in Employee Central guide
on the SAP Help Portal.

2.2.5.12 Other Foundation Objects

There are additional foundation objects that you can use.

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):

Object Object Type Description

Event Reason Legacy Employee Central uses event reasons

to determine which HR event has taken
place when employee data is changed
and why. For example, the event “Termi-
nation” can take place either because
the employee´s performance was not
satisfactory, or because the employee
wanted to change company. In this
case, two event reasons can be created:
“Involuntary Termination -Performance
Issues”, or “Voluntary Termination – By
Employee”. You can create as many
event reasons for an event as needed.
These event reasons can then be used
for reporting and analytics.

Workflow Legacy The Workflow FO allows for the ability to

create and edit workflow details, includ-
ing approver steps, Contributors, and
CC roles.

Implementing Employee Central Core

70 PUBLIC Configuring the System
Object Object Type Description

Dynamic Role Legacy A Dynamic Role is one of the approver

types available in setting up of appro-
val workflows for changes to employee
data. This allows the system to find the
approver dynamically based on the em-
ployee’s FO attributes.

2.2.6 MDF Foundation Objects

As part of the phased migration of Foundation Objects (FO) to the Metadata Framework (MDF), the following
Foundation Objects are now MDF Foundation Objects (also referred to as GOs). Any organizational information
configured using these FOs will now be configured using the corresponding MDF FO.

This Foundation Object... Was migrated in this release...

Cost Center Q4 2014 Release

Department Q2 2015 Release

Division Q2 2015 Release

Business Unit Q2 2015 Release

Legal Entity Q2 2015 Release

Legal Entity Local Q2 2015 Release

Job Function Q4 2015 Release

Pay Group Q4 2015 Release

Pay Calendar Q4 2015 Release

Job Family (Deprecated) Q4 2015 Release

Job Classification Q4 2015 Release

Job Classification Local Q4 2015 Release

As part of the migration:

• The object definitions for these FOs have also been migrated from the Corporate Data Model to MDF. As a
result, the migrated Foundation Objects will no longer be configured in the Corporate Data Model. Instead,
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.

Implementing Employee Central Core

Configuring the System PUBLIC 71
• All instances of these objects and related data such as associations, translations, and audit data have been
migrated to the respective entities in MDF.
• Picklists referenced by the fields on these objects are migrated to MDF picklists and kept in sync with the
ECV2 picklist. Cascading picklists have also been migrated.
• Rules with references to the following FOs have been migrated to rules referencing their corresponding
GOs: costCenter, businessUnit, division, department, company, jobCode, jobFunction, jobFamily,
payGroup, and payCalendar. For example, a rule referring to the FO costCenter now refers to the GO
CostCenter.
• Open workflows for the migrated FOs, mentioned above, have been migrated to MDF-based workflows for
further processing.
• Permissions for the new migrated FOs have been migrated to the permission category for migrated
Foundation Objects and stored as MDF permissions.
• Existing ad-hoc reports now work based on the migrated Foundation Objects. For Advanced Reporting
(ODS), the reports will be migrated when first invoked after migration.
• If the FO jobFamily was previously configured in the Corporate Data Model, it has been migrated to the
custom object type cust_JobFamily1511 to enable you to continue using the FO Job Family after migration.
If you have not been using it, it will not be available. Note that there is no pre-delivered GO for Job Family
since it has been deprecated.

Related Information

Implementing the Metadata Framework (MDF)

2.2.6.1 Adding Search Criteria

You can add terms at the object under which they can be found in the search.

Procedure

1. Go to Admin Center Configure Object Definitions .

2. In the search field, select Object Definition and then select the object for which the criteria is to be
defined. For this example, let's select Business Unit. The Object Definitions page now displays the current
configuration for the GO BusinessUnit.

3. Select Take Action Make Correction .

4. Scroll down to the Searchable Fields section.

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.

Implementing Employee Central Core

72 PUBLIC Configuring the System
  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.

5. Save your changes.

2.2.6.2 Working with Associations, Field Criteria and Value

Help

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.

Association before Association after

Migration Is defined in migration Is defined in Details

mFO – cGO Corporate Data Model mGO – cGO Metadata Framework

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

Implementing Employee Central Core

Configuring the System PUBLIC 73
Association before Association after
Migration Is defined in migration Is defined in Details

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>

Implementing Employee Central Core

74 PUBLIC Configuring the System
  Example

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.

Implementing Employee Central Core

Configuring the System PUBLIC 75
  Example

On Job Information, the cost center field is filtered by business unit and a custom field custom-string2
referring to GO cust_GCC:

<hris-field max-length="256" id="cost-center" visibility="both">

<label>Cost Center Account</label>
<label xml:lang="de-DE">Kostenstellenkonto</label>
<field-criteria
sourceFieldName="cust_toBusinessUnit.internalId"
destinationFieldValue="business-unit" />
<field-criteria
sourceFieldName="cust_tocust_GCC.mdfSystemInternalCode"
destinationFieldValue="custom-
string2" />
</hris-field>

 Example

On Job Information, location field is filtered by cost center field:

<hris-field max-length="128" id="location" visibility="both">

<label>Location</label>
<field-criteria sourceFieldName="CostCenter" destinationFieldValue="cost-
center"/>
</hris-field>

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.

A few scenarios are explained below.

 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" >

Implementing Employee Central Core

76 PUBLIC Configuring the System
  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:

The field criteria defined on the business-unit field looks as follows:

<field-criteria sourceFieldName="cust_toFOWLocation.internalId"
destinationFieldValue="location" >

Creating Associations Between Different Blocks

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

Associations [page 35]

Implementing Employee Central Core

Configuring the System PUBLIC 77
Adding Field Criteria to a HRIS Element

2.2.6.2.1 Adding Legal Entity to the Cost Center Object

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

1. Go to Admin Center Manage Data .

2. Select the cost center object to have the association.
3. Select Insert New Record and then enter a date for the change to be effective in the system.
4. Add the legal entity and save your changes.

This creates the association between the specific cost center and the specific legal entity.

5. Go to Admin Center Manage Business Configuration .

6. Select Employee Central jobInfo .

7. For the <cost center> field, select the Details link.
8. In the Field Criteria section, add the required information:

• Destination Field Value: company

• Source Field Name: legalEntity
9. Save your changes.

Implementing Employee Central Core

78 PUBLIC Configuring the System
Results

In the Job Information block 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.

Next Steps

You can repeat these steps for the Position object as well.

2.2.6.3 Behavior Changes to Importing Foundation Objects

There are a few areas where imports to now MDF foundation objects differ to legacy foundation objects.

You can import updates for all the migrated FOs such as Cost Center, Business Unit, Division, Department,
Legal Entity, and Legal Entity Local.

For example, cost center import updates the GO CostCenter instead of FO costCenter. The Import and Export
Data page continues to be the entry point for cost center imports.

Scheduled Jobs will run as before, without any change. There are a few areas with change in behavior, but for
critical areas, backward compatibility is kept.

You will notice a change in behavior in the following areas:

• You can use the standard MDF imports page as an alternate entry page to import the migrated FOs. In this
case, you need to use the MDF import template for all the objects, which has a different structure than that
of the standard import.
• Import template is enhanced to support translations. You are not required to import translations through a
separate MDF import to the GO FOTranslations.
• MDF import does not support localized format for numbers. Use the format specified in the UI or use the
ECv2 Import template.
• Translations for fields on all migrated FOs are not imported to the MDF object FO Translations.
• Threshold field is not honored in case of import of all the GOs. MDF imports always run asynchronously.
• Synchronous mode validation and import are not supported for the GOs.
• End Date is not exposed in the enhanced template.
• When future-dated associated values are entered in the import file, no error message appears. Instead, it
shows blank value.
• Quick validations in MDF are not supported.
• Full purge is recommended over Incremental Load. See the examples below:
• On the Monitor Jobs page, the Job Type column displays content related to MDF now:
• Error messages are displayed with the new field IDs, for example, effectiveStartDate instead of start-date.

Implementing Employee Central Core

Configuring the System PUBLIC 79
  Example

Delimit Cost Center by inserting new associations:

Let's say Location was associated to the Cost Center in the Corporate Data Model as a One-to-Many
relationship, and we import Cost Center value CC1 in Incremental Mode, with associated locations as Loc1,
Loc2, and Loc3 on January 15, 2001.

If we import new record for CC1 with no location values for January 1, 2014, original associations with
location, that is Loc1, Loc2 and Loc3, will be retained.

This is different from the ECV2 foundation data import, where the import delimits CC1 with no associated
locations.

 Example

Delimit Cost Center by removing existing associations:

Suppose Cost Center has a Valid When association with a customer GO cust_GO with values GO1 and GO2.
We import a Cost Center record CC1 with association GO1 on January 1, 2014 and another import with
association GO2 on January 2, 2014, through incremental load.

On January 2, 2014, Cost Center record has both GO1 and GO2 associations. Here GO1 is carried forward to
the next record, which was not the case in ECV2 foundation data imports.

 Example

Delimit Legal Entity by removing existing associations:

Suppose Legal Entity has a Valid When association with a customer GO cust_GO with values GO1 and
GO2. We import a Legal Entity record LE1 with association GO1 on January 1, 2014 and another import with
association GO2 on January 2, 2014, through incremental load.

On January 2, 2014, Legal Entity record has both GO1 and GO2 associations. Here GO1 is carried forward to
the next record, which was not the case in ECV2 foundation data imports.

 Recommendation

If you want to enhance, for example, the CostCenter object definition in MDF, use the MDF Import for
cost center. For more information about MDF imports, refer to the Implementing the Metadata Framework
(MDF) guide on the SAP Help Portal.

2.2.6.4 Behavior Changes to Workflows

Prior to the November 2014 release, you could create multiple workflows on the same cost center instance.

With the November 2014 release, if a workflow has already been initiated on the cost center, no other
transaction can be performed for that cost center. The same applies for the following MDF Objects with effect
from the Q2 2015 release: Business Unit, Division, Department, and Legal Entity.
For more information on changes as a result of the migration to MDF, see the Migrating to MDF Foundation
Objects guide on the SAP Help Portal.

Implementing Employee Central Core

80 PUBLIC Configuring the System
2.2.6.5 Optional: Editing the Country/Region and Currency
Objects

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).

Instead of deleting countries/regions and currencies, we suggest setting them to Inactive.

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

1. Go to Admin Center Manage Data .

2. In the Search field, select Country/Region.
3. In the field next to it, select the country/region for which you would like to view information.
4. To view the translated country/region name, select the View Translations icon next to the country name.
5. To view the currency associated with a country/region, select the View Currency icon next to currency
name.

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.

Implementing Employee Central Core

Configuring the System PUBLIC 81
2.2.6.6 Adding a New Country/Region and Related Fields
to LegalEntity

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.

2.2.6.6.1 Step 1: Creating a New MDF Object for the

Country/Region-Specific Fields

Create a new MDF object for the country/region-specific fields needed for your company.

Procedure

1. Go to Admin Center Configure Object Definitions .

2. From the Create New drop-down, select Object Definition.
3. In the Code field, specify a code for the new object. It is a good idea to follow the following naming
convention: cust_LegalEntity<Country Code>.
4. In the Effective Dating drop-down, select From Parent.
5. In the Label field, provide a unique identifier.
6. Set API Visibility as required.
7. In the Fields section, select Details against externalCode.
8. Change the externalCode data type to Auto Number and set its Visibility to Not Visible.

9. Select Done to go back to the previous page.

10. Now, specify settings for the externalName field. Select Details next to externalName.
11. Set the externalName field visibility to Not Visible.

12. Define the custom-specific fields.

13. Save your changes.

Results

This will add a number of predefined MDF fields.

Implementing Employee Central Core

82 PUBLIC Configuring the System
2.2.6.6.2 Step 2: Assigning the New Object to Legal Entity

Assign the new country object to Legal Entity to associate the two objects in the system.

Procedure

1. Go to Admin Center Configure Object Definitions .

2. From the Search drop-down, select Object Definition.
3. Select LegalEntity from the field next to it.

4. Select Take Action Make Correction .

5. Scroll down to the associations section and add a new association. We suggest following this naming
convention: cust_toLegalEntity<CountryCode>.

1. Multiplicity: One to One

2. Destination Object: your newly created object
3. Type: Composite
4. Details:
1. Condition fieldID: countryOfRegistration.code
2. Condition Values: <Country Code>
6. Save your changes.

2.2.6.7 Adding a New Country/Region and Related Fields

to Job Classification

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.

2.2.6.7.1 Step 1: Creating a New MDF Object for the

Country/Region-Specific Fields

Create a new MDF object for the country/region-specific fields needed for your company.

Procedure

1. Go to Admin Center Configure Object Definitions .

Implementing Employee Central Core

Configuring the System PUBLIC 83
2. From the Create New drop-down, select Object Definition.
3. In the Code field, specify a code for the new object. It is recommended that you follow this naming
convention: cust_JobClassification<Country Code>.
4. From the Effective Dating drop -down, select From Parent.
5. In the Label field, specify a unique name.
6. SetAPI Visibility to Editable.
7. In the Fields section, select Details for the externalCode.
8. Change the externalCode data type to Number and set its Visibility to Not Visible.
9. Set Default Value to 1.
10. Select Done to go back to the previous page.
11. We will now specify settings for the externalName field. Select Details for externalName.
12. Set the externalName field visibility to Not Visible.
13. Define the custom fields.
14. Add a label to display on the UI.
15. Save your changes.

Results

This will add a number of pre-defined MDF fields.

2.2.6.7.2 Step 2: Assigning the New Object to

JobClassificationCountry

Assign the new country/region object to JobClassificationCountry to associate the two objects in the system.

Procedure

1. Go to Admin Center Configure Object Definitions .

2. From the Search drop-down, select Object Definition.
3. Select JobClassificationCountry from the field next to it.

4. Select Take Action Make Correction .

5. Scroll down to the associations section and add a new association. We suggest following this naming
convention: cust_toJobClassification<CountryCode>.

1. Multiplicity: One to One

2. Destination Object: your newly created object
3. Type: Composite

Implementing Employee Central Core

84 PUBLIC Configuring the System
 4. Details:
1. Condition fieldID: country.code
2. Condition Values: <Country Code>
6. Save your changes.

2.2.6.8 Configuring Standard Fields

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

1. Go to Admin Center Configure Object Definitions .

2. In the Search field, select Object Definition and then select Cost Center.

The Configure Object Definitions page now displays the current configuration for the GO CostCenter.

3. Select Take Action Make Correction .

4. In the Fields section, scroll down to glStatementCode and select Details.
5. Set the Visibility of this field to Not Visible.

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.

The Details page comes up.

8. In the Name field, specify a name for the picklist. Note that the name is automatically prefixed with cust_
when you move to the next field.
9. From the Data Type drop-down, select Picklist.
10. In the Valid Values Source field, specify the ID of the MDF picklist.
11. Fill out the rest of the fields in the form and select Done to save your changes.

2.2.7 Generic Objects

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.

What is the difference between Foundation Objects and Generic Objects?

Implementing Employee Central Core

Configuring the System PUBLIC 85
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

Implementing the Metadata Framework

2.2.7.1 Standard Generic Objects

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

2.2.7.2 Characteristics of Generic Objects

Here's a summary of the features available in generic objects.

Features

Here's a survey of the characteristics of generic objects.

• Each object has a technical ID, which you cannot change.

There are different types of technical ID. Here are some examples:
• Tab element ID: If you include a generic object with a tab element ID in your Succession Data Model,
the relevant tab is available for use in your installation. You need to configure permissions for them
though (see below).

Implementing Employee Central Core

86 PUBLIC Configuring the System
 • Field ID: If you include a generic object with a field ID, that field is available for use in your installation.
Again, you need to give each user the permissions they need to use the field.
Each object has a label, which you can change to suit your requirements. It is possible to have this label in
different languages if you need to.
• You have to enable generic objects in your system before you can use or see them. You do this by checking
the Enable Generic Objects feature 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.

• 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.

2.2.7.3 Creating Customer-Specific Foundation Objects

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

1. Create the generic object in the system.

 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

Implementing Employee Central Core

Configuring the System PUBLIC 87
 1. Download the Succession Data Model or Corporate Data Model from Provisioning and open it in an
XML editor.

 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.

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.

1. Save your changes and upload the data model in Provisioning.

b. If assigning the Generic Object to an MDF Foundation Object or other Generic Object
1. Go to the Configure Object Definition page and search for the destination object.
2. Make a correction, and add a new custom field. In the Details link, at a minimum, fill out the
following fields:
• Data Type = Generic Object
• Valid Values Source = the ID of the Generic Object
c. If assigning the Generic Object to the Succession Data Model
1. Go to Manage Business Configuration, and select the relevant HRIS Element.
2. Create a new custom string field and fill out the required information.
3. Open the Details of the field, and update the following fields:
4. • Type of Reference Object = Foundation Object
• Reference Object = the ID of the Generic Object
• Visibility = View or Edit
3. Save your changes.
4. Assign role-based permissions for the custom field you’ve added.

Related Information

Implementing the Metadata Framework

Implementing Employee Central Core

88 PUBLIC Configuring the System
2.2.7.4 Example: Configuring Workflows for Legacy
Foundation Objects

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.

1. Create a workflow for Location.

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.

For more information on how to configure rules, see the Implementing Business Rules in SAP
SuccessFactors guide on the SAP Help Portal.

Implementing Employee Central Core

Configuring the System PUBLIC 89
3. Add the rule as an onSave event to the foundation object in the Corporate Data Model.

2.2.7.5 Example: Automatic Generation of Legacy

Foundation Object Codes

It is possible for the system to generate foundation object codes by defining a sequence and then using this
sequence in a business rule.

1. Navigate to the Admin Center Manage Data .

2. In the Create New drop-down, select Sequence.
Please ensure the sequence does not begin at 0 or with a negative value.
3. Create a business rule to set all position codes in the format: LOC_seqCurrentNumber.
Make sure to use the corresponding Foundation Object as the base object.

4. Add the rule as an onInit event to the foundation object in the Corporate Data Model.

 Note

The rule trigger needs to be set on the foundation object element, after the labels, but before the field
configuration.

5. Save your changes.

Implementing Employee Central Core

90 PUBLIC Configuring the System
2.2.8 Configuring Company System Settings

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

1. Go to Admin Center Company System and Logo Settings .

2. In the Company System Setting section, select what is required for the company. Go through the list
carefully. Many settings enable validations or affect search results.

We recommend that at least the following validations be selected:

• 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.

2.2.9 Configuring Employee Central Settings

Enable areas within Employee Central from this page.

Prerequisites

You must have the required permissions to view the page: Permission Settings Manage System Properties
Employee Central Feature Settings

Implementing Employee Central Core

Configuring the System PUBLIC 91
Context

Manage the areas of Employee Central using the Admin Center, for example:

• Time and Attendance Management

• Person, Employment and Worker Type
• Position Management
• Deductions Management
• Advances
• Fiscal Year
• IT Declarations
• Cost Distribution

Procedure

1. Go to Admin Center Manage Employee Central Settings .

 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.

2. Enable your changes.

3. Save your changes.

2.2.10 Enabling the Employee Central SOAP APIs

Turn on the API setting so that you can use Employee Central SOAP APIs to integrate data.

Context

 Note

Employee Central SOAP APIs will be deprecated. We recommend that you use OData APIs instead. For
more information, refer to Deprecation of Partner API, SFAPI Adhoc, and SFAPI for Simple Entities in the
Related Information section.

Implementing Employee Central Core

92 PUBLIC Configuring the System
Procedure

1. Go to Provisioning Company Settings .

 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.

2. Under Web Services, select the Employee Central SOAP API setting.
3. Save your changes.

Results

With this option turned on, you can use Employee Central SOAP APIs.

Related Information

Deprecation of Partner API, SFAPI Adhoc, and SFAPI for Simple Entities

2.2.11 Configuring the Internal Job History Block

Configure the Internal Job History block 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 for People Profile from Administrator Permissions Manage System
Properties Manage Employee Files
• Create a rule using the Internal Job History Block rule scenario. You do this by going to Admin Center
Configure Business Rules Employee Central Core 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.

Implementing Employee Central Core

Configuring the System PUBLIC 93
 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 block 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 block, which is really a filtered version of the job history for an employee.

Procedure

1. Navigate to the Admin Center Configure People Profile .

2. Select Custom Blocks Internal Job History .

3. Drag and drop the block to where it should show in the profile.

This is a double block, meaning it needs 2 block spaces. The system does not allow you to place it in a
single block.
4. Select the block to edit it's properties.
5. Edit the block.
a. Enter the block title and block description.
b. Optional: Select the option Show the description below the block title.

If you don't select the option, users access the description through the  Help in the block.
c. Select the Job Information fields from the dropdown that you would like to have in the block.

 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.

Implementing Employee Central Core

94 PUBLIC Configuring the System
  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 block.

d. Select the rule you created using the Internal Job History rule scenario from the Rules dropdown.

 Note

Only the Internal Job History rule scenario rules are shown. If no rule is configured, then the Rule
dropdown will not be seen.

6. Save your changes.

Results

To view the Internal Job History Block, navigate to Employee Profile for the employee whose history you would
like to see. The new block appears on the Employee 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

Rule Scenarios for Employee Central Core [page 140]

2.2.12 Setting Up the Currency Exchange Rate

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

1. Ensure the correct permissions are granted.

Implementing Employee Central Core

Configuring the System PUBLIC 95
 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.

2. Check the CurrencyExchangeRateType picklist.

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.

a. Go to Admin Center Configure Object Definitions .

b. Select Create New Picklist .
c. Enter at least the following:
• Code: CurrencyExchangeRateType
• Effective Start Date: 01/01/1900
• External Code: DEFAULT
DEFAULT must be in capital letters.
d. Save your changes.
3. Check the currency exchange rates.

a. Go to Admin Center Manage Data .

b. In the Search field, select Currency Exchange Rate.
c. Update the default records for the currency exchange rates.

 Caution

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.

2.2.13 User ID Generation

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:

Implementing Employee Central Core

96 PUBLIC Configuring the System
• Hires are processed by concurrent API calls
• Inactive number ranges
• During peak times when a high volume of hires are processed by multiple users at the same time In certain
cases, gaps in the row of assigned IDs cannot be avoided, such as aborted hire processes. For example, if 2
hires are canceled, employees 1020 – 1040 exist, 1041 – 1042 are skipped, and employee IDs continue with
1043.

Assigning the Next ID

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 Person 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.

Changing the Sequence Number

The Maximum Number Already Used as Employee ID for Existing Employees field contains the last number
already used for employees in the system. To start the next employee ID from this number, please enter this
number in Next Person ID Assigned.

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 Person ID Assigned and save the
changes.

To start the sequence with different number, update the number in the field Next Person ID Assigned and save
the changes.

Related Information

Generating User IDs with Business Rules

Different IDs in SAP SuccessFactors HXM Suite

Implementing Employee Central Core

Configuring the System PUBLIC 97
2.2.13.1 Optional: Creating Number Ranges for User ID
Sequences

You can create multiple sequence ranges for customers who want to place certain types of employees in those
ranges.

Procedure

1. Go to Admin Center Manage Data .

2. In Create New Sequence , create a new sequence.

3. Enter the required information:
• External code
• External name
• Start
• Step

For a range that starts at 3000,fill in the fields as such:

• External code: SetPositionExternalCode

• External name: SetPositionExternalCode
• Start: 3000
• Step: 1
4. Save your changes.

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

Generating User IDs with Business Rules

Different IDs in SAP SuccessFactors HXM Suite

Implementing Employee Central Core

98 PUBLIC Configuring the System
3 Managing Role-Based Permissions

3.1 Permissions for Employee Central

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 blocks 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

List of Role-Based Permissions

3.1.1 User Permissions for Employee Central

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 blocks 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.
Here is a list of the user permission categories.

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 99
Permission Category Sections Relevant for Employee Central

Employee Data • HR Information

• Employment Details
• Global Assignment Details
Only available if you have activated global assignments
in the Admin Centerr.
• Pension Payout Details
Only available if you have activated pension payouts in
the Admin Center.
• HR Actions
• Future Dated Transaction Alert
• Transactions Pending Approval
• View Workflow Approval History
• Pay Component Groups
• Pay Components

Employee Central Effective Dated Entities Set field-level permissions for effective-dated blocks and
fields. These blocks 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

List of Role-Based Permissions

3.1.1.1 Employee Data - HR Information

Assign permissions for blocks 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 blocks that have been defined as HRIS elements in the Succession
Data Model.

These settings are available for each entry listed:

Implementing Employee Central Core

100 PUBLIC Managing Role-Based Permissions
• View: The user can see the block.

 Tip

If necessary, you can use OnView rules to control who can see which fields in the blocks listed here,
since you cannot use role-based permissions to set field-level View permissions for these blocks. For
more information about how to create such rules, refer to the Example Employee Central Business
Rules [page 175].

• Edit: The user can edit the block on the Personal Information or Employment Information page by selecting
the Edit link in the block.

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:

HR Information Permission Setting HRIS Element Description

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 coun-
tries or regions for the employee.

For an employee with multiple assign-

ments or employments in different
countries or regions, if the responsible
administrators with this permission can
access an assignment, they only view
and edit the national ID information rel-
evant to the assignment.

Note that selecting only View has the

same impact as selecting both View
and Edit, that is, administrators can
both view and edit the relevant national
ID information.

User Permissions Employee Data Phone Information (phoneInfo) Admins with this permission can access
HR Information personal data of a user.

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 101
HR Information Permission Setting HRIS Element Description

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
HR Information to one of the email types of the
emailInfo element: business email
address.

It is listed here because normally every

employee needs a business email ad-
dress. If a company assigns the email
addresses to the employees and does
not want them to be editable by the
employees, select only View permission
here.

 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 block on the Employment
Information page.

The Edit permissions allows users to

navigate from the Employment Infor-
mation page to the Update Employee
Records page using the Take Action
menu.

 Note
Admins can also assign approval
workflows for changes done on the
Update Employee Records page.

Implementing Employee Central Core

102 PUBLIC Managing Role-Based Permissions
HR Information Permission Setting HRIS Element Description

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.

Admins with the Edit permission can

manage global assignments on the
Update Employee Records page using
the Take Action menu.

 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 pen-
HR Information (pensionPayoutsInfo) sion payouts are active in the system.

The Edit permissions allows the user to

manage pension payouts on the Update
Employee Records page using the Take
Action menu.

 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
employees, select only View permission
here.

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 103
HR Information Permission Setting HRIS Element Description

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 block.

If a user doesn't have permission to see

pay targets, then the entire Pay Targets
section of the Compensation block is
hidden.

Related Information

List of Role-Based Permissions

3.1.1.2 Employee Data - Global Assignment Details

Assign permissions for actions and fields in the Global Assignment Details block.

These permissions are found in User Permissions Employee Data Global Assignment Details

For each action or field listed, choose View or Edit.

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 block View allows the user to view the Global Assignment Details
block on the Employment Information page.

Only View is applicable here; Edit has no function.

Global Assignment Edit Link Edit allows the user to make changes to the Global
Assignment Details block directly on the Employment
Information page.

This requires the user to also have the Global Assignment

View block permission.

 Note
Approval workflows cannot be added to changes done
using the Edit link.

Implementing Employee Central Core

104 PUBLIC Managing Role-Based Permissions
For this Global Assignment Details entry... ...select which permission is needed:

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
navigating 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.

Company 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

List of Role-Based Permissions

3.1.1.3 Employee Data - Employment Details

Assign permissions for the Employment Details block.

These permissions are found in User Permissions Employee Data Employment Details

For each action or field listed, choose View or Edit.

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.

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 105
For this Employment Details entry... ...select this permission:

Employment Details MSS View to allow the user to view the Employment Details block.

Edit to allow the user to navigate from the Employment Infor-

mation 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.

Employment Details Edit Edit allows the user to edit the Employment Details on the
profile by selecting Edit button.

Note that workflows cannot be assigned for changes done

this way.

Add New Employment Edit allows the user to add multiple employments for one
employee.

Please note that Concurrent Employment Management

needs to be enabled in the Admin Center to use this func-
tion.

Bonus Pay Expiration Date Hide this field from the user interface by deselecting View
and Edit.

This field belongs to the Termination Information block.

However, the permissions are included here because it re-
quires field permission rather than permission for the whole
block.

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.

OK to Rehire 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.

Implementing Employee Central Core

106 PUBLIC Managing Role-Based Permissions
For this Employment Details entry... ...select this permission:

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.

Attachment Edit allows the admin or manager to update this field.

New Main Employment Edit allows the admin or manager to update this field.

Related Information

List of Role-Based Permissions

3.1.1.4 Employee Data - HR Actions

Assign permissions for the Change Job and Compensation Info page.

These permissions are found in User Permissions Employee Data HR Actions

The HR Actions section controls mainly who has access to the Update Employee Records page for actions
defined in the Succession Data Model.

This HR Action... ...defines this permission:

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.

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 107
This HR Action... ...defines this permission:

View Higher Grades This option defines whether a manager can view an employ-
ee's job classification and pay grade if it is higher than the
manager's. This option is valid for Manager Self-Service sce-
narios, but it not valid in the History.

To restrict a manager’s view, leave the permissions un-

checked. Make sure that the job classifications are assigned
to a pay grade, and have a paygradeLevel assigned.

When the manager goes to the Update Employee Records

page for Job Information, the list of job classifications in the
dropdown is limited to those whose paygradeLevel is
less than or equal to the manager’s.

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
defines if the user can access the Add New Employee link in
the Admin Center.

Rehire This is an hris-action from the Succession Data Model. It

defines if the user can access the Rehire Inactive Employee
link in the Admin Center.

Terminate This is an hris-action from the Succession Data Model. It

defines if the user can access the Take Action button on the
Employment Information page and select Terminate from the
dropdown menu.

This option defines whether the admin has permission to

terminate every single concurrent employment. If yes, the
Terminate All option will be visible in the Terminate/Retire
screen.

Manage Leave of Absence This option allows admins or managers the Take Action but-
ton for legacy LOA.

Return from Leave of Absence This option allows admins or managers the Take Action but-
ton for legacy LOA.

 Note

Permissions to access the Update Employee Records page for Global Assignments are set in User
Permissions Employee Data HR Information .

Implementing Employee Central Core

108 PUBLIC Managing Role-Based Permissions
Related Information

List of Role-Based Permissions

3.1.1.5 Employee Data - Future-Dated Transaction Alerts

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.

Future-dated transaction alerts can be set for the these blocks:

Block HRIS Element Description

Personal Information personalInfo Only the View permission is applicable

here. The Edit permission has no func-
tion.

Addresses Only the View permission is applicable

homeAddress
here. The Edit permission has no func-
tion.

Dependents personRelationshipInfo Only the View permission is applicable

here. The Edit permission has no func-
This entry is only relevant if you have
tion.
activated the Dependents Management
feature in the Admin Center.

Job Information jobInfo Only the View permission is applicable

here. The Edit permission has no func-
tion.

Compensation Information compInfo, Only the View permission is required.

payComponentNonRecurring The Edit permission has no function.

 Note
Unlike effective-dated entities such
as Compensation Information, if
the pay date (issue date) of
the non-recurring pay component
(non-effective dated entity) is in the
future, the record is shown on the
UI only if the View permission is
granted.

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 109
Block HRIS Element Description

Job Relationships jobRelationsInfo Only the View permission is applicable

here. The Edit permission has no func-
tion.

Related Information

Enabling Dependent Management

List of Role-Based Permissions

3.1.1.6 Employee Data - Transactions Pending Approval

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

You can set the permission for the following blocks:

Block HRIS Element Description

Personal Information personalInfo View means the pending approval link is

shown, but you cannot select it to get to
the details of the workflow request.

Edit means you can view and select the

pending approval link.

National ID nationalIdCard View means the pending approval link is

shown, but you cannot select it to get to
the details of the workflow request.

Edit means you can view and select the

pending approval link.

Home Address homeAddress View means the pending approval link is

shown, but you cannot select it to get to
the details of the workflow request.

Edit means you can view and select the

pending approval link.

Implementing Employee Central Core

110 PUBLIC Managing Role-Based Permissions
Block HRIS Element Description

Dependents personRelationshipInfo View means the pending approval link is

shown, but you cannot select it to get to
the details of the workflow request.

Edit means you can view and select the

pending approval link.

Employment Details employmentInfo View means the pending approval link is

shown, but you cannot select it to get to
the details of the workflow request.

Edit means you can view and select the

pending approval link.

Job Information jobInfo View means the pending approval link is

shown, but you cannot select it to get to
the details of the workflow request.

Edit means you can view and select the

pending approval link.

Compensation Information compInfo View means the pending approval link is

shown, but you cannot select it to get to
the details of the workflow request.

Edit means you can view and select the

pending approval link.

Spot Bonus payComponentNonRecurring View means the pending approval link is

shown, but you cannot select it to get to
the details of the workflow request.

Edit means you can view and select the

pending approval link.

Job Relationships jobRelationsInfo View means the pending approval link is

shown, but you cannot select it to get to
the details of the workflow request.

Edit means you can view and select the

pending approval link.

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.

Edit means you can view and select the

pending approval link.

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 111
Related Information

List of Role-Based Permissions

3.1.1.7 Employee Data - View Workflow Approval History

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

Block HRIS Element

Personal Information personalInfo Only the View permission is relevant,

Edit has no function.

The user with View permission can se-

lect View Approval History in the History
page.

Home Address Only the View permission is relevant,

homeAddress
Edit has no function.

The user with View permission can se-

lect View Approval History in the History
page.

Job Information jobInfo Only the View permission is relevant,

Edit has no function.

The user with View permission can se-

lect View Approval History in the History
page.

Compensation Information compInfo Only the View permission is relevant,

Edit has no function.

The user with View permission can se-

lect View Approval History in the History
page.

Job Relationships jobRelationsInfo Only the View permission is relevant,

Edit has no function.

The user with View permission can se-

lect View Approval History in the History
page.

Implementing Employee Central Core

112 PUBLIC Managing Role-Based Permissions
Related Information

List of Role-Based Permissions

3.1.1.8 Employee Data - Event Reasons

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 .

Here are a few examples of why distribution is important:

• 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

List of Role-Based Permissions

3.1.1.9 Employee Central Effective-Dated Entities

Set permissions for effective-dated blocks and fields.

These permissions are found in User Permissions Employee Central Effective Dated Entities .

These permissions 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).

There are five different permissions you can select for effective-dated entities:

• 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.

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 113
• Correct: The user can make corrections on the History page.
• Delete: The user can delete an effective-dated entity. This is only applicable at element or block level, not at
field level.

Field-level permissions are validated:

• On view of UIs
• On save of UI data

The following sections are relevant for Employee Central:

Block HRIS Element Description

Personal Information For more information about how to set

personalInfo
entity-level permissions for this entity,
plus globalInfo fields from the see Permissions for Personal Informa-
country/region-specific Succession tion and Addresses Blocks [page 212].

Data Model

Addresses This is an exception: you can only set

homeAddress
entity-level permissions on this entity,
but not a specific field.

For more information about how to set

entity-level permissions for this entity,
see Permissions for Personal Informa-
tion and Addresses Blocks [page 212].

Dependents personRelationshipInfo This entity is only relevant if you have

activated the Dependents Management
feature in the Admin Center.

You can find more information in the

Implementing and Configuring Depend-
ents in Employee Central guide on the
SAP Help Portal.

Job Information jobInfo The field FTE is a calculated field and

thus read-only; select only View Current
plus jobInfo fields from the coun-
and/or View History.
try/region-specific Succession Data
Model

Compensation Information compInfo The fields range penetration and

compa-ratio are calculated fields and
thus read-only; select only View Current
and/or View History.

Job Relationships jobRelationsInfo

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.

Implementing Employee Central Core

114 PUBLIC Managing Role-Based Permissions
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 active in the system, then the person who
made the latest changes is shown with their full name.

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.

Further Entity Permissions

In addition, for each of the sections, you can set these two permissions on block level:

• [block] Actions permissions allow the user to:

• Insert a new record on the History UI.
• Add a new record using the Take Action dropdown menu, or add a new record using the Edit link in the
block for those blocks that are listed on the Personal Information page.

 Note

Use this option when you want to associate an approval workflow with the changes done in this block.

All the permissions for actions for the effective-dated entities are validated:
• On view of UIs
• On delete
• On correct/Insert
• Edit Link permissions control what users can do in the Manager and Employee Self-Service pages.
The permissions for this are validated:
• On view of UIs
• On save in MSS

The remaining entries refer to the fields listed in the Succession Data Model and country/region-specific
Succession Data Model. If a field is configured in both the Succession Data Model and the country/region-
specific Succession Data Model, only the field from the Succession Data Model is shown in this list.

Related Information

List of Role-Based Permissions

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 115
3.1.1.10 Employee Views

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

List of Role-Based Permissions

3.1.2 Administrator Permissions for Employee Central

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:

Permission Category Description

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 ob-
ject.

Manage User These permissions ensure that users have the correct ac-
cess to all they need in Employee Central. This is especially
important for the integration between Recruiting, Onboard-
ing 1.0, and Employee Central.

Implementing Employee Central Core

116 PUBLIC Managing Role-Based Permissions
Permission Category Description

Metadata Framework These permissions ensure that users can work with generic
objects in the Metadata Framework (MDF).

For more information, refer to the Implementing the Meta-

data Framework guide on the SAP Help Portal.

 Note
What is the difference to the Manage Data permission?

Without the read/write permission, the user cannot see

or manage generic objects on any page in the system.
Without the Manage Data permission, the user cannot
access the Manage Data page, but is still able to manage
data from other pages, such as the Configure Business
Rules page (if the Configure Business Rules permission
is granted).

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 implemen-
tation partner or Account Executive. For any non-imple-
mentation tasks, contact Product Support.

This entry is only displayed if you have activated the

Business Configuration in Admin Tools feature in Provision-
ing.

For more information, refer to the Setting Up and Using Busi-

ness Configuration UI (BCUI) guide on the SAP Help Portal.

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 Em-
ployee Central with other software products.

The Foundation APIs are relevant for foundation data, the

HRIS APIs for person and employment data.

For more information, refer to the SAP SuccessFactors Em-

ployee Central OData API: Reference Guide on the SAP Help
Portal.

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 117
Permission Category Description

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 Imple-
menting Employee Central Time Off guide on the SAP Help
Portal.

For more information about Time Sheet, refer to the Imple-

menting Employee Central Payroll Time Sheet guide on the
SAP Help Portal.

Manage Positions These permissions ensure that users can work with Position
Management.

For more information, refer to the Employee Central Position

Management guide on the SAP Help Portal.

Manage Compensation These permissions ensure that users can work with Em-
ployee Central compensation data.
Manage Pay Scale
For more information, refer to the Implementing and Con-
Manage Deductions figuring Employee Compensation Data in Employee Central
guide on the SAP Help Portal.
Manage Spot Awards

Related Information

List of Role-Based Permissions

3.1.2.1 Main Admin System Permissions

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.

Ensure that at least the following are selected:

• Employee Central Feature Settings

This allows admins to turn on features in Employee Central themselves without having to create a Product
Support ticket.
• Company System and Logo Settings
This allows admins to make enable or disable further company settings, such as validations for sensitive
data.

Implementing Employee Central Core

118 PUBLIC Managing Role-Based Permissions
Related Information

List of Role-Based Permissions

3.1.2.2 Permissions for Foundation Objects

Set permissions to ensure users can work with foundation objects.

Here you define permissions for working with foundation objects.

• 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 Translating Foundation Data.

Related Information

List of Role-Based Permissions

3.1.2.3 Permissions for Foundation Object Types

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.
• Delete: The admin can delete foundation objects by selecting Take Action Permanently delete record
in the History page.

Related Information

List of Role-Based Permissions

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 119
3.1.2.4 Permissions for User Management

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:

• Employee Central Only

The employee is created manually by selecting Add New User and/or by importing the data manually (10+
Imports for each User)
• Onboarding 1.0 to Employee Central
The employee data flows from Onboarding 1.0, either fully or partially depending on the panels selected in
Onboarding. This is done using the Pending Hires process.
• Recruiting to Employee Central
All the information captured in Recruitment flows to Employee Central. Data can be completed using the
Pending Hires process.
• Recruiting to Onboarding 1.0 to Employee Central
All information flows from either from Recruiting or Onboarding 1.0 and the HR admin reviews all the
information using Pending Hires process.

Here, the following checkboxes are relevant for Employee Central:

• 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 block 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.
For example, you may want to restrict the access of a user to all managers of a legal entity.
• Manage Workflow Requests: Grants access to the Manage Workflow Requests link in the Admin Center, for
example, to change the approver for a particular workflow.

 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.

Implementing Employee Central Core

120 PUBLIC Managing Role-Based Permissions
Related Information

Permissions for Hire-Related Actions

List of Role-Based Permissions

3.1.3 Adding Value Help Permissions for Everyone

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. Go to Admin Center Manage Permission Roles .

2. Select Create New.
3. In the Role Name field, specify a name for the role. For example, MDF Foundation Objects Value Help Read.
4. Select the Permission button.
5. Select MDF Foundation Objects. The permission settings page is displayed listing all the MDF FOs.
6. Define settings for BusinessUnit, for example. Apply Read Only permissions to the externalCode field.

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.

a. Select the View Current checkbox.

b. Select the Field Level Overrides checkbox. Additional options are displayed.
c. From the Field drop-down, select the field corresponding to name. In this case, Business Unit Code.
d. From the Permission drop-down next to the field name, select Read Only.
e. We will now set Read Only permission for the name field. In this example, select Business Unit Name
from the Field drop-down and apply the Read Only permission.
f. Now, repeat this for all other fields displayed in the Field drop-down but set Permission to No Access.

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 121
 g. Select Done to save your changes.
7. Repeat step 7 for all migrated MDF Foundation Objects.
8. After the permission settings are done, in Permission Groups, assign the role to Everyone.

Related Information

List of Role-Based Permissions

3.1.4 Accessing Future Organizational Changes

3.1.4.1 Adding a New Parameter to a Dynamic Group Filter

to Extend Permissions

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.

Previously managers and admins could not access the employment records of a user before the exact effective
date of the organizational change, for example, hire, transfer, or promotion. This caused process delays for all
involved.

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.

Implementing Employee Central Core

122 PUBLIC Managing Role-Based Permissions
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

1. Go to Admin Center Manage Business Configuration .

2. Under Filters, select Dynamic Group Filters Create New .

The Dynamic Group Filters page appears.

3. Enable the filter.

4. Select Hris Elements Job Information .

In some cases, you may want to choose Compensation Information instead.

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

The new parameter appears in the drop-down list.

Next Steps

Once the filter is created, you create a permission group or update an existing group to grant them access to
see the employee data.

Related Information

Configuring Standard and HRIS Elements for Dynamic Group Filters

Implementing Employee Central Core

Managing Role-Based Permissions PUBLIC 123
3.1.4.2 Granting Access to a Permission Group to Access
Future Organizational Changes

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.

Procedure

1. Go to Admin Center Manage Permission Roles .

2. Choose the role.
3. In the Permission Role Detail page, scroll to the Grant this role to... section.
4. Select Edit Granting.

The Grant this role to... pop-up opens.

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.

Implementing Employee Central Core

124 PUBLIC Managing Role-Based Permissions
4 Events and Event Reasons

4.1 Events in Employee Central

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:

• Additional Job (1)

• Assignment (2)
• Assignment Completion (3)
• Job Change (16)
• Completion of Probation (15)
• Data Change (5)
• Demotion (4)
• Furlough (11)

 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)
• Probation (14)
• Promotion (8)
• Rehire (R)
• Return from Disability (22)
• Return to Work (23)

 Note

Return to Work is only valid for Leave of Absence.

• Suspension (7)

 Note

Refer to the Restrictions for the Furlough and Suspension Events section for more information.

Implementing Employee Central Core

Events and Event Reasons PUBLIC 125
• 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.

Restrictions for the Furlough and Suspension Events

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

• Employee status is set to ‘Furlough’

• HRIS sync maps employee status from 'Furlough' to 'Inactive'
• Hierarchy Adaptation is only triggered if a position field is changed in imports or from the API, but it is
never triggered when a record with the Furlough event is created using the Job Information History UI save.
• The <to be hired> field is only updated if a position field is changed in Job (Information) History
imports or from the API; it is never triggered in the Job Information History UI save.
• Matrix Relationship Sync is triggered for Job (Information) History imports; it is never triggered in the Job
Information History UI save.
• The Return to Work event is no longer available in the Job History UI. This means that customers must
create a custom event reason for Return from Furlough with employee status 'Active' AND use the Data
Change event.

Suspension
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

• Employee status is set to ‘Suspended’

• HRIS sync maps the employee status from 'Suspended' to 'Active'.
• Hierarchy Adaptation is only triggered if a position field is changed in imports or from the API, but it is
never triggered when a record with the Suspension event is created using the Job Information History UI
save.
• The <to be hired> field is only updated if a position field is changed in Job (Information) History
imports or from the API; it is never triggered in the Job Information History UI save.

Implementing Employee Central Core

126 PUBLIC Events and Event Reasons
• Matrix Relationship Sync is triggered for Job (Information) History imports; it is never triggered in the Job
Information History UI save.
• The Return to Work event is no longer available in the Job History UI. This means that customers must
create a custom event reason for Return from Suspension with employee status 'Active' AND use the Data
Change event.

Restrictions with the Job History UI

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.

Here is the list of affected events:

• 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)
• Add Higher Duty/Temp Assignment (HD)
• End Higher Duty/Temp Assignment (END_HD)
• Obsolete Higher Duty/Temporary Assignment (OHD)

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:

• Add Global Assignment (GA)

• Away on Global Assignment (AGA)
• Back from Global Assignment (BGA)
• End Global Assignment (EGA)

Implementing Employee Central Core

Events and Event Reasons PUBLIC 127
Data Changes Allowed for Pension Handling

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

Event Reasons in Employee Central [page 128]

Picklist Configuration for Employee Status and Job Relationship Type [page 266]
Event Reason Derivation Business Rules [page 136]
Payroll Event
Adding Standard Events for Supporting Contingent Workers

4.2 Event Reasons in Employee Central

Event reasons are defined by you based on the needs of the organization. Event reasons are used to define
more specifically the reason why an event has taken place.

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 that employee’s professional life. For example, an event could be a promotion or a transfer to another
department. The information about which event lies behind this change is stored in the system for reporting
purposes. However, such a change might also include a change to the employee’s status, for example, if the
employee leaves the company, the employee status would be changed accordingly to reflect that the employee
is no longer an active user in the system.

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”.

Implementing Employee Central Core

128 PUBLIC Events and Event Reasons
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.

System Behavior

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.

If the Event Reason Derivation feature isn’t enabled, the two

fields are shown on the UI for the user to manually select.

An event can be selected if at least one event reason is

available. The availability of an event reason depends on the
following:

• Permissions are applied for event reasons.

• The employee status in the event reason is set to No
Selection. Event reasons with any other status aren’t
shown in the Event Reason drop-down menu.

Implementing Employee Central Core

Events and Event Reasons PUBLIC 129
UI Expected Behavior

Job History Events and event reasons are displayed in Job History.

Only events that don't change the employee status can be

inserted or created in Job History. The exceptions for this
are Furlough and Suspension since there are no dedicated UI
transactions for these actions available in the system.

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
displayed 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
displayed in the Event Reason field.

Add Global Assignment All event reasons that have the event "Add Global Assign-
ment" (external_code GA) and the employee status "Active"
(external_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 ter-
minating employees with direct reports.

Related Information

Event Reason Derivation Business Rules [page 136]

Picklist Configuration for Employee Status and Job Relationship Type [page 266]

Implementing Employee Central Core

130 PUBLIC Events and Event Reasons
4.3 Creating Event Reasons for Employee Central

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

1. Go to Admin Center Manage Organization, Pay and Job Structures .

2. Select Create New: Event Reason.
3. Create the event reason for the listed events. Enter the mandatory data and ensure you include the
required employee status.

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 -

Assignment Completion Terminated

Return from Disability Active

Transfer -

Suspension Suspended

Job Reclassification -

Job Change -

Pay Rate Change -

Implementing Employee Central Core

Events and Event Reasons PUBLIC 131
 Event Status

Demotion -

Promotion -

Additional Job -

Layoff Furlough

Rehire Active

Termination Retired

Terminated

4. Save your changes.

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

If required, you can create country/region-specific event reasons.

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

Using the Check Tool

List of Role-Based Permissions
Configuring Country/Region-Specific Event Reasons

Implementing Employee Central Core

132 PUBLIC Events and Event Reasons
4.4 Creating a Fallback Event Reason Configuration

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

onSave Cross-Entity Rule: Compensation Information to Job Information

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

1. Go to Admin Center Manage Data .

2. Select Create New: Fallback Event Reason Configuration.
3. Add the following data:

• Code: This field is the external code.

• Status: Set to Active or Inactive.
You can only have 1 configuration set to Active in the system.
• Default Fallback Event Reason: Select the event reason.
This is used in all cases if no mapping exists.
4. Optional: Configure the mapping. Select an event and then the fallback event reason if you want to
differentiate between individual events.

For a Hire event, then Fallback Event Reason is Data Change.

5. Save your changes.

Implementing Employee Central Core

Events and Event Reasons PUBLIC 133
Related Information

Cross-Entity Rules [page 156]

4.5 Configuring Country/Region-Specific Event Reasons

Customers that operate in multiple countries/regions often have event reasons that are very specific for a
country/region.

Prerequisites

• You use the Country/Region object.

• You have imported the Events picklist and have created event reasons in the system.

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

This feature is useful for:

• 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 .

Implementing Employee Central Core

134 PUBLIC Events and Event Reasons
 3. Under Associations, in the Destination Object field, select the wrapper generic object that you have
created:

4. Save your changes..

2. For each country/region, assign the event reason relevant for that country/region.

a. Choose Admin Center Manage Data .

b. In the Search field, select the Country/Region object.
c. In the field next to Country/Region, select the corresponding country/region, for example, United
States (USA).
d. Select Take Action Make Correction .
e. Under Event Reasons, select the corresponding event reasons.

 Note

• Assign the country/region-specific event reasons to the relevant country only.

• Assign the globally-applicable event reasons to all countries/regions.

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.

f. Save your changes.

Next Steps

Repeat these steps for all relevant countries/regions.

Related Information

Generic Objects [page 85]

Event Reasons in Employee Central [page 128]

Implementing Employee Central Core

Events and Event Reasons PUBLIC 135
5 Creating Rules

5.1 Event Reason Derivation Business Rules

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, you can select the Event Reason
Derivation rule scenario that 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 instead of the
Basic scenario.

Recommendations for Configuration

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 workflow derivation is triggered.
The order of execution is:
• 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.

Implementing Employee Central Core

136 PUBLIC Creating Rules
  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.

The rule handling is valid for the following transactions:

• 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 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.

Behavior with Imports

• Using Event Reason Derivation with Business Rules

To have the event reason derived using business rules, you must enable the Enable Business Rules for
selected entities permission for imports.
If the event reason value is provided in the import template, then the event reason provided in template is
taken into account rather than the event reason derivation by onSave business rules. The data is validated
by the system to ensure that an event reason is given. Since it is a required field, it cannot be empty.
If an event reason is provided but is empty in the template, then the event reason is derived using the
onSave business rules.
If the event reason is removed from the import template or if the &&NO_OVERWRITE&& value is provided
in the template for the Event Reason field, then the event reason used before the update will be used.

Implementing Employee Central Core

Creating Rules PUBLIC 137
• Manual Event Reason Selection
If the event reason value is provided in the import template, then this event reason is used.
The data is validated by the system to ensure that an event reason is given. Since it is a required field, it
cannot be empty.
If the event reason is removed from the template or if &&NO_OVERWRITE&& value is provided in the
template for Event Reason field, the system reminds the user that an event reason is a required field.

Example: System Behavior

Consider a case where both the Job Information and Compensation Information entities are processed on the
Manager Self Service (MSS) Take Action page.

The event reason will be derived as follows:

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.

Check Tool for Event Reason Derivation Rule Scenario

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

Events in Employee Central [page 125]

Rule Handling with Manager Self-Service [page 280]
Implementing Business Rules in SAP SuccessFactors

Implementing Employee Central Core

138 PUBLIC Creating Rules
5.2 Workflow Derivation Business Rules

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.

5.3 Business Rules in Employee Central

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.

You can set up business rules to do the following:

• Set default values

You can define default values for specific fields.
Example: The OK to rehire field on the termination screen is always Yes by default.
• Set conditional values
You can define which default value is set when a specific condition is met: IF this condition is met, THEN
this is how the system should react.
Example: When the admin selects the business unit ENG, the job classification is automatically set to
Engineering.
• Set field properties

Implementing Employee Central Core

Creating Rules PUBLIC 139
 You can dynamically default a field as visible or required.
Example: If the company is COMP_USA, the phone extension is always required.

 Note

However, hiding all fields in a block 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.

• Display error messages

You can define that an error message is displayed.
Example: The admin forgot to enter the national ID for a new employee; the error message National ID is
required is displayed.
• Calculate transient fields
You can define transient fields that are calculated “on the fly” when the user opens a page. The calculated
values are not meant to be written to the database, as they are not fixed values.
Example: The user can see the employee's current age in the system.
• Validate consistency of fields
You can define that all relevant fields are provided.
Example: If an admin selects a Contract Type with fixed term validity, the Contract End Date needs to be
provided. This is automatically checked.

 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.

5.3.1 Rule Scenarios for Employee Central Core

Rule scenarios help you create rules correctly, based on the rule context and parameters for a given scenario.

Rule Scenario Description

Trigger Rules to Generate Assignment ID External You can use this scenario to create rules that generate the
value for Assignment ID External based on MDF Sequence
objects. Create a single rule only based on this scenario. For
more information, refer to the Assignment ID topic in the
Implementing Employee Central Core guide on the SAP Help
Portal.

Trigger Rules to Generate Employee ID for Hire/Rehire You can use this scenario to create rules that generate
an Employee ID from the Metadata Framework (MDF) Se-
quence and assign it to the User ID field of the Employee
Information object during the Hire/Rehire with new employ-
ment process. You must first register the rule for the Hire/
Rehire Configuration object. If you have enabled the On-
boarding feature, you must also register the rule for On-
boarding Configuration object.

Implementing Employee Central Core

140 PUBLIC Creating Rules
Rule Scenario Description

Trigger Rules for Hire/Rehire You can use this scenario to create rules for the Hire/Rehire
with new employment process using the Employee Informa-
tion base object.

Trigger Rules for Event Reason Derivation You can use this scenario to create rules that derive the
event reason for Job and Compensation Information Models.

Trigger Rules to 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.

Trigger Rules to Enforce New Employment for Rehire You can use this scenario to create rules that validate busi-
ness requirements for rehire with new employment and dis-
play 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 Config-
uration, rules created using this scenario can be registered
only for the onSave event type.

Trigger Rules to Display Internal Job History You can use this scenario to create rules to display the Inter-
nal Job History on the People Profile page.

Trigger Rules to Validate HRIS Elements You can use this scenario to create rules that validate HRIS
Elements and display messages.

Trigger Rules to 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 In-
formation 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.

You can have a maximum of 5 cross-entity rule scenarios for

an HRIS entity.

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
onChange 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
created using this scenario can be registered only for the
onSave event type.

Trigger Rules for 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 Employ-
ment Details Model as the base object. This rule is executed
during the Off Cycle Event Batch Processing Job.

Implementing Employee Central Core

Creating Rules PUBLIC 141
Related Information

Rule Scenarios
Example Business Rules for Compensation
Rule Scenarios Available in Position Management
Rule Scenarios for Time Off

5.3.2 Optimizing Business Rules

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 block 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.

Think Long Term

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.

Optimize Where Possible

• 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.

Make Rules Scalable

Try to figure out ways to ensure that business rules don't need to be changed once set up.

Implementing Employee Central Core

142 PUBLIC Creating Rules
Take the example of a customer who has a vastly different process for the termination of an employee,
dependent on whether it is a voluntary termination or an involuntary termination. Besides a separate workflow
that is triggered, there may be additional checks that need to happen based on the termination type or the
defaulting of certain fields. For the workflow rule, a better design than listing all the voluntary terminations in
the IF statement might be to have a flag on the Event Reason object that separates out a voluntary termination
from an involuntary termination. By doing this, should the customer decide to add or remove termination event
reasons in the future, they do not have to touch the business rule.

5.3.3 Standard and Model Base Objects for Employee Central

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:

When the user is on

this page: And you want to trigger the rule when the user is... Then choose this type of base object:

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 144]).

Add New Employee • Opening a page (see onInit event) Employee Information/Employee Information
• Changing a field value (see onChange event) Model
• Saving a page (see onSave event)
 Note
Select Employee Information Model to
set field properties in the rule (for more
information, refer to About Model Base
Objects [page 144]).

Implementing Employee Central Core

Creating Rules PUBLIC 143
When the user is on
this page: And you want to trigger the rule when the user is... Then choose this type of base object:

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

Beware that onChange rules are not supported for:

• Hidden fields
• Foundation Objects

Related Information

Overview: Rule Events in Employee Central [page 147]

Event Types for HRIS Elements and HRIS Fields [page 148]

5.3.3.1 Properties of Model Base Objects

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

Here's some more information about the different properties:

• Required
You can make a field required or not by entering true or false accordingly.

 Note

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

Implementing Employee Central Core

144 PUBLIC Creating Rules
 For this HRIS element in the Succession Data Model... ...this HRIS field is always required:

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

Implementing Employee Central Core

Creating Rules PUBLIC 145
 For this HRIS element in the Succession Data Model... ...this HRIS field is always required:

(for all HRIS elements where applicable) start-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

For Model base objects:

• Consider whether the onSave event makes sense to be used when you set field properties. For
example, a field should be set to mandatory as soon as the user opens a page (then choose onInit
event), or when the user makes certain changes (onChange event), but not when the user saves a
change.

5.3.4 Mapping of Employee Central Data Types and Business

Rule Field Types

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.

Implementing Employee Central Core

146 PUBLIC Creating Rules
• 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

String Text String

Boolean Boolean Yes/No

Date Date Date

Double Decimal Decimal

Decimal Decimal Decimal

Big Decimal Decimal Decimal

Long Number Integer

(Picklist) Value Dropdown list for user to select from

(Foundation object, for example: Value Dropdown list for user to select from
department, division)

(Enum, for example: Gender, which has Enum Dropdown list for user to select from
a picklist)

5.3.5 Overview: Rule Events in Employee Central

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.

Table 3: Overview: Relationship Between Rule Events and Pages in Employee Central

Add New Em-

ployee Page
Manage Organiza- People Profile - People Profile
tion, Pay and Job Personal Informa- - Employment In- Take Action But- Manage Pending
Rule Event Types Structures Page tion formation ton Hires Page

OnInit Yes No No No Yes

OnSave Yes • History • History Yes Yes

• Edit • Edit

OnChange No • History • History Yes Yes

• Edit • Edit

OnView No • History • History Yes No

• Edit • Edit
• Personal In- • Employment
formation Information
block block

Implementing Employee Central Core

Creating Rules PUBLIC 147
 Add New Em-
ployee Page
Manage Organiza- People Profile - People Profile
tion, Pay and Job Personal Informa- - Employment In- Take Action But- Manage Pending
Rule Event Types Structures Page tion formation ton Hires Page

OnPostSave No No Yes (only for Job Yes Yes

Inormation)

5.3.5.1 Event Types for HRIS Elements and HRIS Fields

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.

Here's an overview of the available event types and when to use which:

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.

For example, if the user didn't make an entry in a mandatory

field, an error message is displayed.

You can also use this to create or updated data.

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 hid-
den fields.

Implementing Employee Central Core

148 PUBLIC Creating Rules
 Use this
Rule is triggered event Assign the rule event
when... type: to: Use this event to:

Page with transient onView HRIS element Default the value for a field or to change field properties.
field 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).

For example, to calculate an employee's age.

Note: Requires an additional onSave rule that sets the transi-

ent field back to null.

 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 onPostSav HRIS element Trigger events for Intelligent Services.
object have been e
saved
 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.

Behavior for onView Rules

onView rules have the following behavior:

• Permissions are not checked after onView rules are executed.

• You cannot use onView rules for the following objects:
• Home Address
• For Model base objects that represents data in rows and columns (also referred to as 'data grids'), you have
to consider the following:

Implementing Employee Central Core

Creating Rules PUBLIC 149
 • To set a column to invisible or required, create a rule without an If condition (Always True selected) and
put only visibility and required changes in the Then statement of the rule. Do not set values here.
• To set values for single rows or for the whole data grid: Create a rule with or without If conditions and
set the values in the Then statement. Do not set the visible or required attributes in this rule.

 Note

This applies to the following Model base objects:

• Spot Bonus Model (for HRIS element payComponentNonRecurring)
• Job Relationships Model (for HRIS element jobRelationsInfo)
• Compensation Model (for HRIS element payComponentRecurring)
• National ID Information Model (for HRIS element nationalIdCard)
• Work Permit Info Model (for HRIS element workPermitInfo)
• Email Information Model (for HRIS element emailInfo)
• Social Accounts Information Model (for HRIS element imInfo)

5.3.6 Common Problems for Business Rules in Employee

Central

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.

What you can do with rules Do Don't

Assign rules to all HRIS elements You can assign rules only to HRIS el- You cannot assign rules to the
ements contained in the Succession userAccountInfo HRIS element.
Data Model, the country/region-specific
Succession Data Model, or the Corpo-
rate 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.

Implementing Employee Central Core

150 PUBLIC Creating Rules
What you can do with rules Do Don't

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,
Rules with Employee Information and
add it to the If condition.
Employee Information Model are trig-
gered only during new hire flow.

If the rule base object is a model object,

then always read/set the field proper-
ties for the value of that field, but not
the direct field itself.

The difference between Job Information

and Job Information Model as base ob-
jects is that for Job Information, the
system can only work with the field val-
ues in the rule. But with Job Informa-
tion Model as the base object, in ad-
dition to field values, the system can
also work with field properties such as
Required or Visibility. Customers can
choose depending on the requirement
of whether field values or field proper-
ties are needed.

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 employ-
ment-related entities.

• Job Information
• Compensation Information
• Employment Information
• Job Relationships
• Pay Component Recurring
• Pay Component Non-Recurring

These rules are triggered based on

changes made in the Take Action menu
as well as the History UI. If these rules
are configured as onSave rules, they will
also be triggered during imports and
API calls.

Implementing Employee Central Core

Creating Rules PUBLIC 151
What you can do with rules Do Don't

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 prop-
erties 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 block.

Use rules to set valid field properties You can use rules to change two field Not applicable

properties - visibility and required.

Valid values for required:

• true
• false

List of visibility options:

• None: The field isn't visible.

• Edit: The field can be viewed and
changed.
• View: The field can only be viewed.

 Note
You can't set values for fields of a
Foundation Object.

For entities supported on Centralized

services, if a field is mandatory and
a rule tries to change the visibility to
none, the system still validates the field
to check whether a valid value is added.

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 correspond-
ing Employee Central object, preceded
by the country/region code (for exam-
ple: IND for India).

Make sure that the country/region-spe-

cific rules are in the Country/Region-
Specific Succession Data Model.

Implementing Employee Central Core

152 PUBLIC Creating Rules
What you can do with rules Do Don't

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 HRIS field or HRIS element once in
field or the same element in the coun- the Succession Data Model, and an-
try/region-specific Succession Data other rule in the Country/Region-spe-
Model cific Succession Data Model.

Use pay component group sums in A pay component group sum is the Not applicable
rules total amount (sum) of the pay compo-
nents that are part of a specific pay
component group. You can use pay
component group sums in rules, for ex-
ample, to perform calculations.

The pay component group sums

are listed under the Compensation
Information object, together with the
other Compensation Information fields.
Only the pay component groups are
shown here that are displayed on the
compensation UI (that means you have
defined Display on Comp UI = Yes un-
der Manage Organization, Pay and Job
Structures).

Rules for recurring pay components Not applicable Do not create OnChange rules for re-
curring pay components of type num-
ber 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.

You can, however, create an OnInit rule

to default position entry date with re-
hire date. Set the base object of the rule
to Job Information Model.

Set onSave rules in the jobinfo ele- Not applicable If you set the event reason through an
ment onSave 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.

Implementing Employee Central Core

Creating Rules PUBLIC 153
What you can do with rules Do Don't

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, base object, note that the system can
before a contract expires. only read values for the fields of the
same entity only.

Similarly, if you use Job Information as

the base object, you can only check for
values in Job Information, and not other
elements.

Use previous values in rules The previous value property is available Not applicable
for all fields when the base object is a
model object.

However, in case of non-effective-dated

entities such as Person Information,
Employment Information, Email Infor-
mation, and so on, the previous value is
the value stored in the database before
the transaction began.

In case of effective-dated entities such

as Job Information, when new records
are inserted or updated with Take
Action, then the value is taken from
the previous effective-dated (date +
sequence number) record in the data-
base. In cases of updates made with
Make Correction, then it is the value for
the field on the same effective-dated
(date + sequence number) record in the
database.

Use country of company in rules Use the country listed in the Legal Do not use the <country of
Entity field, since this is stored in the company> field in the rule because it
database. is a transient field, meaning it is not
stored in the database.

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
configured for the Person entity, it will
not be triggered in the system, due to
the presence of the Employee node.

To fix this problem, you can remove the

Employee node to avoid confusion in
the system.

Implementing Employee Central Core

154 PUBLIC Creating Rules
What you can do with rules Do Don't

Use picklists in rules If you copy values from an MDF picklist Not applicable
to 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 Cross entity rules with, for example,
rule scenario. This limits the base ob- Employment Details as the base object
ject to either Employee Information or cannot set values in another entity such
the Employee Information model. This as Job Information in the Add New Em-
ensures that all the objects involved in ployee UI. You need to use Employee
hire/rehire are available to the rule even Information as the base object.
though they are not yet saved in the
system.

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
DELETE operation on a Job Information
record.

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
ground job two groups of rules will not be triggered or executed.

• onSave rules on Job Information

(with Job Information Model as the
base object)
If these rules change any recurring
pay components, then the result
(meaning, the updated pay compo-
nent and Compensation Informa-
tion) are saved.
• onChange rules on the pay com-
ponent field of non-recurring pay
component
If these rules change the non-re-
curring pay component, then the
result is saved.

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
supported event is onPostSave.

Implementing Employee Central Core

Creating Rules PUBLIC 155
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.
8. If both Job Information and Compensation Information are updated from Take Action, then Job Information
OnSave rules are executed before Compensation Information OnSave rules.
9. For OnChange rules, you can enable browser extensions (such as F12 in Google Chrome), and then check
for the call "triggerRule" to validate its response.
10. OnSave rules are executed at the time of workflow initiation, not at the time of the approval during the final
step of the workflow.

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.

5.3.7 Cross-Entity Rules

For employment-related 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.

Cross-entity rules are supported for these entities:

• Job Information
• Job Relationship Information
• Compensation Information
• Recurring Pay Component
• Non-Recurring Pay Component

Implementing Employee Central Core

156 PUBLIC Creating Rules
• Employment Details

The source/target direction is very important. The source element must be the base object of the rule.

Common use cases for cross-entity rules are

• 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

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-rules are supported with workflows.

If the source entity supports forward propagation, then by default, the target entity is also supported with
forward propagation when data is updated using cross-entity rules.

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 block such as Compensation Information and Recurring Pay Components).

Event Reason Derivation

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.

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.

Rules Using the Create Expression

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.

Implementing Employee Central Core

Creating Rules PUBLIC 157
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Job Information - Supported: Not Supported Supported: Supported: Not Supported

• onSave • onSave • onSave

• onChange • onChange

Job Relation- Not Supported - Not Supported Not Supported Not Supported Not Supported
ships

Compensation Not Supported 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
Compo-
nent. Do
not navi-
gate to Em-
ployment
Details and
then to the
Recurring
Pay Com-
ponent.

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
• onChange

Implementing Employee Central Core

158 PUBLIC Creating Rules
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Employment Not Supported Not Supported Not Supported Supported: Not Supported -
Details (Active
Employment)
• onSave

Employment Supported: Supported: Supported: Supported: Supported: -

Details (Inactive
Employment)
• onSave • onSave • onSave • onSave • onSave

Rules Using the Set Expression

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.

Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Job Information - Supported: Supported: Supported: Supported: Supported:

• onSave • onSave • onSave • onSave • onSave

• onChange • onChange • onChange • onChange

Job Relation- Supported: - Not Supported Not Supported Not Supported Supported:
ships
• onSave • onSave
• onChange

Implementing Employee Central Core

Creating Rules PUBLIC 159
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Compensation Supported: Supported: - Supported: Supported: Supported:

Information
• onSave • onSave • onSave • onSave • onSave

• onChange • onChange • onChange

 Cau-
tion
We recom-
mend navi-
gating di-
rectly from
Compensa-
tion Infor-
mation to
the Recur-
ring Pay
Compo-
nent. Do
not navi-
gate to Em-
ployment
Details and
then to the
Recurring
Pay Com-
ponent.

Recurring Pay Supported: Supported: Supported: Not Supported Supported: Supported:

Component
• onSave • onSave • onSave • onSave • onSave
• onChange • onChange

Non-Recurring Not Supported Not Supported Supported: Supported: - Supported:

Pay Component
• onSave • onSave • onSave

Implementing Employee Central Core

160 PUBLIC Creating Rules
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Employment Supported: Not Supported Supported: Supported: Supported: -

Details (Active
Employment)
• onSave • onSave • onSave • onSave

 Not
e
This
only
works
when
both
Em-
ploy-
ment
Infor-
mation
and
Job In-
forma-
tion
are
part of
the
trans-
action
for
Hire/
Re-
hire/
Termi-
nation.
It will
not
work if
only
Em-
ploy-
ment
Infor-
mation
is
chang
ed.

Implementing Employee Central Core

Creating Rules PUBLIC 161
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Employment Supported: Supported: Supported: Supported: Supported: -

Details (Inactive
Employment)
• onSave • onSave • onSave • onSave • onSave

 Not
e
This
only
works
when
both
Em-
ploy-
ment
Infor-
mation
and
Job In-
forma-
tion
are
part of
the
trans-
action
for
Hire/
Re-
hire/
Termi-
nation.
It will
not
work if
only
Em-
ploy-
ment
Infor-
mation
is
chang
ed.

Implementing Employee Central Core

162 PUBLIC Creating Rules
Rules Using the Delete Expression

Here is a general overview of which elements support cross-entity rules to other elements to delete records:

 Note

You cannot delete Job Information or Compensation Information records using the Delete function in a
business rule.

Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Job Information - Supported: Not Supported Supported: Supported: Not Supported

• onSave • onSave • onSave

• onChange • onChange

Job Relation- Not Supported - Not Supported Not Supported Not Supported Not Supported
ships

Compensation Not Supported 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
Compo-
nent. Do
not navi-
gate to Em-
ployment
Details and
then to the
Recurring
Pay Com-
ponent.

Implementing Employee Central Core

Creating Rules PUBLIC 163
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

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 Supported: Not Supported -
Details (Active
Employment)
• onSave

Employment Supported: Supported: Supported: Supported: Supported: -

Details (Inactive
Employment)
• onSave • onSave • onSave • onSave • onSave

Related Information

Cross-Entity Rules with Centralized Services [page 301]

5.3.8 Adding Contexts for Business Rules

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 do not have to add contexts to 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 are not executes where rule contexts which 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).

Implementing Employee Central Core

164 PUBLIC Creating Rules
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.

You can restrict the triggering of rules to the following contexts:

• Edit
• History
• Imports
• Mass Changes
• Hire
• Onboarding
• Promotion 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.

Context/Rule Workflow Deriva- Event Reason Forward Propaga-

Type tion Derivation Validation Cross-Entity tion

Edit (MSS/ESS) Yes Yes Yes Yes Yes

History No No Yes Yes Partially Sup-

ported

This is supported
for inserting a new
record rather than
editing an existing
record.

Imports No No Yes Yes Yes

Only when work-

flows are disabled
for imports.

Mass Changes No No No No Yes

You would not

want to create ap-
proval workflows
when making the
same change for
lots of people.

Implementing Employee Central Core

Creating Rules PUBLIC 165
Context/Rule Workflow Deriva- Event Reason Forward Propaga-
Type tion Derivation Validation Cross-Entity tion

Hire/Rehire Yes No Yes No No

Onboarding No No No No No

Promotion from No No No No No
Compensation
Planning

Report No-Shows Yes No Yes No No

Off Cycle Event No No No No Yes

Batch

Termination Yes No Yes No No

API No No Yes Yes Yes

 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).

Procedure

1. Go to Admin Center Manage Business Configuration .

2. Under Employee Central, select the relevant HRIS element.
3. For onSave rules, in the Trigger Rules section, select the Details link.

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.

Implementing Employee Central Core

166 PUBLIC Creating Rules
5.3.9 Managing Conditional Groups and Defaults

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.

Related Information

Configuring Objects for Conditional Defaults [page 167]

Examples for Conditional Defaults [page 170]
Creating Business Rules for Conditional Defaults [page 171]
Assigning Business Rules for Conditional Defaults [page 173]

5.3.9.1 Configuring Objects for Conditional Defaults

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.

Implementing Employee Central Core

Creating Rules PUBLIC 167
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.

a. Go to Admin Center Manage Permissions Roles .

b. From the Permission Role List, choose either the role (System Admin) or Take Action Edit for the
role you want to change.
c. Choose the Permission... button.
d. Choose Administrator Permissions Employee Central Core Configuration .
e. Select the permissions you need to grant to the role.
f. Choose Done.
3. Configure the condition fields you would like to use by adding custom fields to the definitions of Employer
and Employee Group Items. Custom fields are used as condition fields. The data type and source should
match for a condition field and its custom field.

a. Go to Admin Center Configure Object Definitions .

b. From the Search list, select Object Definition and then select either Employer Group Items or Employee
Group Items from the list next to it.
c. Choose Take Action Make Correction .
d. Add custom fields to these group items at the end of the Fields section:
1. Employer Group Items: For example, add custom fields with Legal Entity and Location as the data
source (organizational conditional fields can be added to group users by their employer data).
2. Employee Group Items: For example, add custom fields with Employee Class and Employee Type
as the data source (employee related conditional fields can be added to group users by their
employee data).
e. For each custom field, choose Details and then enter the Data Type and Valid Value Source.

 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.

Implementing Employee Central Core

168 PUBLIC Creating Rules
 a. Go to Admin Center Manage Data .
b. From the Create New list, choose an object and enter the configuration data for these objects:
• For configuring condition fields and corresponding default fields.
• Condition Field

 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

 Note

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

List of Role-Based Permissions

Examples for Conditional Defaults [page 170]
Creating Business Rules for Conditional Defaults [page 171]
Assigning Business Rules for Conditional Defaults [page 173]

Implementing Employee Central Core

Creating Rules PUBLIC 169
5.3.9.1.1 Examples for Conditional Defaults

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

Employer Group: ER1

Employer Group Item: ABC01, FL US

Employer Group: ER2

Employer Group Item: ABC01, NY US

Employer Group: ER3

Employer Group Item: ABC01, AZ NU

Employee Group

Employee Group: EE1

Employee Group Item: Partial Retirement, Inative

Employee Group: EE2

Employee Group Item: Partial Retirement, Active and exempt

Employee Group: EE3

Employee Group Item: Partial Retirement, Active and non-exempt

Default Group

Pay Scale Type

Default Group Items

ER Group EE Group Default Value

ER1 EE1 Commission

Implementing Employee Central Core

170 PUBLIC Creating Rules
ER Group EE Group Default Value

ER1 EE2 Hourly

ER2 EE3 Salaried

Pay Scale Area

Default Group Items

ER Group EE Group Default Value

ER1 EE2 Miami Beach

ER2 EE3 New York

ER3 EE1 Scottsdale

Related Information

Configuring Objects for Conditional Defaults [page 167]

Creating Business Rules for Conditional Defaults [page 171]
Assigning Business Rules for Conditional Defaults [page 173]

5.3.9.2 Creating Business Rules for Conditional Defaults

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

• You've enabled Employee Central V2 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.

• You've configured the objects and condition fields that are used to set the default fields.

Implementing Employee Central Core

Creating Rules PUBLIC 171
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.

2. Go to Admin Center Configure Business Rules .

3. Choose  (Create New Rule).
4. Expand either of these categories and choose a rule scenario:

• For HRIS elements: Basic Basic

• For MDF objects: Metadata Framework Rules for MDF Based Objects

 Note

SAP recommends that you select the Metadata Framework category for MDF objects.

5. Enter the required details to create your business rule.

 Note

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

Only the Set operation is supported.

9. Choose the configured default field of the base object.

10. Select a rule function for the Value. Based on the default field of an object, only one of these rule functions
is available:

Implementing Employee Central Core

172 PUBLIC Creating Rules
 • Get Generic Object Default Value
• Get Foundation Object Default Value
• Get MDF Picklist Default Value
• Get Legacy Picklist Default Value
11. Choose the default field as the first parameter of the function.

 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

Assigning Business Rules for Conditional Defaults [page 173]

Get Foundation Object Default Value
Get Generic Object Default Value
Get Legacy Picklist Default Value
Get MDF Picklist Default Value

5.3.9.3 Assigning Business Rules for Conditional Defaults

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.

Implementing Employee Central Core

Creating Rules PUBLIC 173
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.

2. Go to Admin Center Configure Business Rules .

3. On the Business Rules Admin page, select your business rule.
4. Choose the  (The rule is not assigned) icon.
• In the Assigned column.
• Next to the rule name on the Configure Business Rules page.
To assign your business rules to HRIS elements, go to step 8.
5. Choose Assign Rule to see a list of assignment options. For a required option, navigate to its rule
assignment page.

The Configure Object Definitions page appears.

6. Choose Take Action Make Correction .

 Remember

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

8. Go to Admin Center Manage Business Configuration .

9. Select the base object from Employee Central HRIS Elements .

10. From the list of fields, choose Details of a condition field.
11. In the Trigger Rules section, enable your business rule for the OnChange event.

 Note

For the OnInit and onSave events, you need to enable your business rule at the object level in the
Trigger Rules section.

Implementing Employee Central Core

174 PUBLIC Creating Rules
12. Choose Done and then Save.

Results

The rule is triggered when the values of the condition fields are changed or the base object is initialized or
saved.

5.3.10 Example Employee Central Business Rules

Here are a few examples of how you can use business rules in your system.

General

For all business rules, do the following:

1. Go to Admin Center Configure Business Rules .

2. Create a new rule.
3. Select a rule scenario.
4. Create a rule based on the examples shown.
5. Save your changes.

Once rules are created, they must be assigned to the element in Manage Business Configuration and the trigger
event selected.

Create Objects

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.

Implementing Employee Central Core

Creating Rules PUBLIC 175
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.

Create Custom MDF Objects

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.

This only works for:

• Custom MDF objects

• Job Information and Job Information Model base objects
• onSave rules for Job Information HRIS element

Implementing Employee Central Core

176 PUBLIC Creating Rules
Here’s an example of how to create a custom MDF object for cust_benefitPlanOverride when the employee
subgroup changes:

Adding Additional Parameters

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.

Implementing Employee Central Core

Creating Rules PUBLIC 177
Setting Field Properties

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.

Implementing Employee Central Core

178 PUBLIC Creating Rules
Check Correct Salutation and Gender

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.

This rule can either be an onChange rule for the fields for Gender/Salutation or an onSave rule for employee
personal information or both.

Implementing Employee Central Core

Creating Rules PUBLIC 179
Automatically Set Retirement Date

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 use the Date Plus rule function to set the retirement date based on the date of birth, for example, set
the retirement date when employee age is 50 years (600 months) old.

This is an onSave rule for job information.

Implementing Employee Central Core

180 PUBLIC Creating Rules
Default Phone Information

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.

Implementing Employee Central Core

Creating Rules PUBLIC 181
Set Phone Number Format

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.

This is an onChange rule for the <phone-number> field in phone information.

Set Job Title

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.

Implementing Employee Central Core

182 PUBLIC Creating Rules
Validate Data in Position and 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.

This is an onSave rule for job information.

Implementing Employee Central Core

Creating Rules PUBLIC 183
Insert Record in Job Information for Every Change in Job Relationship

You can use a cross-entity business rule to create a record in the Job Information block for every change in Job
Relationship information for a user.

This is an OnSave rule for Job Relationship information.

Implementing Employee Central Core

184 PUBLIC Creating Rules
End Deductions on Termination

You can use a cross-entity business rule to end recurring deductions as of the termination date.

This is an OnSave rule for employment information.

Implementing Employee Central Core

Creating Rules PUBLIC 185
Set Field-Level View Permissions for Non-Effective Dated Blocks

Use OnView rules to control who can see which fields in the non-effective dated blocks and ensure data
protection and privacy for your users, since you cannot use permissions to set field-level View permissions for
such blocks.

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.

Implementing Employee Central Core

186 PUBLIC Creating Rules
Cross-Entity Rule to Update Job Relationships

An example where, based on the Location of the employee, you change the Location Manager (matrixManager)
of that user in the Job Relationships section.

Once the rule is created, in Manage Business Configuration assign it to the jobInfo element. For the base object,
select Job Information Model (as in the rule) and then select onSave as the event type. Select the rule from
drop-down list and save your changes.

Implementing Employee Central Core

Creating Rules PUBLIC 187
Triggering Cross-Entity Rules to Delete Data

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.

Based on this example, the results would be that the first rule deletes the base salary recurring pay component
and the second rule should not be triggered, meaning that the meal allowance pay component should not be
created.

Implementing Employee Central Core

188 PUBLIC Creating Rules
Rule Navigation Using Biographical Information and Employment Details

This rule contains Employment Details as a rule parameter, which is a single instance, and navigates from
Biographical Information to Employment Details which is expected to be a list.

 Note

We've handled only one variant of the collection filter issue. However, self-entity rules with navigations such
as payComponentRecurring.employmentInfo.payComponentRecurring may not be resolved and
the log message is, Unsupported navigation from base object: %s to target object: %s.

Rules Including Supervisor Fields

This rule configuration includes jobInfo and the supervisor’s jobInfo too.

Implementing Employee Central Core

Creating Rules PUBLIC 189
This rule configuration retrieves the jobInfo of the supervisor.

Rules Including Biographical Information of Parents and Dependents

This rule configuration includes the biographical information of the parents and dependents.

This rule configuration retrieves the dependent's biographical information. Dependent related entities are
resolved using the Dependent’s object.

Implementing Employee Central Core

190 PUBLIC Creating Rules
Related Information

Example Business Rules for Compensation and Recurring Pay Components

Business Rules for Indirect Valuation
Example Business Rules for Termination

Implementing Employee Central Core

Creating Rules PUBLIC 191
6 Entities in Employee Central

Information in Employee Central is organized around the type of data it is, for example, personal or
employment. This information is then shown on the People Profile in organized blocks. Those blocks 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

Effective-Dated Entities Description Available on Centralized Services

Personal Information This is personal information that can Imports, Editing UI, History UI

change over time such as marital sta-

tus, name, gender, and so on, including
country/region-specific Global Informa-
tion.

Addresses Employees can add multiple addresses Imports, Editing UI, History UI
as well as multiple types of addresses.

Dependents Employees can add multiple depend- Person Relationship Imports, Editing UI,
ents along with their data. History UI

Non-Effective-Dated Entities Description Available on Centralized Services

Biographical Information This is personal information that does Imports

not change over time, such as date of
birth.

Phone Information Employees can add multiple phone Imports, Editing UI

numbers 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 me- Imports, Editing UI
dia accounts.

Emergency Contacts Employees can add multiple contacts Imports, Editing UI

with their contact data and relationship
information.

National ID Information Employees can add multiple ID types Imports, Editing UI

and their numbers.

Implementing Employee Central Core

192 PUBLIC Entities in Employee Central
Non-Effective-Dated Entities Description Available on Centralized Services

Work Permits Employees can add multiple permit Imports, Editing UI

types, numbers, expiry dates, and at-
tachments.

Employment Information

Effective-Dated Entities Description Available on Centralized Services

Job Information Managers can add, update, or delete Imports, History UI, MSS
job data, time information, and other
information for an employee.

Job Relationships Managers can specify the employer's Imports, History UI, MSS
HR Business Partner, legal advisors,
and others besides the primary man-
ager.

Compensation Managers can change the salary, bo- Imports, History UI, MSS
nus, eligibility for benefits, and other in-
formation.

Recurring Pay Components Managers can add, update, or delete Imports, History UI, MSS
recurring pay components such as for
the base salary or a company car allow-
ance.

Non-Effective-Dated Entities Description Available on Centralized Services

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 Imports, MSS

for an employee.

Non-Recurring Pay Components Managers can add a spot bonus for an Imports, MSS
employee.

Related Information

Centralized Services in Employee Central [page 299]

Data Model Field Information for Employee Central Entities

Implementing Employee Central Core

Entities in Employee Central PUBLIC 193
6.1 Personal and Global Information

Learn more information about the entity Personal Information and Global Information in Employee Central.

Special Characters in Picklists

Special characters are not supported in picklist IDs for Personal Information.

Validations for Telephone Numbers

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.

Behavior with BCUI

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 block 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.

Global Information

If the globalInfo HRIS element is configured in the BCUI or the Succession Data Model (SDM), it is part of
the Personal Information block. 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.

Implementing Employee Central Core

194 PUBLIC Entities in Employee Central
Removing Flags

In the Global Information section of the Personal Information block, the flag of the country/region is displayed
next to the country/region name by default.

For more information, see Hiding Country/Region Flags.

Preventing Deletion of Global Information on Editing UI [page 195]

Prevent users from deleting Global Information on the Editing UI of Personal Information and
Dependents blocks so that the information is available for replication in a Payroll system.

Data Deletion for Certain Person Entities on History UI [page 196]

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.

Forward Propagation of Personal Information and Global Information on History UI [page 199]
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 201]
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 204]
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 block.

Related Information

Implementing Name Formats

Enabling the Adoption of General Display Name

6.1.1 Preventing Deletion of Global Information on Editing UI

Prevent users from deleting Global Information on the Editing UI of Personal Information and Dependents
blocks 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.

Implementing Employee Central Core

Entities in Employee Central PUBLIC 195
Context

The setting is off by default.

Procedure

1. Go to Admin Center Company System and Logo Settings .

2. Select the option Protect global information from deletion.
3. Save your changes.

Results

Users can't save the changes if they perform the following actions on the Editing UI:

• Delete a record of Global Information

• Change the value in the business key field country: this is regarded as deleting the original record.
• Delete a record of Global Information and then add a record for another country or region

Task overview: Personal and Global Information [page 194]

Related Information

Data Deletion for Certain Person Entities on History UI [page 196]

Forward Propagation of Personal Information and Global Information on History UI [page 199]
Forward Propagation of Personal Information and Global Information on Editing UI [page 201]
Record Suppression for Personal Information and Global Information on the UI [page 204]

6.1.2 Data Deletion for Certain Person Entities on History UI

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.

Implementing Employee Central Core

196 PUBLIC Entities in Employee Central
Delete Records in the Earliest Time Period

 Example

Table 4: Existing Records of Addresses for an Employee

Address Type Start Date End Date

Home, Shipping January 1, 2012 December 31, 2013

Home, Billing January 1, 2014 December 31, 9999

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.

Address Type Start Date End Date

Home, Billing January 1, 2014 December 31, 9999

Delete Records in an In-Between Time Period

 Example

Table 5: Existing Records of Addresses for an Employee

Address Type Start Date End Date

Home January 1, 2011 December 31, 2011

Billing January 1, 2012 December 31, 2012

Home January 1, 2013 December 31, 2013

Billing January 1, 2014 December 31, 2016

Home January 1, 2017 December 31, 9999

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.
• No forward propagation occurs.
• The records in previous and later time period are not affected.

Address Type Start Date End Date

Home January 1, 2011 December 31, 2011

Billing January 1, 2012 December 31, 2012

Home January 1, 2013 December 31, 2013

Home January 1, 2017 December 31, 9999

Implementing Employee Central Core

Entities in Employee Central PUBLIC 197
  Example

Table 6: Existing Records of Personal Information and Global Information for an Employee
Personal Information Global Information

Number of Chil-
First Name Last Name Country/Region dren Start Date End Date

Julie Armstrong January 1, 2015 December 31,

2016

Julie Armstrong Australia 1 January 1, 2017 December 31,

2018

Julie Moore Australia 2 January 1, 2019 December 31,

9999

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.

Personal Information Global Information

Number of Chil-
First Name Last Name Country/Region dren Start Date End Date

Julie Armstrong January 1, 2015 December 31,

2018

Julie Moore Australia 2 January 1, 2019 December 31,

9999

Delete Records in the Latest Time Period

Table 7: Existing Records of Addresses for an Employee
Address Type Start Date End Date

Home January 1, 2011 December 31, 2012

Home, Billing January 1, 2013 June 20, 2021

Home, Billing June 21, 2021 December 31, 9999

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.

Address Type Start Date End Date

Home January 1, 2011 December 31, 2012

Home, Billing January 1, 2013 December 31, 9999

Implementing Employee Central Core

198 PUBLIC Entities in Employee Central
Parent topic: Personal and Global Information [page 194]

Related Information

Preventing Deletion of Global Information on Editing UI [page 195]

Forward Propagation of Personal Information and Global Information on History UI [page 199]
Forward Propagation of Personal Information and Global Information on Editing UI [page 201]
Record Suppression for Personal Information and Global Information on the UI [page 204]

6.1.3 Forward Propagation of Personal Information and

Global Information on History UI

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.

Insert Records of Personal Information in the In-Between Time Slice

 Example

Table 8: Existing Sample Personal Information of an Employee

First Name Last Name Start Date End Date

Julie Armstrong January 1, 2015 December 31, 2016

Julie Armstrong January 1, 2017 December 31, 2018

Julie Moore January 1, 2019 December 31, 9999

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".

Implementing Employee Central Core

Entities in Employee Central PUBLIC 199
 First Name Last Name Start Date End Date

Julie Armstrong January 1, 2015 December 31, 2015

Julie Smith January 1, 2016 December 31, 2016

Julie Smith January 1, 2017 December 31, 2018

Julie Moore January 1, 2019 December 31, 9999

Insert Records of Global Information in the In-Between Time Slice

 Example

Table 9: Existing Sample Global Information of an Employee

Country/Region Number of Children Start Date End Date

Australia 0 January 1, 2015 December 31, 2016

Australia 0 January 1, 2017 December 31, 2018

Australia 2 January 1, 2019 December 31, 9999

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".

Country/Region Number of Children Start Date End Date

Australia 0 January 1, 2015 December 31, 2015

Australia 1 January 1, 2016 December 31, 2016

Australia 1 January 1, 2017 December 31, 2018

Australia 2 January 1, 2019 December 31, 9999

Parent topic: Personal and Global Information [page 194]

Related Information

Preventing Deletion of Global Information on Editing UI [page 195]

Data Deletion for Certain Person Entities on History UI [page 196]
Forward Propagation of Personal Information and Global Information on Editing UI [page 201]
Record Suppression for Personal Information and Global Information on the UI [page 204]

Implementing Employee Central Core

200 PUBLIC Entities in Employee Central
6.1.4 Forward Propagation of Personal Information and
Global Information on Editing UI

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.

Edit Records Without Gap

 Example

Table 10: Existing Sample Personal Information and Global Information of an Employee
Personal Information Global Information

Person ID Exter- Number of Chil-

nal Custom String 1 Country/Region dren Start Date End Date

104003 example 1 Australia 0 January 1, 2015 December 31,

2016

104003 example 1 Australia 0 January 1, 2017 December 31,

2018

104003 example 2 Australia 2 January 1, 2019 December 31,

9999

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:

• Update the <Custom String 1> in Personal Information to example 3.

• Update the <Number of Children> in Global Information to 1.

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.

Implementing Employee Central Core

Entities in Employee Central PUBLIC 201
 Table 11: Sample Personal Information and Global Information of an Employee
Personal Information Global Information

Person ID Exter- Number of Chil-

nal Custom String 1 Country/Region dren Start Date End Date

104003 example 1 Australia 0 January 1, 2015 December 31,

2015

104003 example 3 Australia 1 January 1, 2016 December 31,

2016

104003 example 3 Australia 1 January 1, 2017 December 31,

2018

104003 example 2 Australia 2 January 1, 2019 December 31,

9999

 Example

Table 12: Existing Sample Personal Information and Global Information of an Employee
Personal Information Global Information

Person ID Exter- Number of Chil-

nal Custom String 1 Country/Region dren Start Date End Date

104003 example 1 Australia January 1, 2015 December 31,

2016

104003 example 1 Australia January 1, 2017 December 31,

9999

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.

Table 13: Sample Personal Information and Global Information of an Employee

Personal Information Global Information

Person ID Exter- Number of Chil-

nal Custom String 1 Country/Region dren Start Date End Date

104003 example 1 Australia 1 January 1, 2015 December 31,

2016

104003 example 1 Australia 1 January 1, 2017 December 31,

9999

Implementing Employee Central Core

202 PUBLIC Entities in Employee Central
Edit Records of Global Information with Gap

 Example

Table 14: Existing Sample Personal Information and Global Information of an Employee
Personal Information Global Information

Person ID Exter- Number of Chil-

nal Custom String 1 Country/Region dren Start Date End Date

104003 example 1 Australia January 1, 2015 December 31,

2016

104003 example 1 January 1, 2017 December 31,

2018

104003 example 2 Australia 2 January 1, 2019 December 31,

9999

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.

Table 15: Sample Personal Information and Global Information of an Employee

Personal Information Global Information

Person ID Exter- Number of Chil-

nal Custom String 1 Country/Region dren Start Date End Date

104003 example 1 Australia January 1, 2015 December 31,

2015

104003 example 1 Australia 1 January 1, 2016 December 31,

2016

104003 example 1 January 1, 2017 December 31,

2018

104003 example 2 Australia 2 January 1, 2019 December 31,

9999

Parent topic: Personal and Global Information [page 194]

Related Information

Preventing Deletion of Global Information on Editing UI [page 195]

Data Deletion for Certain Person Entities on History UI [page 196]

Implementing Employee Central Core

Entities in Employee Central PUBLIC 203
Forward Propagation of Personal Information and Global Information on History UI [page 199]
Record Suppression for Personal Information and Global Information on the UI [page 204]

6.1.5 Record Suppression for Personal Information and

Global Information on the UI

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
block.

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.

Parent topic: Personal and Global Information [page 194]

Related Information

Preventing Deletion of Global Information on Editing UI [page 195]

Data Deletion for Certain Person Entities on History UI [page 196]
Forward Propagation of Personal Information and Global Information on History UI [page 199]
Forward Propagation of Personal Information and Global Information on Editing UI [page 201]

Implementing Employee Central Core

204 PUBLIC Entities in Employee Central
6.2 Addresses

Here is a little more information about Addresses in Employee Central.

Country/Region-Specific Address Format

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.

Time Gap in Addresses

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 block 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 block 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.

Rules for Addresses

onInit and onView rules do not work with homeAddress.

Forward Propagation of Addresses on History UI [page 206]

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.

Forward Propagation of Addresses on Editing UI [page 208]

Forward propagation is supported on the Editing UI of addresses when you add or edit a record.

Preventing Deletion of a Type of Addresses [page 211]

Implementing Employee Central Core

Entities in Employee Central PUBLIC 205
 You can prevent users from deleting a certain type of addresses on the Editing UI of Addresses block so
that the addresses are available for replication in a Payroll system.

6.2.1 Forward Propagation of Addresses on History UI

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.

Insert Records in the Earliest Time Period

 Example

Table 16: Existing Records of Addresses for an Employee

Address Type Postal Code Start Date End Date

Billing 10000 January 1, 2020 December 31, 2020

Billing 10000 January 1, 2021 December 31, 9999

Home 20000 January 1, 2021 December 31, 9999

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.

Records of other address types are not affected.

Address Type Postal Code Start Date End Date

Home 30000 January 1, 1999 December 31, 2019

Home 30000 January 1, 2020 December 31, 2020

Billing 10000 January 1, 2020 December 31, 2020

Billing 10000 January 1, 2021 December 31, 9999

Home 20000 January 1, 2021 December 31, 9999

Implementing Employee Central Core

206 PUBLIC Entities in Employee Central
Insert Records in the In-Between Time Period Without Gap

 Example

Table 17: Existing Records of Addresses for an Employee

Address Type Postal Code Start Date End Date

Billing 10000 January 1, 1999 December 31, 2019

Billing 10000 January 1, 2020 December 31, 2020

Billing January 1, 2021 December 31, 9999

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".

Address Type Postal Code Start Date End Date

Billing 10000 January 1, 1999 December 31, 2019

Billing 10000 January 1, 2020 April 30, 2020

Billing 20000 May 1, 2020 December 31, 2020

Billing January 1, 2021 December 31, 9999

Insert Records in the In-Between Time Period with Gap

 Example

Table 18: Existing Records of Addresses for an Employee

Address Type Postal Code Start Date End Date

Billing 10000 January 1, 1999 December 31, 2019

Billing 10000 January 1, 2020 December 31, 2020

Billing 20000 May 1, 2021 December 31, 9999

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.

Implementing Employee Central Core

Entities in Employee Central PUBLIC 207
 Address Type Postal Code Start Date End Date

Billing 10000 January 1, 1999 December 31, 2019

Billing 10000 January 1, 2020 April 30, 2020

Billing 30000 May 1, 2020 December 31, 2020

Billing 20000 May 1, 2021 December 31, 9999

Parent topic: Addresses [page 205]

Related Information

Forward Propagation of Addresses on Editing UI [page 208]

Preventing Deletion of a Type of Addresses [page 211]

6.2.2 Forward Propagation of Addresses on Editing UI

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.

Add a Record Before the Earliest Start Date

 Example

Table 19: Existing Sample Addresses of an Employee

Address Type Postal Code Start Date End Date

Billing 10000 January 1, 2020 December 31, 2020

Billing 10000 January 1, 2021 December 31, 9999

Home January 1, 2021 December 31, 9999

You set the start date as January 1, 1999 and do the following changes:

Implementing Employee Central Core

208 PUBLIC Entities in Employee Central
 • Add a home address
• Set its postal code as 30000

Result:

The new record of home address is forward propagated.

Records of other address types are not affected.

Address Type Postal Code Start Date End Date

Home 30000 January 1, 1999 December 31, 2019

Home 30000 January 1, 2020 December 31, 2020

Billing 10000 January 1, 2020 December 31, 2020

Billing 10000 January 1, 2021 December 31, 9999

Home 30000 January 1, 2021 December 31, 9999

Edit Records Without Gap

 Example

Table 20: Existing Sample Addresses of an Employee

Address Type Postal Code Start Date End Date

Billing 10000 January 1, 1999 December 31, 2019

Billing 10000 January 1, 2020 December 31, 2020

Billing 10000 January 1, 2021 December 31, 9999

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 updated field value "20000" is forward propagated.

Address Type Postal Code Start Date End Date

Billing 10000 January 1, 1999 December 31, 2019

Billing 10000 January 1, 2020 April 30, 2020

Billing 20000 May 1, 2020 December 31, 2020

Billing 20000 January 1, 2021 December 31, 9999

Implementing Employee Central Core

Entities in Employee Central PUBLIC 209
  Example

Table 21: Existing Sample Addresses of an Employee

Address Type Postal Code Start Date End Date

Billing 10000 January 1, 1999 December 31, 2019

Billing 10000 January 1, 2020 December 31, 2020

Billing 10000 January 1, 2021 December 31, 9999

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:

The updated field value "20000" is forward propagated.

Address Type Postal Code Start Date End Date

Billing 20000 January 1, 1999 December 31, 2019

Billing 20000 January 1, 2020 December 31, 2020

Billing 20000 January 1, 2021 December 31, 9999

Edit Records with Gap

 Example

Table 22: Existing Sample Addresses of an Employee

Address Type Postal Code Start Date End Date

Billing 10000 January 1, 1999 December 31, 2019

Billing 10000 January 1, 2020 December 31, 2020

Billing 10000 May 1, 2021 December 31, 9999

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.

Address Type Postal Code Start Date End Date

Billing 10000 January 1, 1999 December 31, 2019

Implementing Employee Central Core

210 PUBLIC Entities in Employee Central
 Address Type Postal Code Start Date End Date

Billing 10000 January 1, 2020 April 30, 2020

Billing 30000 May 1, 2020 December 31, 2020

Billing 10000 May 1, 2021 December 31, 9999

Parent topic: Addresses [page 205]

Related Information

Forward Propagation of Addresses on History UI [page 206]

Preventing Deletion of a Type of Addresses [page 211]

6.2.3 Preventing Deletion of a Type of Addresses

You can prevent users from deleting a certain type of addresses on the Editing UI of Addresses block 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

This validation is for the UI only and doesn't support imports.

Procedure

1. Go to Admin Center Company System and Logo Settings .

2. Under the option Protect address from deletion, select an address type that can't be deleted.
3. Save your changes.

Implementing Employee Central Core

Entities in Employee Central PUBLIC 211
Task overview: Addresses [page 205]

Related Information

Forward Propagation of Addresses on History UI [page 206]

Forward Propagation of Addresses on Editing UI [page 208]

6.3 Permissions for Personal Information and Addresses

Blocks

Learn how to set entity-level permissions for the People Profile blocks Personal Information, Global
Information, and Addresses in different scenarios.

You can find permissions that control the access to the Personal Information and Addresses blocks in User
Permissions Employee Central Effective Dated Entities .

Table 23: Required Permissions in Common Scenarios

Scenario Required Permission Result

Employees and admins view records. In the line Personal Information Actions No icon is displayed in the blocks.
or Address Information Actions:
Users can view current records.
The View Current permission

In the line Personal Information Actions

Only the icon  (History) for History UI
or Address Information Actions:
is displayed in the block.
• The View Current permission
Users can view current records and the
• The View History permission
change history on the History UI.

Employees update their records on the In the line Personal Information Actions
The icons  (Edit) for Editing UI and
Editing UI and view the change history. or Address Information Actions:
 (History) for History UI are both dis-
• The View Current permission played in the block.
• The View History permission
Users can do the following:
In the line Edit Link:
• View current records
• The Edit/Insert permission • Update a record on the Editing UI
• The View Current permission • View the change history on the His-
• The View History permission tory UI

Implementing Employee Central Core

212 PUBLIC Entities in Employee Central
Scenario Required Permission Result

Admins update the change history. In the line Personal Information Actions
Only the icon  (History) for History UI
or Address Information Actions
is displayed in the block.
• The Edit/Insert permission
Users can do the following:
• The View Current permission
• View current records
• The View History permission
• View the change history on the His-
tory UI
• Choose the Insert New Record but-
ton on the History UI to add a his-
tory record

In the line Personal Information Actions

Only the icon  (History) for History UI
or Address Information Actions:
is displayed in the block.
• The Correct permission
Users can do the following:
• The View Current permission
• View current records
• The View History permission
• View the change history on the His-
tory UI
• Choose the Edit button on the His-
tory UI to edit existing history re-
cords

In the line Personal Information Actions

Only the icon  (History) for History UI
or Address Information Actions:
is displayed in the block.
• The Delete permission
Users can do the following:
• The View Current permission
• View current records
• The View History permission
• View the change history on the His-
tory UI
• Choose the Delete button on the
History UI to delete a history re-
cord

6.4 Emergency Contact

Here is more information about Emergency Contact in Employee Central.

Mandatory Fields

The <relationship> and <name> fields are business keys for Emergency Contact, and must be enabled.

Implementing Employee Central Core

Entities in Employee Central PUBLIC 213
Duplicate Emergency Contacts

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 block, see
Emergency Contact.

Enabling Mandatory Field Validation for Emergency Contacts [page 214]

Enable validation of all mandatory fields in the Emergency Contact block.

6.4.1 Enabling Mandatory Field Validation for Emergency

Contacts

Enable validation of all mandatory fields in the Emergency Contact block.

Context

By default, mandatory field validation covers no more than the following fields for emergency contacts,
depending on your field configuration:

• <relationship>
• <name>
• <phone>
• <primary_flag>
• <email>

However, you can extend the validation to cover all mandatory fields in the details section of the Emergency
Contact block.

Procedure

1. Go to Admin Center Company System and Logo Settings .

2. Select Enable validations for mandatory fields in the Emergency Contact's details section.
3. Save your changes.

Task overview: Emergency Contact [page 213]

Implementing Employee Central Core

214 PUBLIC Entities in Employee Central
6.5 National ID

Here is a little more information about National ID in Employee Central.

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.

Related Information

Using Temporary National ID While Hiring an Employee

6.6 Work Permits

Here is a little more information about Work Permit in Employee Central.

Editing Work Permits

When entering or editing work permit information on the Work Permit block, 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.

Requirements on Data Entry

These four fields on the UI are mandatory and must not be left empty.

Data Validation

Business key-based 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

Implementing Employee Central Core

Entities in Employee Central PUBLIC 215
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.

 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.

Validation of Unchanged Records

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:

Table 24: Sample Work Permit Records

Document Document Why Non-
Record User ID Country Type Number Issue Date Compliant

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.

Useful Checks to Find Invalid Data

The following two checks are available in Check Tool Employee Central Core Employee Central Core :

• WPWithDuplicateBusinessKeys: Use to find records that have duplicate business keys.

• WPWithEmptyBusinessKeys: Use to find records that have empty business keys.

Approving Workflows When Involved Work Permit Record Not Existing

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.

Implementing Employee Central Core

216 PUBLIC Entities in Employee Central
Employment-Based or Person-Based

The Work Permit block 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 block 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 block, people can view work permit records related to all their employments after logging into any
account corresponding to those employments.

6.7 Enabling Email Address Validation

Enable email address validation in Employee Central so that the format of email addresses is validated
whenever you manually add or import email addresses into the system.

Prerequisites

You have permission to access the admin tool Company System and Logo Settings.

Context

After you enable email address validation, the email addresses you added are validated against the RFC 822
standards, some of which are as follows:

• The format of an email address is someone@example.com.

• The email prefix "someone" can include:
• Uppercase and lowercase Latin letters: A to Z or a to z
• Digits: from 0 to 9
• Printable characters: !#$%&'*+-/=?^_`{|}~
• Dot (.)
• The "someone" part can't include characters with special usage in URLs, such as square brackets ([ ]).
• The "example" part can include:
• Uppercase and lowercase Latin letters: A to Z or a to z
• Digits: from 0 to 9
• Dot (.)
• Hyphen (-)
• Underscore (_)
• The "com" part can only include uppercase or lowercase Latin letters.

Implementing Employee Central Core

Entities in Employee Central PUBLIC 217
Procedure

1. Go to Admin Center Company System and Logo Settings .

2. Select the Activate Email Validation in scorecard option.
3. Save your changes.

6.8 Enabling Attachments for Personal Information Entities

Enable attachments for a personal information 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:

• Personal Information: personalInfo

• Global Information: globalInfo
• Biographical Information: personInfo
• National ID: nationalIdCard
• Addresses: homeAddress
• Dependents: personRelationshipInfo
• Work Permits: workPermitInfo

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

1. Go to the Admin Center Manage Business Configuration .

2. Select an HRIS element under Employee Central.
3. Enable the attachment-id field for the element.
4. Save your settings.

Next Steps

Grant appropriate role-based permissions of the attachment-id field.

Implementing Employee Central Core

218 PUBLIC Entities in Employee Central
6.9 Employment Information

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.

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..

For more information about the supported person types and the overall concept, refer to the Setting Up and
Using Business Configuration UI (BCUI) guide on the SAP Help Portal.

6.9.1 Business Rules for Employment Details

Business rules for employment-related entities on Centralized services differ from legacy behavior.

• Business rules
• We do not recommend making any changes to the hire date or employment end date using rules. It is
technically possible, but may cause data inconsistencies.

Implementing Employee Central Core

Entities in Employee Central PUBLIC 219
• Cross-entity rules
• Employment Information as Source Element
For active users, cross-entity rules with Employment Information as the source element and
Job Information, Compensation Information, Recurring Pay Components, Non-Recurring Pay
Components, or Job Relationships as the target element are no longer supported.
For inactive or terminated users, cross-entity rules triggered from changes made using the icon
 (Edit)in the Profile page are supported from Employment Information as the source element to
Job Information as the target element using the Cross-Entity Rules or Basic rule scenario.
Cross-entity rules where Employment Information is the source element with Job Information,
Compensation Information, Recurring Pay Components, Non-Recurring Pay Components, or Job
Relationships as the target element are possible only from changes made in Take Action.
• Job Information as Source Element
For inactive or terminated users, onSave cross-entity rules where Job Information is the source
element with Employment Information, Compensation Information, Recurring Pay Components, Non-
Recurring Pay Components, or Job Relationships as the target element are only supported using the
Cross-Entity Rules rule scenario.

These rules are triggered from changes made using the icon  (Edit)in the Profile page.

Rule Event Types

For business rules based on Job Information ( triggered in the Employment Details UI of a terminated user), the
following rule event types are supported:

• OnView: Always triggered

• OnChange: Triggered only if a Job Information field is changed
• onSave: Triggered only if a Job Information field is changed
• onPostSave: Triggered only if a Job Information field is changed

Related Information

Cross-Entity Rules with Centralized Services

Implementing Employee Central Core

220 PUBLIC Entities in Employee Central
6.9.2 System Behavior for Editing UI of Employment Details

With Centralized services enabled, data validations are enhanced to improve data quality.

Changing Employment Details

When you edit a termination record and only change employment details, the system saves the changes only
for the employment details. There is no change to the Job Information record. This also means that no rules
with Job Information as the base object are triggered since there are no changes to Job Information.

Workflow Handling

• Workflow Triggers
If there are changes for both Employment Information and Job Information fields, the Employment
Information workflow configuration is used by the system to trigger the workflow. If no Employment
Information workflow configuration is found, then the system checks whether a Job Information workflow
configuration exists and uses that configuration to trigger the workflow. If only fields from Employment
Information are changed, then the system uses the Employment Information workflow configuration to
trigger the workflow. If only fields from Job Information are changed, then the system uses the Job
Information workflow configuration to trigger the workflow.
• Workflow Approvals, Updates, Resubmit
For a user with a terminated employment, the following Job Information fields are now displayed in the
workflow approval:
• Event reason
• Notes
• Attachments
If a user makes change to the above fields, once the workflow is approved, the Job Information record is
updated with all the changes (for Employment Information and Job Information fields).

6.10 Job Information

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

Implementing Employee Central Core

Entities in Employee Central PUBLIC 221
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 Take 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.

It is available in the Manager Self-Service scenario.

Rule contexts, events, and field-level permissions are supported.

Expected Return Date

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.

Job Code Propagation

You can propagate job code values to the Job Information block 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:

• Data Type: Generic Object

• Valid Values Source: Work Schedule

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 block.

You must then update the Work Schedule values for the different job codes in the Manage Data Job
Classification screen.

Implementing Employee Central Core

222 PUBLIC Entities in Employee Central
Position to Job Information Sync

You can sync field values from position management to Job Information using business rules.

For more information, refer to Define Synchronization Position to JobInformation.

Notes and Attachments

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

Events in Employee Central [page 125]

Manager Self-Service (MSS) [page 278]
Manager Self-Service (MSS) Supported on Centralized Services [page 309]
Job Information
Entry Dates and TimeIn Calculation for Job Information

Implementing Employee Central Core

Entities in Employee Central PUBLIC 223
6.10.1 Data Validation for Job Information (MSS and History
UI)

With Centralized services enabled, data validations are enhanced to improve data quality.

Data Validation for Job History UI

Job Information History is validated for the following scenarios:

• 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.
• 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.

Data Validation for Job Information MSS

Job Information MSS is validated for the following scenarios:

• 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.
• To ensure that working days for each week is greater than or equal to 0, or less than or equal to 7.

Implementing Employee Central Core

224 PUBLIC Entities in Employee Central
• 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.

System Handling with Deleted Termination Records

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 Main Employment ID
• End Date
• Benefits End Date
• Payroll End Date
• Last Date Worked
• Bonus Pay Expiration Date
• Salary End Date
• Stock End Date

Position Management Validations

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.

• Position Status Validation: Employees can be assigned to only active positions.

• Multiple Incumbents Validation: This validation verifies that you allow multiple incumbents for the position.
• Full-Time Equivalent (FTE) Validation: This validation depends on whether the position is subject to
position control, as well as the FTE value.

Related Information

Changing an Employee's Hire Date in Employee Central

Validations in Position Management

Implementing Employee Central Core

Entities in Employee Central PUBLIC 225
6.10.2 Forward Propagation in Job 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 and does not stop at any gap. Field
forward propagation, however, stops at any gap between two existing records.

Forward propagation is supported for the following:

• MDF Objects

 Note

Forward propagation is NOT supported for custom MDF objects.

• Job Information
• Job Relationships

 Note

Rules are not triggered for propagated records.

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.

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.

Implementing Employee Central Core

226 PUBLIC Entities in Employee Central
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.

Job Information

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.

Changes to Job Information are propagated when:

• Changes are made in the MSS screen

• Changes are made using Insert New Record on the Job Information History screen

Changes to Job Information are NOT propagated when:

• Corrections are done in the Job Information History screen

• Job history records are deleted in the Job Information History screen, except for special fields such as
the employment status, for instance in case a Job Information termination record is deleted, we forward
propagate the employment status from the previous record to future records.

Related Information

Forward Propagation of Personal Information and Global Information on History UI [page 199]
Forward Propagation of Addresses on History UI [page 206]
Forward Propagation of Addresses on Editing UI [page 208]
Forward Propagation of Personal Information and Global Information on Editing UI [page 201]
Forward Propagation of Data with Imports
Forward Propagation in Employee Central Compensation Information

6.10.2.1 Fields Not Propagated in Job Information

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.

If the criteria for forward propagation is met, then the data is forward propagated. Updated records include
updated last modified information.

Here is some additional information about the fields that are not forward propagated for Job Information. This
means, that a change to these fields is not made to future records.

Implementing Employee Central Core

Entities in Employee Central PUBLIC 227
HRIS Entity HRIS Field

Job Information action-id

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

Implementing Employee Central Core

228 PUBLIC Entities in Employee Central
6.10.3 Calculating FTE

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 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.

Implementing Employee Central Core

Entities in Employee Central PUBLIC 229
Procedure

Using the Data Model (Only for FTE=0 Cases)

1. Import the Succession Data Model (SDM) XML to first set the <jobInfo.standard-hours> field
visibility to None.
2. Save your changes.
3. Import the SDM XML again to remove the field from the XML entirely.
4. Save your changes.
5. Once the standard-hours field is removed entirely from the XML, add a custom decimal field (custom-
double) field to jobInfo and use this as your field for Standard Hours instead.
6. Create a new business rule that 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.
Using the Business Configuration UI (Only for FTE=0 Cases)
7. Alternatively, you can make the changes to the configuration using the Business Configuration UI. Go to
Admin Center Manage Business Configuration .

8. Select Employee Central jobInfo .

9. For the <standard-hours> field, set the Enabled field to No.
10. Save your changes and refresh the page.

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.

Implementing Employee Central Core

230 PUBLIC Entities in Employee Central
6.11 Job Relationships

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 or using the Manager Self-Service (MSS) action.

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.

Implementing Employee Central Core

Entities in Employee Central PUBLIC 231
Here is the list of possible relationships:

• 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.

Existing customers can manually add the new job relationship types to their picklist and re-import it to have the
new job relationships in the system.

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

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.

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.

For more information about delegation, refer to Delegate Relationship Assignments.

Target Groups for Workers

Fields of the type Worker (for example, supervisor in Job Information or HR/matrix manager in Job
Relationship, and so on) now 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.

6.11.1 Data Validation for Job Relationships (MSS and History

UI)

With Centralized services enabled, data validations are enhanced to improve data quality.

Job Relationships is validated for the following scenarios:

Implementing Employee Central Core

232 PUBLIC Entities in Employee Central
• 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.

6.11.2 Forward Propagation in Job Relationships

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 is supported for the following:

• MDF Objects

 Note

Forward propagation is NOT supported for custom MDF objects.

• Job Information
• Job Relationships

 Note

Rules are not triggered for propagated records.

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.

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

Implementing Employee Central Core

Entities in Employee Central PUBLIC 233
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.

Job Relationships

Forward propagation for Job Relationships is on by default in the system and cannot be switched off.

Changes to Job Relationship Information are propagated when:

• Changes are made in the MSS screen

• Changes are made using Insert New Record on the Job Relationships History screen
• Changes are made to name or relationship type

Changes to Job Relationship Information are NOT propagated when:

• Corrections are done in the Job Relationships History screen

• Job relationship records are deleted in the Job Relationships History screen

6.11.2.1 Fields Not Propagated in Job Relationships

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.

If the criteria for forward propagation is met, then the data is forward propagated. Updated records include
updated last modified information.

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.

HRIS Entity HRIS Field

Job Relationships action-id

allow-delete

Implementing Employee Central Core

234 PUBLIC Entities in Employee Central
HRIS Entity HRIS Field

created-on

created-by

end-date

item-id

last-modified-on

last-modified-by

start-date

wfConfig

6.12 Last Updated by Source Details in History UIs

The "last updated" by source information is now 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.

For records saved using a process enabled on Centralized services, the system now 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 saved using Centralized services:

• 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.

Implementing Employee Central Core

Entities in Employee Central PUBLIC 235
7 Human Resource Information System
(HRIS) Synchronization

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.

Process of HRIS Sync

The following diagram demonstrates how data is synchronized from Employee Central to Platform user data
and then consumed by other SAP SuccessFactors products.

Implementing Employee Central Core

236 PUBLIC Human Resource Information System (HRIS) Synchronization
• HRIS Sync Mappings [page 240]
• Triggering HRIS Sync [page 238]

Why HRIS Sync?

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.

Triggering HRIS Sync [page 238]

HRIS Sync can be triggered automatically by certain actions taken on the UI, or it can be kicked off due
to a scheduled job.

HRIS Sync Mappings [page 240]

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.

Hard-Coded HRIS Sync Mappings [page 240]

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 237
 The system synchronizes some Employee Central data based on the hard-coded sync mappings from
HRIS fields to standard and userinfo elements.

Custom HRIS Sync Mappings [page 244]

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.

Special Handling for Syncing Fields [page 264]

Here is some further information about syncing field values.

Picklist Configuration for Employee Status and Job Relationship Type [page 266]
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 Jobs [page 268]

You can create, manage, and monitor scheduled jobs for HRIS Sync using Scheduled Job Manager in
the Admin Center.

7.1 Triggering HRIS Sync

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 can be triggered by any of the following ways:

Real-Time HRIS Sync Due to UI Operations

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.

This method doesn't require or trigger an HRIS Sync job.

Implementing Employee Central Core

238 PUBLIC Human Resource Information System (HRIS) Synchronization
Scheduled HRIS Sync Jobs

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.

Employee Central Data Import or API Operations

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 236]

Related Information

HRIS Sync Mappings [page 240]

Hard-Coded HRIS Sync Mappings [page 240]
Custom HRIS Sync Mappings [page 244]
Special Handling for Syncing Fields [page 264]
Picklist Configuration for Employee Status and Job Relationship Type [page 266]
HRIS Sync Jobs [page 268]
Effective Dating [page 62]

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 239
7.2 HRIS Sync Mappings

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 236]

Related Information

Triggering HRIS Sync [page 238]

Hard-Coded HRIS Sync Mappings [page 240]
Custom HRIS Sync Mappings [page 244]
Special Handling for Syncing Fields [page 264]
Picklist Configuration for Employee Status and Job Relationship Type [page 266]
HRIS Sync Jobs [page 268]

7.3 Hard-Coded HRIS Sync Mappings

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.

Fields Hard-Coded for Syncing [page 241]

Learn hard-coded sync mappings in the Succession Data Model.

Parent topic: Human Resource Information System (HRIS) Synchronization [page 236]

Implementing Employee Central Core

240 PUBLIC Human Resource Information System (HRIS) Synchronization
Related Information

Triggering HRIS Sync [page 238]

HRIS Sync Mappings [page 240]
Custom HRIS Sync Mappings [page 244]
Special Handling for Syncing Fields [page 264]
Picklist Configuration for Employee Status and Job Relationship Type [page 266]
HRIS Sync Jobs [page 268]
Configurable Sync Mappings [page 245]
Rules for Configuring HRIS Sync Mappings [page 252]

7.3.1 Fields Hard-Coded for Syncing

Learn hard-coded sync mappings in the Succession Data Model.

 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.

HRIS Element HRIS Field Standard Element More Information

Phone Information country-code homePhone The phone-type field of

(phoneInfo) the phoneInfo element
area-code
allows you to define the
type of phone number being
phone-number
stored. To sync phoneInfo
extension records correctly, make sure
that the pre-delivered picklist
country-code cellPhone ecPhoneType is already
assigned to the phone-
area-code
type field. The external
code of options are H, B, C,
phone-number
and F.
extension When phone number
is synchronized, four
country-code businessPhone
fields countryCode,

area-code areaCode,
phoneNumber, and
phone-number extension are merged
into one value and synced
extension
to the mapped standard el-
ement, for example, (086)
country-code fax

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 241
HRIS Element HRIS Field Standard Element More Information

area-code 021 21345501x0619. Cus-

tomizing the hard-coded
phone-number sync mapping only changes
the target field but not the
extension
format.

Email (emailInfo) email-address email Only business email is

synced in hard-coded sync.
The external code of the
picklist option for business
email is B.

Employment Information start-date hireDate

(employmentInfo)
end-date companyExitDate This is not hard-coded. For
more information, see Sync-
ing the Termination Date Be-
tween Employee Central and
Standard User Fields [page
262].

assignmentIdExternal assignmentIdExternal The data is synced even if the

field is not configured in the
Succession Data Model.

User(Internal) is Active if
EMPLOYMENT_STATUS is
Active, Paid Leave, Unpaid
Leave, or Suspended. Else,
the user is Inactive. External
user's status will not be up-
dated.

Job Relationships rel-user-id hrId An employee can have multi-

(jobRelationsInfo) ple job relationships, for ex-
(picklist external_code - hr
ample, three active matrix
manager)
managers. In such cases,

rel-user-id matrixManager the job relationships are

synchronized to user data ta-
(picklist external_code - ma- bles in the ascending order
trix manager)
of RELATIONSHIP_TYPE
(the option ID of the
rel-user-id secondManager
JobRelationships pick-
(picklist external_code - sec- list). For more information
ond manager) about the picklist, see Pick-
list Configuration for Em-
rel-user-id customManager
ployee Status and Job Rela-
(picklist external_code - cus- tionship Type [page 266].
tom manager)

Implementing Employee Central Core

242 PUBLIC Human Resource Information System (HRIS) Synchronization
HRIS Element HRIS Field Standard Element More Information

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)

Job Information (jobInfo) job-code jobCode The HRIS field

emplStatus data is
job-title title synced to the standard ele-
ment status even if the
department department
field is not configured in

division division the Succession Data Model.

For the sync to work,
location location you must define the field
emplStatus as a picklist.
emplStatus status
For more information, see
manager-id manager-id Picklist Configuration for Em-

timezone timeZone ployee Status and Job Rela-

tionship Type [page 266].

Corporate Address address1 addressLine1 This element is derived

(corporateAddress) from the foundation ob-
address2 addressLine2 ject Location. The Loca-
tion values determine the
address3 addressLine3
corporateAddress that
is synchronized to Employee
city city
Profile.
state state Only when the Location value
changes, does the element
zip-code zipCode
corporateAddress is
country country synchronized.

 Remember
To ensure consistent
sync of Corporate Ad-
dresses for all countries
and regions, follow this
hard-coded mapping for
country/region-specific
configurations as well.

Personal Information first-name firstName The only gender values that

(personalInfo) can be synchronized from

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 243
HRIS Element HRIS Field Standard Element More Information

last-name lastName the HRIS field gender are

"Male" and "Female". Other
middle-name mi gender values, such as "Un-
known", are set to null in
salutation salutation
Platform user data.

suffix suffix The only values that can be

synchronized from the HRIS
gender gender
field marital-status are
"Yes" and "No". The value No
marital-status married
Selection is synchronized as
title title "None" to Platform user data.

Compensation Information job-level jobLevel Don't enable the Employee

Central fields pay-grade
(compInfo)
pay-grade (Deprecated) payGrade and bonus-target. These
fields are deprecated and the
bonus-target (Deprecated) bonusTarget mappings are obsolete.

Biographical Information date-of-birth dateOfBirth This field is only synced when

(personInfo) it is configured in personInfo
or personalInfo.

Parent topic: Hard-Coded HRIS Sync Mappings [page 240]

7.4 Custom HRIS Sync Mappings

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.

 Remember

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.

Configurable Sync Mappings [page 245]

Learn about the HRIS elements that can be customized in HRIS Sync mappings and the conditions
around their sync logic.

Implementing Employee Central Core

244 PUBLIC Human Resource Information System (HRIS) Synchronization
 Rules for Configuring HRIS Sync Mappings [page 252]
When configuring your HRIS Sync mappings in the Succession Data Model, keep these points in mind.

Configuring HRIS Sync Mappings in Business Configuration UI [page 257]

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.

Configuring HRIS Sync Mappings in the Succession Data Model XML [page 260]
Edit the Succession Data Model XML from Provisioning to configure HRIS Sync mappings to your
organization's needs.

Syncing the Termination Date Between Employee Central and Standard User Fields [page 262]
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 236]

Related Information

Triggering HRIS Sync [page 238]

HRIS Sync Mappings [page 240]
Hard-Coded HRIS Sync Mappings [page 240]
Special Handling for Syncing Fields [page 264]
Picklist Configuration for Employee Status and Job Relationship Type [page 266]
HRIS Sync Jobs [page 268]

7.4.1 Configurable Sync Mappings

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
• userId
• jobCode
• hireDate

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 245
Table 25:

HRIS Element Included in Hard-Coded Support Full Sync or Delta More Information
Sync Mappings Sync

Email (emailInfo) Partly Full Based on hard-coded

sync mappings, only busi-
ness email information is
synchronized.

If you want to customize

the mapping, you must make
sure that each type of email
is mapped. To specify the
type of email in the mapping,
set the entity-type at-
tribute. The entity type val-
ues are based on the exter-
nal codes from a predelivered
picklist ecEmailType.

In custom sync mappings,

the last modified email infor-
mation is synced.

 Recommenda-
tion
We recommend that
you map personal email
and business email to
different Employee Pro-
file fields. If both email
types are mapped to
the standard element
email, the last modi-
fied record is synced.

Phone Information Yes Full If you want to customize

(phoneInfo) the mapping, you must make
sure that each type of phone
information is mapped. To
specify the type of phone
information in the mapping,
set the entity-type at-
tribute. The entity type val-
ues are based on the exter-
nal codes from a predelivered
picklist ecPhoneType.

Implementing Employee Central Core

246 PUBLIC Human Resource Information System (HRIS) Synchronization
HRIS Element Included in Hard-Coded Support Full Sync or Delta More Information
Sync Mappings Sync

Addresses (homeAddress) No Delta To specify which type of ad-

dresses for HRIS Sync, set
the entity-type attribute
in the homeAddress map-
ping. The <isPrimary> flag
is not considered by the HRIS
sync.

 Recommenda-
tion
To avoid data in-
consistencies, we rec-
ommend that you
map homeAddress
data to User Info ele-
ments and don't over-
ride the hard-coded
corporateAddress
mapping with the
homeAddress map-
ping.

If the target field

you defined for the
homeAddress map-
ping is also used
in the hard-coded
corporateAddress
mapping, the
homeAddress map-
ping overwrites.

Personal Information Yes Delta To avoid unexpected down-

(personalInfo) stream impacts, you're not
recommended to override
hard-coded mappings for
name-related fields and the
HRIS field gender.

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 247
HRIS Element Included in Hard-Coded Support Full Sync or Delta More Information
Sync Mappings Sync

Biographical Information Yes Full Don't map the field

(personInfo) person-id-external to
the field empId if you con-
figured sm-mappings in the
Candidate Profile Template
for the same.

Implementing Employee Central Core

248 PUBLIC Human Resource Information System (HRIS) Synchronization
HRIS Element Included in Hard-Coded Support Full Sync or Delta More Information
Sync Mappings Sync

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
countryOfRegistr
ation field in the Legal
Entity.

 Note
Don't override the hard-
coded mapping from the
HRIS field manager-
id to the standard ele-
ment manager-id.

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 249
HRIS Element Included in Hard-Coded Support Full Sync or Delta More Information
Sync Mappings Sync

Direct manager change is

synchronized when the job
records are synchronized.

Compensation Information Yes Delta You need to override the

mapping for the field pay-
(compInfo)
grade because this field is
now in Job Information.

Employment Information Yes Full

(employmentInfo)

Social Accounts (imInfo) No Full

National ID Information No Full

(nationalIdCard)

Implementing Employee Central Core

250 PUBLIC Human Resource Information System (HRIS) Synchronization
HRIS Element Included in Hard-Coded Support Full Sync or Delta More Information
Sync Mappings Sync

Work Permit No Full You can map a Work Permit

(workPermitInfo) field to any standard custom
field or a custom User Info
field.

The HRIS sync of Work Per-

mit information is only trig-
gered by real-time UI opera-
tions.

 Remember
• If there're multiple
records of work per-
mits, for example,
work permits of
several document
types, only the last
modified record is
synchronized via
HRIS Sync.
• If there're multiple
last modified re-
cords, then the re-
cord with the lat-
est issue date is
synchronized.

 Note
Don't set any value
for the entity-type
attribute in the HRIS
Sync mapping because
this attribute is irrel-
evant and will be
automatically set as
WorkEligibility.
So you can't use this
attribute to sync data
for a specific document
type. The system maps
a source field to a target
field regardless of docu-
ment types.

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 251
HRIS Element Included in Hard-Coded Support Full Sync or Delta More Information
Sync Mappings Sync

globalInfo, payComponen- No These entities support sync

tRecurring, payComponent- in a generic way, but some-
NonRecurring, EmpDocu- times the generic way is not
mentInfoEO (workPermitInfo, suitable and need some spe-
visaInfo, citizenshipInfo ) cial handling to suit the real
needs for sync in future if
needed.

Parent topic: Custom HRIS Sync Mappings [page 244]

Related Information

Rules for Configuring HRIS Sync Mappings [page 252]

Configuring HRIS Sync Mappings in Business Configuration UI [page 257]
Configuring HRIS Sync Mappings in the Succession Data Model XML [page 260]
Syncing the Termination Date Between Employee Central and Standard User Fields [page 262]

7.4.2 Rules for Configuring HRIS Sync Mappings

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.

Implementing Employee Central Core

252 PUBLIC Human Resource Information System (HRIS) Synchronization
General Rules

• 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.

This is an example of custom HRIS Sync mapping in XML:

 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

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.

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 253
  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.

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>

The refid Attribute

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.

Implementing Employee Central Core

254 PUBLIC Human Resource Information System (HRIS) Synchronization
  Sample Code

<hris-element-ref refid="personInfo" >

<hris-mapping >
<hris-field-ref refid="date-of-birth" date-format="dd/MMM"/>
<standard-element-ref refid="custom01" />
</hris-mapping >
</hris-element-ref>

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.

Overriding 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.

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"/>

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 255
 </hris-mapping>
</hris-element-ref>

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.

Duplicating Hard-Coded Sync Mappings

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>

Implementing Employee Central Core

256 PUBLIC Human Resource Information System (HRIS) Synchronization
This results in the HRIS field department syncing to both the standard element department (hard-coded
sync mapping) and the standard element custom01 (custom sync mapping).

Parent topic: Custom HRIS Sync Mappings [page 244]

Related Information

Configurable Sync Mappings [page 245]

Configuring HRIS Sync Mappings in Business Configuration UI [page 257]
Configuring HRIS Sync Mappings in the Succession Data Model XML [page 260]
Syncing the Termination Date Between Employee Central and Standard User Fields [page 262]

7.4.3 Configuring HRIS Sync Mappings in Business

Configuration UI

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 258]
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.

Adding Sync Mappings in a Specific HRIS Element [page 259]

Using Business Configuration UI, you can add sync mappings for a specific HRIS field in the HRIS
Element screen.

Parent topic: Custom HRIS Sync Mappings [page 244]

Related Information

Configurable Sync Mappings [page 245]

Rules for Configuring HRIS Sync Mappings [page 252]
Configuring HRIS Sync Mappings in the Succession Data Model XML [page 260]
Syncing the Termination Date Between Employee Central and Standard User Fields [page 262]
Before You Get Started with Business Configuration UI (BCUI)

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 257
7.4.3.1 Adding Sync Mappings in the HRIS Sync Mappings
Section

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

1. Go to Admin Center Manage Business Configuration HRIS Sync Mappings .

2. Select  Add to add a sync mapping.
3. Specify the following information:

Field Description

HRIS Element (ID) Select the source HRIS element.

Field (ID) Select the source HRIS field.

Target Field Type Specify the type of target field you want to map to.

Target Field (ID) Select the target field ID.

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

For example, the entity type for homeAddress element

must be any of these values: home, shipping, mail, and
business.

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

4. Save the settings.

Implementing Employee Central Core

258 PUBLIC Human Resource Information System (HRIS) Synchronization
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 257]

Related Information

Adding Sync Mappings in a Specific HRIS Element [page 259]

7.4.3.2 Adding Sync Mappings in a Specific HRIS Element

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

1. Go to Admin Center Manage Business Configuration Employee Central HRIS Elements .

2. Select any HRIS element, for example, compInfo.

Information on the right side shows details for the selected element.

3. Select Take Action Make Correction .

4. Select Details corresponding to any HRIS field.

Detail page appears.

5. Go to the HRIS Sync Mapping section, do one of the following:

• 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.

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 259
 • To map the HRIS field to a user info record key, enter a key value.

You can enter any arbitrary string value for the Key field, so it is not a refid. Whatever value you use here will
be used as key in the user directory.
6. Optional: Specify the entity type and entity name.

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 257]

Related Information

Adding Sync Mappings in the HRIS Sync Mappings Section [page 258]

7.4.4 Configuring HRIS Sync Mappings in the Succession

Data Model XML

Edit the Succession Data Model XML from Provisioning to configure HRIS Sync mappings to your
organization's needs.

Prerequisites

• You've downloaded the Succession Data Model XML file in Provisioning and have the file open for editing in
an XML 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.

Implementing Employee Central Core

260 PUBLIC Human Resource Information System (HRIS) Synchronization
  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.

Context

Using the Succession Data Model XML, you can do the following:

• Create or update custom sync mappings to synchronize additional data

• Override a hard-coded sync mappings by adding a custom sync mapping

Procedure

1. Find the last <view-template> tag section in your Succession Data Model XML.

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-mapping >
<hris-field-ref refid="timezone"/>
<standard-element-ref refid="timeZone"/>
</hris-mapping>
</hris-element-ref>
...
<hris-sync-mappings>

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 261
Task overview: Custom HRIS Sync Mappings [page 244]

Related Information

Configurable Sync Mappings [page 245]

Rules for Configuring HRIS Sync Mappings [page 252]
Configuring HRIS Sync Mappings in Business Configuration UI [page 257]
Syncing the Termination Date Between Employee Central and Standard User Fields [page 262]
Working with Data Model Files in Provisioning

7.4.5 Syncing the Termination Date Between Employee

Central and Standard User Fields

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

You are an administrator with access to the Business Configuration UI.

The standard element <companyExitDate> is already enabled in your data model.

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>

Implementing Employee Central Core

262 PUBLIC Human Resource Information System (HRIS) Synchronization
  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. Go to Admin Center Manage Business Configuration .

2. Go to Employee Central HRIS Elements employmentInfo in the navigation pane.

3. Under HRIS Fields, find the row with <end-date> in the Identifier column.
4. In the row for <end-date>, click Details and scroll to the HRIS Sync Mapping section in the dialog window.
5. Use the Standard Field search box to find and select <companyExitDate>.

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.

Task overview: Custom HRIS Sync Mappings [page 244]

Related Information

Configurable Sync Mappings [page 245]

Rules for Configuring HRIS Sync Mappings [page 252]
Configuring HRIS Sync Mappings in Business Configuration UI [page 257]
Configuring HRIS Sync Mappings in the Succession Data Model XML [page 260]

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 263
7.5 Special Handling for Syncing Fields

Here is some further information about syncing field values.

Syncing Data Between Different Types of Source and Target Fields

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.

Table 26: HRIS Sync Mappings - Value Output

Source Field Target Field Synced Value More Information

String field String field String

Foundation Object field or String field The name If the name is empty, only the
Generic Object field (externalName) and code object code is synced.
(externalCode) of the
object instance regardless 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 stand-
ard element is set to null.
Other fields of the record can
still sync successfully.

Picklist field String field Label of the picklist value in

the default company locale

Picklist field Picklist field Option ID of the picklist value

Date field String field String The synchronized date in the

target field is displayed in the
locale format you're using so
that it can be understood by
other external systems that
consume the date.

The existing hard-coded sync

mapping of an employee's
date of birth always syncs
the complete date. To make
a custom sync of dates
possible, you need to de-
fine the date-format at-
tribute. See Rules for Config-
uring HRIS Sync Mappings
[page 252].

Implementing Employee Central Core

264 PUBLIC Human Resource Information System (HRIS) Synchronization
Source Field Target Field Synced Value More Information

Decimal field String field String in the default com-

pany locale

Numeric field String field String in the default com-

pany locale

The <isPrimary> Flag and entity-type Attribute

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 name to user directory tables.

Others

• In the sync mapping from the source field gender, only the gender values "Male" and "Female" are
synchronized. Any other gender values, such as "Unknown" and "Undeclared" are set to null in 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 236]

Related Information

Triggering HRIS Sync [page 238]

HRIS Sync Mappings [page 240]
Hard-Coded HRIS Sync Mappings [page 240]

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 265
Custom HRIS Sync Mappings [page 244]
Picklist Configuration for Employee Status and Job Relationship Type [page 266]
HRIS Sync Jobs [page 268]

7.6 Picklist Configuration for Employee Status and Job

Relationship Type

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

U Unpaid Leave Active t

P Paid Leave 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

RNS Reported No-Show 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.

Implementing Employee Central Core

266 PUBLIC Human Resource Information System (HRIS) Synchronization
  Note

The Discarded/Obsolete status is only allowed for Global Assignments.

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.

Non-Unique External Code Relationship Name

hr manager HR Manager

second manager Second Manager

matrix manager Matrix Manager

additional manager Additional Manager

custom manager Custom Manager

delegate 1 Delegate A

delegate 2 Delegate B

If you need to support some or all of the predelivered relationship types, you need to define the non-unique
external code for the picklist option. You can manually add a new job relationship type to the picklist in the
Picklist Center or using MDF imports to have the new job relationships in the system.

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 236]

Related Information

Triggering HRIS Sync [page 238]

HRIS Sync Mappings [page 240]

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 267
Hard-Coded HRIS Sync Mappings [page 240]
Custom HRIS Sync Mappings [page 244]
Special Handling for Syncing Fields [page 264]
HRIS Sync Jobs [page 268]
Relationships Between Managers and Employees
Job Relationships [page 231]

7.7 HRIS Sync Jobs

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.

Job Types for HRIS Sync

The following job types are available for HRIS Sync:

• 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

Execution Restrictions for HRIS Sync Jobs

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.

Job Type Daily Execution Limit

Sync HRIS Data • 3 times for a One-Time job

• 3 times for a Recurring job

Implementing Employee Central Core

268 PUBLIC Human Resource Information System (HRIS) Synchronization
Job Type Daily Execution Limit

Sync HRIS Data for Specific Users 3 times combined regardless of occurrence types

 Note

Daily execution times are counted based on server time.

Creating a Job Request to Sync HRIS Data [page 269]

Create a scheduled job request in Scheduled Job Manager to sync data changes from Employee Central
to user data tables.

Creating a Job Request to Sync HRIS Data for Specific Users [page 273]
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.

Future Hires in HRIS Sync Jobs [page 276]

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.

Parent topic: Human Resource Information System (HRIS) Synchronization [page 236]

Related Information

Triggering HRIS Sync [page 238]

HRIS Sync Mappings [page 240]
Hard-Coded HRIS Sync Mappings [page 240]
Custom HRIS Sync Mappings [page 244]
Special Handling for Syncing Fields [page 264]
Picklist Configuration for Employee Status and Job Relationship Type [page 266]
Managing Scheduled Jobs in Admin Center
Creating a Scheduled Job Request in Admin Center

7.7.1 Creating a Job Request to Sync HRIS Data

Create a scheduled job request in Scheduled Job Manager to sync data changes from Employee Central to user
data tables.

Prerequisites

• You have the following permissions:

• Admin Center Permissions Monitor Scheduled Jobs

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 269
 • Admin Center Permissions Manage Scheduled Jobs
• You've verified that the HRIS Sync mappings in the Succession Data Model are as desired.

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:

• 3 times for a One-Time job

• 3 times for a Recurring job

The daily execution times are counted based on server time.

Procedure

1. Go to Admin Center Scheduled Job Manager .

2. On the Job Scheduler tab, choose Create Job Request.
3. In the Job Definition section, enter the following information.

Setting Description

Job Name The name given to the job.

Job Type Select the option Sync HRIS Data.

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 be-
comes inactive, create a new job request.

4. In the Job Parameters settings, select an option for Sync Types:

Implementing Employee Central Core

270 PUBLIC Human Resource Information System (HRIS) Synchronization
 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 suc-
cessful 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
selected
• 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
recipient if not already and the former manager is removed from any further ac-
countability.

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 Man- All the documents are moved from the former manager's
ager 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.

You can specify if you want to transfer the document to

manager, matrix manager, or both.

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
Owner (Only for 360) forms are transferred to the manager.

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 271
 Option Result

You can specify if you want to transfer the document to

manager, matrix manager, or both.

6. In the Job Parameters settings, select appropriate options for Automatic Document Removal.

All options are disabled by default.

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 Docu- Delete 360 participant evaluation forms for inactive users.
ments

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.
• 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>.

Implementing Employee Central Core

272 PUBLIC Human Resource Information System (HRIS) Synchronization
Task overview: HRIS Sync Jobs [page 268]

Related Information

Creating a Job Request to Sync HRIS Data for Specific Users [page 273]
Future Hires in HRIS Sync Jobs [page 276]
Managing Scheduled Jobs in Admin Center
Creating a Scheduled Job Request in Admin Center

7.7.2 Creating a Job Request to Sync HRIS Data for Specific

Users
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

• You have the following permissions:

• Admin Center Permissions Monitor Scheduled Jobs
• Admin Center Permissions Manage Scheduled Jobs
• You've verified that the HRIS Sync mappings in the Succession Data Model are as desired.
• You've prepared a CSV file containing user IDs, which is accessible through an FTP server.

 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.

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 273
  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

1. Go to Admin Center Scheduled Job Manager .

2. On the Job Scheduler tab, choose Create Job Request.
3. In the Job Definition section, enter the following information.

Setting Description

Job Name The name given to the job.

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.

Option Result

Automatic insertion of new manager as next document The new manager becomes a part of the review process
recipient if not already and the former manager is removed from any further ac-
countability.

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 Man- All the documents are moved from the former manager's
ager 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.

You can specify if you want to transfer the document to

manager, matrix manager, or both.

Implementing Employee Central Core

274 PUBLIC Human Resource Information System (HRIS) Synchronization
 Option Result

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
Owner (Only for 360) forms are transferred to the manager.

You can specify if you want to transfer the document to

manager, matrix manager, or both.

5. In the Job Parameters settings, select appropriate options for Automatic Document Removal.

All options are disabled by default.

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 Docu- Delete 360 participant evaluation forms for inactive users.
ments

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.

7. In the Job Occurrence section, define how frequently you want the job to run.

 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:

Implementing Employee Central Core

Human Resource Information System (HRIS) Synchronization PUBLIC 275
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>.

Task overview: HRIS Sync Jobs [page 268]

Related Information

Creating a Job Request to Sync HRIS Data [page 269]

Future Hires in HRIS Sync Jobs [page 276]
Managing Scheduled Jobs in Admin Center
Creating a Scheduled Job Request in Admin Center

7.7.3 Future Hires in HRIS Sync Jobs

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.

Parent topic: HRIS Sync Jobs [page 268]

Related Information

Creating a Job Request to Sync HRIS Data [page 269]

Creating a Job Request to Sync HRIS Data for Specific Users [page 273]

Implementing Employee Central Core

276 PUBLIC Human Resource Information System (HRIS) Synchronization
8 HR Transactions in Employee Central

HR transactions are managed in several ways within Employee Central.

Here is the list:

• Self-Service for Employees

To allow employees to perform changes to their own personal data.
• Self-Service for Managers
To allow managers to perform data changes for their direct reports.
• History UI
To allow HR admins to keep employee data up-to-date.

 Note

Workflows are not available for the History UI.

Employee Self-Service (ESS) [page 277]

Admins can set up the system to allow employees to update their own data.

Manager Self-Service (MSS) [page 278]

Admins can set up the system to allow managers to make certain changes for the employees who
report to them.

Employee Central Quick Actions [page 282]

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.

8.1 Employee Self-Service (ESS)

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.

Implementing Employee Central Core

HR Transactions in Employee Central PUBLIC 277
Affected Entity Type Transaction Change

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

Address HRIS Edit Address Information Add, change, or delete an ad-

dress

National ID HRIS Edit National ID Information Add, change, or delete na-

tional ID information

Work Permit HRIS Edit Work Permit Information Add, change, or delete work
permit information

Dependents HRIS Edit Dependents Add, change, or delete de-

pendent data

Payment Information MDF Edit Payment Information Add, change, or delete bank
details

Parent topic: HR Transactions in Employee Central [page 277]

Related Information

Manager Self-Service (MSS) [page 278]

Employee Central Quick Actions [page 282]

8.2 Manager Self-Service (MSS)

Admins can set up the system to allow managers to make certain changes for the employees who report to
them.

These changes can be made using Actions Change Job and Compensation Info or using the Edit button.
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.

Admins control the allowed transactions based on the permissions for those users.

Implementing Employee Central Core

278 PUBLIC HR Transactions in Employee Central
Affected Entity Transaction Change

Global Assignment Actions Add Global Assignment Add an assignment.

Global Assignment Actions Edit Global Assignment Change an existing assignment.

Global Assignment Actions End Global Assignment End an assignment.

Global Assignment Actions Obsolete Global Set an assignment to obsolete.

Assignment

Concurrent Employment Actions Add Concurrent Add additional employment.

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 exam-
ple, add a matrix manager or HR busi-
Compensation Info
ness partner

Pay Component Non-Recurring Actions Spot Bonus Add a spot bonus.

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

repay 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, de-
Distribution
pending on the selected start date.
When doing so, combinations of cost
center and percentage can be added,
updated, or deleted.

Employment Information Actions Employment Details Update employment information.

Employment Information Actions Terminate Set the termination data and reason for
an employee.

Parent topic: HR Transactions in Employee Central [page 277]

Related Information

Employee Self-Service (ESS) [page 277]

Implementing Employee Central Core

HR Transactions in Employee Central PUBLIC 279
Employee Central Quick Actions [page 282]

8.2.1 Rule Handling with Manager Self-Service

Here is some information about rule handling in the system for Job Information, Job Relationships, and
Compensation Information.

General

The order of processing of rules is

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 block such as Compensation Information and Recurring Pay Components).

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.

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.

The rule handling is changed for the following transactions:

• 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

Implementing Employee Central Core

280 PUBLIC HR Transactions in Employee Central
• 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.

This change does not impact cross-entity rules.

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.

•  Note

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

Related Information

Events in Employee Central [page 125]

Event Reason Derivation Business Rules [page 136]
Workflow Derivation Business Rules [page 139]

Implementing Employee Central Core

HR Transactions in Employee Central PUBLIC 281
8.3 Employee Central Quick Actions

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
for a given use case. For each predelivered use case, you can create up to 5 templates. Each Quick Action
allows a definiton of 5 standard and custom fields (including country/region-specific fields) in total, as well as
the effective date field.

 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.

Process

1. Enable the admin setting.

2. Add permissions for admins to be able to create Quick Action templates (MDF config object).
3. Configure the template for the use case.
4. Add permissions of the newly created Quick Action Templates for employees and managers.
5. Repeat as necessary for other scenarios - up to 5 templates for each use case.

Channels and Access Points

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)

Implementing Employee Central Core

282 PUBLIC HR Transactions in Employee Central
 • 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 Work Zone

Rule Handling

Model-based rules are supported in the Employee Central Quick Actions.

Only the following rule triggers are supported:

• onSave
• onChange
The system executes rules for all fields even if the field is not shown on the UI.

onInit and onView rule triggers are not supported.

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.

Parent topic: HR Transactions in Employee Central [page 277]

Related Information

Employee Self-Service (ESS) [page 277]

Manager Self-Service (MSS) [page 278]
Home Page
SAP SuccessFactors Mobile Features
Work Zone - My Profile
Using Employee Central Self-Service in Microsoft Teams

Implementing Employee Central Core

HR Transactions in Employee Central PUBLIC 283
8.3.1 Use Cases for Employee Central Quick Actions

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.

Mandatory Fields Supported Fields

(Default Fields in (Default Fields in
Name Base Object Bold) Bold) Event Best Practice

Change Chosen Personal Informa- At least one of the • Business First n/a ESS
Name tion following fields is
Name
required:
• Business First
• Preferred Name Alt1
Name
• Business First
• Display Name
Name Alt2
• Business
Name
• Display Name

• Third Name • Preferred

Name
• Display Name
Alt1
• Display Name
Alt2
• Third Name
• Third Name
Alt1
• Third Name
Alt2

Change Pronouns Users Sys Info • USERS_SYS_ USERS_SYS_PRO- n/a ESS

NOUNS
PRONOUNS
 Note
Changing pro-
nouns is only
allowed for
Employee
Self-Service
scenarios.

Implementing Employee Central Core

284 PUBLIC HR Transactions in Employee Central
 Mandatory Fields Supported Fields
(Default Fields in (Default Fields in
Name Base Object Bold) Bold) Event Best Practice

Change Location Job Information • Location • Location Data Change MSS

• Timezone
• Travel Dis-
tance
• Transporta-
tion Subsidy
• Notes
• Is Cross Bor-
der Worker
• Is Home
Worker
• Work Location
• Holiday Cal-
endar
• Time Profile

Change Working Job Information At least one of the • Standard Data Change MSS
Time following fields is
Hours
required:
• Notes
• FTE
• FTE
• Standard
Hours
• Is Full Time
Employee
• Working Days
Per Week • Is Shift Em-

• Is Full Time ployee

Employee • Shift Code
• Working Days
Per Week
• Working Time
Directive

Implementing Employee Central Core

HR Transactions in Employee Central PUBLIC 285
 Mandatory Fields Supported Fields
(Default Fields in (Default Fields in
Name Base Object Bold) Bold) Event Best Practice

Change Job Job Information At least one of the • EEO Class Job Change MSS
following fields is
required:
• Job Title
• Local Job Title
• Job Code
• Job Code
• Job Title
• Local Job Title
• Employee
Type
• Notes
• Employee
Class
• Employment
Type
• Regular/
Temporary
• Is Shift Em-
ployee
• Shift Code
• Is Home
Worker
• Is Volunteer
• Contract Type
• Worker Cate-
gory
• Contract
Number
• Contract ID
• Job Group
• Contract Date
• Contract End
Date

Implementing Employee Central Core

286 PUBLIC HR Transactions in Employee Central
 Mandatory Fields Supported Fields
(Default Fields in (Default Fields in
Name Base Object Bold) Bold) Event Best Practice

Change Legal Personal Informa- At least one of the • First Name n/a ESS
Name tion following fields is
required:
• Middle Name
• Last Name
• First Name
• First Name
• Middle Name
Alt1
• Last Name
• Middle Name
• Birth Name
Alt1
• Formal Name
• Last Name
• Second Last
Alt1
Name
• Business Last
• First Name

Name Alt2
• Middle 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

Implementing Employee Central Core

HR Transactions in Employee Central PUBLIC 287
 Mandatory Fields Supported Fields
(Default Fields in (Default Fields in
Name Base Object Bold) Bold) Event Best Practice

Change Contract Job Information • Contract End • Notes Data Change MSS
End Date Date • Regular/
Temporary
• Contract Type
• Contract
Number
• Contract Date
• Contract End
Date

Change Cost Cen- Job Information • Cost Center • Notes Data Change MSS
ter
• Cost Center

Change Probation Job Information • Probation • Notes Probation MSS

End Date • Contract Type
• Contract
Number
• Probation Pe-
riod End Date
• Probation Pe-
riod
• Probation Pe-
riod Measure

Implementing Employee Central Core

288 PUBLIC HR Transactions in Employee Central
 Mandatory Fields Supported Fields
(Default Fields in (Default Fields in
Name Base Object Bold) Bold) Event Best Practice

Promotion Job Information At least one of the • Job Code Promotion MSS
following fields is
required:
• Notes
• Pay Grade
• Position
• Is Eligible for
• Manager
Car
• Pay Grade
• Is Eligible for
• Job Code
Benefit
• Is Eligible for
Financial Plan
• Position ID
• Manager ID
• Pay Group
• Pay Scale
Area
• Pay Scale
Type
• Pay Scale
Group
• Pay Scale
Level

Transfer (With or Job Information At least one of the • Department Transfer MSS
Without Position following fields is
Change) required:
• Division
• Location
• Position
• Notes
• Manager
• Business Unit
• Cost Center
• Manager ID
• Timezone
• Position ID
• Holiday Cal-
endar
• Time Profile

View Cost Center Job Information • Cost Center • Cost Center n/a -

• Notes

Implementing Employee Central Core

HR Transactions in Employee Central PUBLIC 289
 Mandatory Fields Supported Fields
(Default Fields in (Default Fields in
Name Base Object Bold) Bold) Event Best Practice

View Job Job Information At least one of the • EEO Class n/a -
following fields is
required:
• Job Title
• Local JobTitle
• Job Code
• Job Code
• Job Title
• Local Job Title
• Employee
Type
• Notes
• Employee
Class
• Employment
Type
• Regular/
Temporary
• Is Shift Em-
ployee
• Shift Code
• Is Home
Worker
• Is Volunteer
• Contract Type
• Worker Cate-
gory
• Contract
Number
• Contract ID
• Job Group
• Contract Date
• Contract End
Date

Implementing Employee Central Core

290 PUBLIC HR Transactions in Employee Central
 Mandatory Fields Supported Fields
(Default Fields in (Default Fields in
Name Base Object Bold) Bold) Event Best Practice

View Legal Name Personal Infroma- At least one of the • First Name n/a -
tion following fields is
required:
• Middle Name
• Last Name
• First Name
• First Name
• Middle Name
Alt1
• Last Name
• Middle Name
• Birth Name
Alt1
• Formal Name
• Last Name
• Second Last
Alt1
Name
• Business Last
• First Name

Name Alt2
• Middle 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

Implementing Employee Central Core

HR Transactions in Employee Central PUBLIC 291
 Mandatory Fields Supported Fields
(Default Fields in (Default Fields in
Name Base Object Bold) Bold) Event Best Practice

View Location Job Information • Location • Job Location n/a -

• Work Location
• Notes
• Is Cross Bor-
der Worker
• Is Home
Worker
• Timezone
• Travel Dis-
tance
• Transporta-
tion Subsidy
• Holiday Cal-
endar
• Time Profile

View Marital Sta- Personal Informa- • Marital Sta- • Salutation n/a -

tus tion
tus • Marital Status
• Since
• Ethnic Group
• Religion
• Healthcare
Number
• Healthcare
Province
• Partner Name
• Partner Name
Prefix

Related Information

Configuring an Employee Central Quick Action Template [page 293]

Data Model Field Information for Personal Information
Data Model Field Information for Job Information

Implementing Employee Central Core

292 PUBLIC HR Transactions in Employee Central
8.3.2 Enabling Employee Central Quick Actions

Enable this setting in your system, so that you can use it.

Procedure

1. Navigate to Admin Center Manage Employee Central Settings .

2. Under Person, Employment and Worker Type, select Employee Central Quick Actions.
3. Save your changes.

Next Steps

Ensure that all required fields are set to Enabled and Visible or Editable in the data model.

Enable the Administrator Permissions Manage Business Configuration Employee Central Quick Action
Template permission setting for admins so that they can create templates.

8.3.3 Configuring an Employee Central Quick Action

Template

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.

Implementing Employee Central Core

HR Transactions in Employee Central PUBLIC 293
  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

1. Go to Admin Center Manage Data .

2. Select Create New Employee Central Quick Action Template .

3. Add the required basic information.

Field Description

Use Case Select the use case you need from the drop-down list.

Code This is defaulted by the system based on the chosen use

case. However, it is possible to change this as long as it
remains unique in the system.

 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 remove the verb (Change or View) if needed, since

the use cases are shown in the Change or View segment of
the Actions list.

You can add translations for the templates. For more infor-
mation, refer to the Managing Languages and Customiz-
ing UI Labels guide.

Base Object This is defaulted by the system based on the chosen use
case.

Implementing Employee Central Core

294 PUBLIC HR Transactions in Employee Central
 Field Description

Event This is defaulted by the system based on the chosen use

case, where applicable.

Each use case allows only one specific event.

Here is a list of the events allowed:

• Data Change
• Job Change
• Job Classification
• Probation
• Promotion
• Transfer

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).

If no event reason is defined in the template, then the

system uses ERD.

The system does not check view permissions for event

reasons.

 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.

Status The status of the template - either active or inactive.

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 5 for each country/region. If there are more than 5 fields to be displayed for the
user, then the system won't let you save the template until the number is corrected.

Example

For the Change Location template, you could add the following fields:
• JobInformation: Location
• JobInformation: Timezone
• JobInformation_DEU: Travel Distance

Implementing Employee Central Core

HR Transactions in Employee Central PUBLIC 295
 • 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
• JobInformation_CHN: Work Location
• JobInformation_CHN: Travel Distance

Field Description

Data Model Select the HRIS entity, for example, Job Information or
Job Information_DEU

Identifier Select the HRIS element you want to use.

 Note

For Custom String texts, the Type of Reference

Object Employee setting is not supported.

Label The label for the field is defaulted by the system.

Action You can rearrange the order by selecting an up or down

arrow, or delete a row.

 Note

Attachments are not supported for any use cases.

 Note

Legislatively sensitive personal data fields configured as masked are not supported with Employee
Central Quick Actions and shouldn't be added to the template.

5. Save your changes.

Next Steps

You can make up to five active templates for each use case, so repeat the above steps as necessary.

Implementing Employee Central Core

296 PUBLIC HR Transactions in Employee Central
To access and change Employee Central Quick Actions, employees and managers need to have the following
role-based permissions:

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
Entities Job Information Job Information Actions Employee Central Quick Actions with Job Information as the

View Current base entity.

User Permissions Employee Central Effective-Dated Select this setting for users to enter data for a past date
Entities Job Information Job Information Actions (before the start date of the record that is valid as of today).

View History

User Permissions Employee Central Effective-Dated Select this setting for users to change templates with Job
Information as the base entity. This setting is required in
Entities Job Information Edit Link Edit/Insert
addition to the Job Information Actions View Current
or
or Job Information Actions View History permission.
User Permissions Employee Central Effective-Dated

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
Entities Personal Information Personal Information Employee Central Quick Actions with Personal Information

Actions View Current as the base entity.

User Permissions Employee Central Effective-Dated Select this setting for users to enter data for a past date
Entities Personal Information Personal Information (before the start date of the record that is valid as of today).

Actions View History

User Permissions Employee Central Effective-Dated Select this setting for users to change templates with Per-
sonal Information as the base entity. This setting is re-
Entities Personal Information Edit Link Edit/Insert
quired in addition to the Personal Information Actions
or
View Current or Personal Information Actions View
User Permissions Employee Central Effective-Dated History permission.
Entities Personal Information Personal Information

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
Transaction Alerts
Data Permissions - 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, quickcard, on their mobile device, or any of the other channels, such as Joule or Microsoft
Teams.

Implementing Employee Central Core

HR Transactions in Employee Central PUBLIC 297
  Note

It is not possible to transport your templates to the Configuration Transport Center.

Related Information

Employee Central Quick Actions [page 282]

Enabling Employee Central Quick Actions [page 293]
Calculating FTE [page 229]
Use Cases for Employee Central Quick Actions [page 284]
Employee and Manager Self-Service Use Cases (Home Page)
SAP SuccessFactors Mobile Features
Work Zone - My Profile
Using Employee Central Self-Service in Microsoft Teams

Implementing Employee Central Core

298 PUBLIC HR Transactions in Employee Central
9 Centralized Services in Employee Central

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.

Centralized services are enabled by default, and are applicable to data imports initiated from the Import
Employee Data page or OData APIs.

For more information about imports, refer to Centralized Services for Employee Data Imports.

Save Action on Editing UI

Centralized services support saving changes on the Editing UI of a supported HRIS entity. To access the Editing
UI of a block in People Profile, you choose the icon  (Edit) in that block.

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 Configuration Type Setting

Addresses Universal

Personal Information and Global Infor- Universal

mation

National ID Universal

Contact Information, consisting of: Universal

• Phone Information
• Email Information
• Social Accounts

Emergency Contacts Universal

Implementing Employee Central Core

Centralized Services in Employee Central PUBLIC 299
HRIS Entity Configuration Type Setting

Dependents Admin Opt-out Admin Center Company System

and Logo Settings Enable Centralized
Services for Dependents (Applicable for
data imports from UI and API and saving
changes on Editing UI)

Employment Details Universal

Global Assignments Universal

Higher Duty/Temporary Assignment Universal

Non-Recurring Pay Component Infor- Universal

mation

Work Permit Universal

Save Action on History UI

Centralized services support saving changes on the History UI of a supported HRIS entity. To access the
History UI of a block in People Profile, you choose the icon  (History) in that block.

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:

HRIS Entity Configuration Type Setting

Addresses Universal

Dependents Admin Opt-out Admin Center Company System

and Logo Settings Enable Centralized
Services for Dependents (Applicable for
saving changes on History UI)

Personal Information and Global Infor- Universal

mation

Job Information Universal

Job Relationships Universal

Compensation Information and Recur- Universal

ring Pay Components

Save Action in Manager Self-Service (MSS)

Centralized services support saving changes on the MSS UI of a supported HRIS entity.

Implementing Employee Central Core

300 PUBLIC Centralized Services in Employee Central
Save on the MSS UI of the following HRIS entities are supported by Centralized services:

HRIS Entity Configuration Type Setting

Job Information Universal

Job Relationships Universal

Compensation Information Universal

Termination Universal

Internal Hire using the Manage Pending Universal

Jobs Tool

Related Information

Entry Dates, Event-Based Dates, and TimeIn Calculation for Job Information
Record Suppression for Personal Information and Global Information on the UI [page 204]
Data Deletion for Certain Person Entities on History UI [page 196]
Forward Propagation of Personal Information and Global Information on History UI [page 199]
Forward Propagation of Addresses on History UI [page 206]
Follow-Up Processes After Saving on Manager Self-Service UI

9.1 Cross-Entity Rules with Centralized Services

For employment-related 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.

Cross-entity rules are supported for these entities:

• Job Information
• Job Relationship Information
• Compensation Information
• Recurring Pay Component
• Non-Recurring Pay Component
• Employment Details
• Termination Details

The source/target direction is very important. The source element must be the base object of the rule.

Common use cases for cross-entity rules are

• 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

Implementing Employee Central Core

Centralized Services in Employee Central PUBLIC 301
• 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.

Cross entity-rules are supported with workflows.

If the source entity supports forward propagation, then by default, the target entity is also supported with
forward propagation when data is updated using cross-entity rules.

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 block such as Compensation Information and Recurring Pay Components).

Event Reason Derivation

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 and Concurrent Employment

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 editing a global assignment, cross-entity rules with Job Information as source element and Job
Relationships or Compensation Information as target element are triggered only if a Job Information record
exists on the same date or before the Job Relationships or Compensation Information start date when saving a
Host Assignment.

Implementing Employee Central Core

302 PUBLIC Centralized Services in Employee Central
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.

Rules Using the Create Expression

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 Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Job Information Not Supported Supported: Not Supported Supported: Supported: Not Supported

• onSave • onSave • onSave

• onChange • onChange

Job Relation- Not Supported - Not Supported Not Supported Not Supported Not Supported
ships

Implementing Employee Central Core

Centralized Services in Employee Central PUBLIC 303
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

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
Compo-
nent. Do
not navi-
gate to Em-
ployment
Details and
then to the
Recurring
Pay Com-
ponent.

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)

Implementing Employee Central Core

304 PUBLIC Centralized Services in Employee Central
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Employment Not Supported Not Supported Not Supported Not Supported Not Supported Not Supported
Details and Ter-
mination De-
tails

(Inactive/
Terminated Em-
ployment with
Employment In-
formation as
Source Ele-
ment)

Employment Not Supported Supported Not Supported Supported Supported Not Supported
Details and Ter-
mination De-
tails

(Inactive/
Terminated Em-
ployment with
Job Information
as Source Ele-
ment)

Rules Using the Set Expression

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.

Implementing Employee Central Core

Centralized Services in Employee Central PUBLIC 305
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Job Information Not Supported Supported: Supported: Supported: Supported: Supported:

• onSave • onSave • onSave • onSave • onSave

• onChange • onChange • onChange

Job Relation- Supported: Not Supported Not Supported Not Supported Not Supported Supported:
ships
• onSave • onSave
• onChange

Compensation Supported: Supported: Not Supported Supported: Supported: Supported:

Information
• onSave • onSave • onSave • onSave • onSave

• onChange • onChange • onChange

 Cau-
tion
We recom-
mend navi-
gating di-
rectly from
Compensa-
tion Infor-
mation to
the Recur-
ring Pay
Compo-
nent. Do
not navi-
gate to Em-
ployment
Details and
then to the
Recurring
Pay Com-
ponent.

Recurring Pay Supported: Supported: Supported: Not Supported Supported: Supported:

Component
• onSave • onSave • onSave • onSave • onSave
• onChange • onChange

Implementing Employee Central Core

306 PUBLIC Centralized Services in Employee Central
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Non-Recurring Not Supported Not Supported Supported: Supported: Supported: Supported:

Pay Component
• onSave • onSave • onSave • onSave

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 De- • onSave • onSave
tails
• onChange
(Inactive/
Terminated Em-
ployment with
Employment In-
formation as
Source Ele-
ment)

Employment Supported: Supported: Supported: Supported: Supported: Supported:

Details and Ter-
mination De- • onSave • onSave • onSave • onSave • onSave • onSave
tails
• onChange • onChange • onChange • onChange • onChange • onChange
(Inactive/ • onPost-
Terminated Em- Save
ployment with
Job Information
as Source Ele-
ment)

Rules Using the Delete Expression

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.

Implementing Employee Central Core

Centralized Services in Employee Central PUBLIC 307
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

Job Information Not Supported Supported: Not Supported Supported: Supported Not Supported

• onSave • onSave • onSave

• onChange • onChange

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
Compo-
nent. Do
not navi-
gate to Em-
ployment
Details and
then to the
Recurring
Pay Com-
ponent.

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

Implementing Employee Central Core

308 PUBLIC Centralized Services in Employee Central
 Target Ele-
ment: Com- Target Ele- Target Ele-
Target Ele- Target Ele- pensation In- ment: Recur- ment: Non-Re- Target Ele-
Source Ele- ment: Job In- ment: Job Re- formation ring Pay Com- curring Pay ment: Employ-
ment formation lationships ponent Component ment Details

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 De-
tails

(Inactive/
Terminated Em-
ployment with
Employment In-
formation as
Source Ele-
ment)

Employment Not Supported Supported Not Supported Supported Supported Not Supported
Details and Ter-
mination De-
tails

(Inactive/
Terminated Em-
ployment with
Job Information
as Source Ele-
ment)

Related Information

Cross-Entity Rules [page 156]

9.2 Manager Self-Service (MSS) Supported on Centralized

Services

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.

Implementing Employee Central Core

Centralized Services in Employee Central PUBLIC 309
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

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.

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.

Entities in MSS

Supported on Centralized
Affected Entity Transaction Services Change

Global Assignment Actions Add Global Yes Add an assignment.

Assignment

Implementing Employee Central Core

310 PUBLIC Centralized Services in Employee Central
 Supported on Centralized
Affected Entity Transaction Services Change

Global Assignment Actions Edit Global Yes Change an existing assign-

ment.
Assignment

Global Assignment Actions End Global Yes End an assignment.

Assignment

Global Assignment Actions Obsolete Global Yes Set an assignment to obso-

lete.
Assignment

Concurrent Employment Actions Add Concurrent Yes Add additional employment.

Employment

Job Information Actions Change Job and Yes Change an employee's job,
for example, for a promotion
Compensation Info
or change the manager.

Job Relationship Actions Change Job and Yes Change the job relationship,
for example, add a matrix
Compensation Info
manager or HR business
partner

Pay Component Non-Recur- Actions Spot Bonus No Add a spot bonus.

ring

Compensation Information Actions Change Job and Yes Change the compensation
data, for example, pay group.
Compensation Info

Recurring Pay Component Actions Change Job and Yes Add, update, or delete recur-
ring pay components such as
Compensation Info
for the base salary or a com-
pany car allowance.

Recurring Deduction Actions Manage No Add a recurring deduction,

such as to repay a company
Recurring Deductions
housing loan.

One Time Deduction Actions One Time No Add a one-time deduction,

such as for a charity dona-
Deduction
tion.

Alternative Cost Distribution Actions Manage No Add a new alternative cost

Alternative Cost distribution record or mod-
ify the latest one, depending
Distribution
on the selected start date.
When doing so, combinations
of cost center and percent-
age can be added, updated,
or deleted.

Employment Information Actions Employment Yes Update employment infor-

mation.
Details

Employment Information Actions Terminate Yes Set the termination data and
reason for an employee.

Implementing Employee Central Core

Centralized Services in Employee Central PUBLIC 311
Related Information

Follow-Up Processes After Saving on Manager Self-Service UI

Implementing Employee Central Core

312 PUBLIC Centralized Services in Employee Central
10 Deep Links in Employee Central

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.

Link Description Parameters

/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 user to the Position Org Chart selected_position=<position external

code>

(selected_user will contain the person

id of a user)

/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>

/xi/ui/apprenticemanagement/pa- Takes apprentice supervisor to Appren- N/A

ges/apprenticemanagement.xhtml tice Management

/xi/ui/apprenticemanagement/pa- Takes on-site supervisor to Apprentice N/A

ges/apprenticemanagementdepart- Management
ment.xhtml

sf/timeoff Takes user to Time Off employee self N/A

service page

sf/timeoffworkbench Takes user to Time Off Workbench selected_user can be entered as a pa-
rameter. If it is not, theWorkbench
or Administer Time is opened for the
logon user.

sf/timeoffcalendars Takes user to Time Off change calen- N/A

dars

/sf/payoutandpurchasetime#payout Takes user to the Time Off leave payout N/A

feature.

/sf/payoutandpurchasetime#purchase Takes user to the Time Off purchase N/A

leave feature.

Implementing Employee Central Core

Deep Links in Employee Central PUBLIC 313
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=

Implementing Employee Central Core

314 PUBLIC Deep Links in Employee Central
11 Mobile Employee Central

11.1 Setting Up Mobile

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:

• Users can only activate the device from a valid account

• You can wipe lost or stolen devices from your computer and erase all sensitive data
• You can add an on-device mobile password to create an extra layer of security
• There is Mobile Device Management Support (MDM)

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.

Implementing Employee Central Core

Mobile Employee Central PUBLIC 315
11.2 Mobile To-Do Items in Employee Central

This section describes how to set up to-do items in Employee Central for your mobile device.

Overview

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

• Remember to register and activate your mobile device.

• Once you have have enabled the To-Do List, you must activate this feature for mobile use. In your instance,
navigate to the Admin Center. In the Tools search field, type Mobile Settings. Ensure that Theming, SF
Notifications, and On Device Support are enabled.
• In addition, you can select further Employee Central areas to be accessible on your mobile, for example,
Time Off, Benefits, or Pay Summary.

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.

• Changes to job details

• Change to job relationships
• Changes to recurring pay components
• Spot bonuses
• Leaves of absence

Implementing Employee Central Core

316 PUBLIC Mobile Employee Central
12 Ad Hoc Report Types

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

• Some reports do not support role-based permissions

• Reports will time out after 5 minutes. This means that, for the more complex or large ad-hoc reports, we
recommend that you run these reports offline. Alternatively, if they are to be run on a regular basis, they
can be scheduled to run and output to SFTP
• Always use filters in Date Range and As Of Date reports

Person and Employment (As of Date)

This report shows employee HR data as of a given date (by default, it shows today unless specified), for
example, reporting all employees hired as of 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 As Of Date 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.

This report respects Cell Level Permissions.

Be mindful of the number of Column Sets (JOINS) 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 return only as numbers. This is for performance reasons. If you want the corresponding
labels or external codes that match, select the columns in the relevant entity to generate a report with codes.

 Note

Since the data displayed in the Compensation Information block 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) ad hoc report, you must
have the HRIS PayComponentGroup Sums Sync job created and 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 selecting the column set
“Employee Pay Group Sums” and one of the Pay Component Groups, such as AnnualizedSalary.

Implementing Employee Central Core

Ad Hoc Report Types PUBLIC 317
Job Information (Date Range)

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.

This report does not respect Cell Level Permissions.

The report always generates based on Job Information data structure.

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.

Recurring Compensation (Date Range)

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.

This report does not respect Cell Level Permissions.

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.

Non-Recurring Compensation (Date Range)

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.

Implementing Employee Central Core

318 PUBLIC Ad Hoc Report Types
This report does not respect Cell Level Permissions.

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.

Person and Employment (Audit)

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.

This report does not respect Cell Level Permissions.

Action Types in the Audit Report

• 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.

Only admin users should have access to this report.

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 see deleted records in this report.

Person and Employment (Export)

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.

Implementing Employee Central Core

Ad Hoc Report Types PUBLIC 319
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.

This report does not respect Cell Level Permissions.

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.

Multi-Data Set Reporting

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.

Scheduled Reporting

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

Implementing Employee Central Core

320 PUBLIC Ad Hoc Report Types
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.

12.1 Permissions for Ad-Hoc Reports

There are different options that can be enabled for Ad Hoc Reports.

Row Level Permissions

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.

Cell and Field Level Permissions

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).

Implementing Employee Central Core

Ad Hoc Report Types PUBLIC 321
12.2 Ad Hoc Report Query Trimming

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):

• Person and Employment (As of Date)

• Job Information (Date Range)
• Recurring Compensation Information (Date Range)
• Non-Recurring Compensation (Date Range)

Implementing Employee Central Core

322 PUBLIC Ad Hoc Report Types
13 Implementing Alternative Cost
Distribution

13.1 Enabling Alternative Cost Distribution

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

1. Go to Admin Center Manage Employee Central Settings .

2. In the resulting screen, enable Cost Distribution.

You can access full information about Alternative Cost Distribution by selecting the question mark (?) icon
next to the Cost Distribution switch.
3. Save your settings.

Results

Cost distribution is enabled in your system.

Implementing Employee Central Core

Implementing Alternative Cost Distribution PUBLIC 323
13.2 Enabling Cost Centers for Non-Recurring Pay
Components

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

1. Go to Admin Center Manage Business Configuration .

2. Select Employee Central payComponentNonRecurring .

3. Add the <alternative-cost-center> field.
4. Save your changes.

Results

Cost distribution is now enabled for spot bonus.

13.3 Assigning Alternative Cost Distribution to an Employee

Assign the alternative cost distribution to an employee where needed.

Prerequisites

Ensure that the miscellaneous permissions have been granted in the object definition and that the block is
visible.

Procedure

1. Go to Admin Center Employee Files Employment Information .

2. Select Take Action Manage Alternative Cost Distribution .

3. In the What changes are you proposing for (employee name)? screen, select Take Action Manage
Alternative Cost Distribution .

Implementing Employee Central Core

324 PUBLIC Implementing Alternative Cost Distribution
4. Make the corresponding entries.
• You can enter up to 30 cost centers for one employee.
• The total percentage of all cost centers cannot be greater than 100 %.
• If the total percentage of all cost centers entered in the Alternative Cost Distribution block is less than
100 %, the remaining percentage is deducted from the Cost Center foundation object that has been
added for the employee.
• You can also add the cost center that has been added as a foundation object for the employee in the
Alternative Cost Distribution block.
5. Save your changes.

13.4 Configuring People Profile Block for Alternative Cost

Distribution

To avoid errors in the People Profile, configure the Alternative Cost Distribution block as a Live Profile MDF
Information custom block with MDF Screen ID EmpCostDistributionUI .

Procedure

1. Go to Admin Center Configure People Profile .

2. Scroll until you find Alternative Cost Distribution.
3. Select Remove Block.
4. In the Available Blocks search field, search for MDF.

In the Custom Blocks section, the Live Profile MDF Information appears.
5. Drag the Live Profile MDF Information block 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.

7. Save your changes.

Implementing Employee Central Core

Implementing Alternative Cost Distribution PUBLIC 325
13.5 Adding Custom Fields for Alternative Cost Distribution

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

1. Go to Admin Center Employee Files Manage Configuration UI .

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.

3. Add the fields you want.

4. Save your changes.

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.

Implementing Employee Central Core

326 PUBLIC Implementing Alternative Cost Distribution
13.6 Importing Data for Alternative Cost Distribution

Import alternative cost distribution data to save the manual effort.

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

1. Download the templates.

a. Go to Admin Center Import Data .

b. In the Import and Export Data screen, from the Select the action to perform dropdown list, choose
Download Template.
c. Download the following two data import file templates:
• Alternative Cost Distribution
• Alternative Cost Distribution Item-Alternative Cost Distribution
2. Update the templates.

a. You can find the downloaded templates by going to the Admin Center Monitor Jobs .

 Note

The job name for the templates starts with EmpCostDistribution:

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.

Implementing Employee Central Core

Implementing Alternative Cost Distribution PUBLIC 327
13.7 Troubleshooting Alternative Cost Distribution

Here's a look at some issues you might encounter when using Alternative Cost Distribution.

Failed Data Purge

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 block 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.

To resolve the issue, try the following:

• 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.

Implementing Employee Central Core

328 PUBLIC Implementing Alternative Cost Distribution
14 Retired Functionality

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.

14.1 Event Reason Derivation from XML

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.

Provisioning related changes that are a part of this upgrade include:

• 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.

Implementing Employee Central Core

Retired Functionality PUBLIC 329
  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.

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.

For more information, refer to the Related Information section.

Use Cases

Consider the following table chart for reference:

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

4 JR4 JR4 JR4

5 CR5 CR5 CR5

6 JC6 JC6 JC6

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

Use Case 1: Deriving the event reason based on Job Information.

XML Rule:

 Sample Code

<rule id="rule-PT1">
<trueoutput>POS_XFR</trueoutput>
<conditions>
<and>

Implementing Employee Central Core

330 PUBLIC Retired Functionality
 <equal
id="jobInfo.pay-grade" inverse="true"/>
<equal
id="jobInfo.position" value="" inverse="true"/>
<equal
id="jobInfo.cost-center" value="63000" />
</
and>
</conditions>
</rule>

Migrated business rule:

 Example

Use Case 2: Deriving the event reason based on Compensation Information.

XML Rule:

 Sample Code

<rule id="rule-7">
<trueoutput>PAYBEN</trueoutput>
<conditions>
<and>
<equal
id="compInfo.benefits-rate" inverse = "true"/>
</and>
</conditions>
</rule>

Migrated business rule:

 Example

Use Case 3: Deriving the event reason based on the Job Relationship information of an employee.

Implementing Employee Central Core

Retired Functionality PUBLIC 331
 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>

Migrated business 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>

Migrated business rule:

Implementing Employee Central Core

332 PUBLIC Retired Functionality
  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>

Migrated business 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" />
<greater
id="jobInfo.pay-grade.paygradeLevel"/>
</and>
</conditions>
</rule>

Implementing Employee Central Core

Retired Functionality PUBLIC 333
 Migrated business rule:

 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>

Migrated business rule:

Related Information

Implementing Business Rules in SAP SuccessFactors

Event Reason Derivation Business Rules
Employee Central Resouces Blog: Event Reason Derivation XML Rules Change to Business Rules

Implementing Employee Central Core

334 PUBLIC Retired Functionality
Change History

Learn about changes to the documentation for Implementing Employee Central Core.

2H 2023

Type of Change Description More Info

Oct 27, 2023

Changed We removed the information about ena-

bling the setting Encrypt User ID in URL.
User IDs in URLs are now encrypted by
default.

Oct 13, 2023

New You can now create templates for com- Employee Central Quick Actions [page
monly used Manager Self-Service and
282]
Employee Self-Service usecases. The
templates can be tailored for your Use Cases for Employee Central Quick
company and country/region-specific Actions [page 284]
requirements.
Enabling Employee Central Quick Ac-
tions [page 293]

Configuring an Employee Central Quick

Action Template [page 293]

Added We added a note that mappings to Rules for Configuring HRIS Sync Map-
userId will be ignored during HRIS Sync pings [page 252]
and the data won't be synced.

Changed We updated the information about con- Configuring HRIS Sync Mappings in
figuring sync mappings using the tool Business Configuration UI [page 257]
Manage Business Configuration as per
the latest user experience.

New You can now enable attachments for Enabling Attachments for Personal In-
Global Information. formation Entities [page 218]

New Saving changes on the History UI of de- Centralized Services in Employee Cen-
pendents is supported by Centralized tral [page 299]
services as an Admin Opt-out feature.

New An HRIS Sync job that is triggered by Employee Central Data Import or API
data import or API operations now waits Operations [page 239]
10 minutes before starting.

Changed We removed the topic "Keeping the User Human Resource Information System
Directory and Org Chart Up to Date". Re- (HRIS) Synchronization [page 236]
fer to HRIS Sync for more information.

Implementing Employee Central Core

Change History PUBLIC 335
Type of Change Description More Info

Changed We added information about how data is Special Handling for Syncing Fields
synchronized between different types of [page 264]
fields and in which language the data is
sent to Platform user data.

Changed Saving changes for Job Information and Manager Self-Service (MSS) Sup-
Job Relationships using Manager Self-
ported on Centralized Services [page
Services is universally supported by
309]
Centralized services and requires no set-
tings. Data Validation for Job Information
(MSS and History UI) [page 224]

Data Validation for Job Relationships

(MSS and History UI) [page 232]

Changed Saving changes for Employment Details System Behavior for Editing UI of Em-
on the Edit UI is universally supported
ployment Details [page 221]
by Centralized services and requires no
settings. Business Rules for Employment Details
[page 219]

Changed Saving changes for Compensation In-

formation using Manager Self-Services
is universally supported by Centralized
services and requires no settings.

We have moved the Data Validation for

Compensation Information and Recur-
ring Pay Components (MSS and History
UI) topic to the Implementing the Em-
ployment Compensation Data guide.

Changed Saving changes for Termination Details Terminating an Employment

using Manager Self-Services is univer-

sally supported by Centralized services
and requires no settings.

We have moved the Termination topic

to the Implementing and Managing the
Employment Lifecycle guide.

Changed We have split out the details about for- Forward Propagation in Job Informa-
ward propagaton for Job Information tion [page 226]
and Job Relationships and moved them
Forward Propagation in Job Relation-
to the Entity Information section.
ships [page 233]

Changed We have removed the Pension Payouts

information.

Changed Updated the topic about the new rule Rule Scenarios for Employee Central
scenario Trigger Rules for Off Cycle Core [page 140]
Event Batch.

Implementing Employee Central Core

336 PUBLIC Change History
1H 2023

Type of Change Description More Info

May 19, 2023

Changed We emphasized that Employee Central Enabling the Employee Central SOAP
SOAP APIs would be deprecated, and APIs [page 92]
updated the way to enable the APIs.

April 21, 2023

New You can now prevent users from deleting Preventing Deletion of Global Informa-
Global Information on the Editing UI of tion on Editing UI [page 195]
People Profile blocks.

New You can now create, manage, and moni- HRIS Sync Jobs [page 268]
tor scheduled jobs for HRIS Sync with
the tool Scheduled Job Managers in the
Admin Center.

New We have added additional information Concurrent Employment with Central-

about changes to entities in MSS ena-
ized Services
bled on Centralized services.

Changed We moved the topics about Data Mod- Data Models [page 26]
els, Foundation Objects, and Generic
Objects to the Configuration section. Foundation Objects [page 26]

MDF Foundation Objects [page 71]

Generic Objects [page 85]

Changed Saving changes on the Editing UI of Centralized Services in Employee Cen-

emergency contacts and contact infor- tral [page 299]
mation is universally supported by Cen-
tralized services and requires no set-
tings.

Changed Saving changes on the Editing UI of de- Centralized Services in Employee Cen-
pendents is supported by Centralized tral [page 299]
services as an Admin Opt-out feature.

Changed We have added additional information Picklist Configuration for Employee

about what the system considers as ac- Status and Job Relationship Type [page
tive or inactive employment. 266]

Changed We have removed the information about

sync order in HRIS Sync jobs as this in-
formation is irrelevant for person-based
HRIS Sync jobs.

Changed We have removed the Known Issues with

Picklists topic.

Implementing Employee Central Core

Change History PUBLIC 337
Type of Change Description More Info

Changed We have removed the topics about re-

tired functionality:

• Direct Deposit
• HRIS Propagation Configuration
Template
• Event Reason Derivation from XML

Implementing Employee Central Core

338 PUBLIC Change History
Important Disclaimers and Legal Information

Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:

• Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your
agreements with SAP) to this:

• The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.

• SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.

• Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering 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.

Videos Hosted on External Platforms

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

Beta and Other Experimental Features

Experimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by
SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use
the experimental features in a live operating environment or with data that has not been sufficiently backed up.
The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your
feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.

Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax
and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of
example code unless damages have been caused by SAP's gross negligence or willful misconduct.

Bias-Free Language
SAP supports a culture of diversity and inclusion. Whenever possible, we use unbiased language in our documentation to refer to people of all cultures, ethnicities,
genders, and abilities.

Implementing Employee Central Core

Important Disclaimers and Legal Information PUBLIC 339
www.sap.com/contactsap

© 2023 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form

or for any purpose without the express permission of SAP SE or an SAP
affiliate company. The information contained herein may be changed
without prior notice.

Some software products marketed by SAP SE and its distributors

contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for

informational purposes only, without representation or warranty of any
kind, and SAP or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP or
SAP affiliate company products and services are those that are set forth
in the express warranty statements accompanying such products and
services, if any. Nothing herein should be construed as constituting an
additional warranty.

SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.

Please see https://www.sap.com/about/legal/trademark.html for

additional trademark information and notices.

THE BEST RUN