SF EC Position Management en PDF

Implementation Guide | PUBLIC
Document Version: 2H 2022 – 2022-11-11
Implementing Position Management

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

Content
1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Change History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 What Is Position Management?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Terms "Manager" and "Supervisor". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Centralized Data Protection and Privacy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Basic Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Important Initial Settings for Position Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Configuration Settings for the User Interface, Imports and APIs in Position Management. . . . . . . . . . 12
Configuration Settings for the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Configuration Settings for Imports and APIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Permissions and Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Permissions Required for Position Management in General. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Permissions for the Position Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Creating Approval Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Defining The Position Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Fields in Position Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Custom Fields in the Position Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Defining Field Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Propagate Job-Related Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Defining Default Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Setting up Automatic Position Code Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Define Searchable Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Creating New Positions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.5 Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Define Synchronization of Common Position and jobInfo Fields for Position Reclassification
and Position Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Synchronization Between Position and Incumbent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6 Defining the Leading Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Scenarios for the Leading Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.7 Defining Fields to Be Copied. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.8 Setting up the Automatic Update Of “To Be Hired” Field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.9 Standard Hours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Determining Standard Weekly Hours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.10 Optimistic Locking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.11 Position Organization Chart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Setting Up The Position Organization Chart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

2 PUBLIC Content
Using URL Parameters in the Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Limit on Loading and Processing of Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3 Enhanced Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.1 Position Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Workflow for Position To Job Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
To whom shall the direct reports report if the manager leaves the position?. . . . . . . . . . . . . . . . . 87
Adapt Reporting Line If Position Hierarchy Is Changed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Synchronize position matrix relationships to job relationships of incumbents?. . . . . . . . . . . . . . . 91
Position Type Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Transition Periods in Position Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.2 Mass Copy of Positions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.3 Mass Changes to Positions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.4 Positions That Allow Multiple Incumbents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.5 Capacity Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.6 Forward Propagation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.7 Right to Return. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Position Management Settings for Right to Return. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.8 Matrix Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Synchronization between Matrix Relationships and Job Relationships. . . . . . . . . . . . . . . . . . . . 110
Synchronization Triggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Synchronization Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Restricting Access to Positions Based on Matrix Relationships. . . . . . . . . . . . . . . . . . . . . . . . . 114
3.9 Validations in Position Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Types of Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Validation Logic During Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Validation in Case of Forward Propagation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.10 Follow-Up Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Follow-Up Processes After Job History Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Follow-Up Processes After Termination Details Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Error Handling for Job History Import and Termination Details Import. . . . . . . . . . . . . . . . . . . . 121
Configuring the Result Email for Only Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.11 Event Reasons for Imports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Configure Event Reasons for Job History Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Configure Event Reasons for Termination Details Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.12 Moving Positions When Changing An Employee's Manager Assignment. . . . . . . . . . . . . . . . . . . . . 126
3.13 Showing Pay Range on Position. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
3.14 Business Rules in Position Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Rule Scenarios Available in Position Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Rule Functions in Position Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
3.15 Configuring the Position Default or Supervisor Default. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Content PUBLIC 3
3.16 Using the Check Tool to Solve Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Benefits of the Check Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Running Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Check Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Check Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Creating Product Support Tickets from the Check Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Exporting Configuration Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Using the Quick Fix Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Exporting a List of All Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
3.17 Automated Daily Hierarchy Adaptation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3.18 Transition Periods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
3.19 Terminating Employment on the User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
3.20 Transferring Reports in Case of Termination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
4 Integration of Position Management With Other Applications. . . . . . . . . . . . . . . . . . . . . . . . .152

4.1 Setting Up Integration with Recruitment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Validation for Position Job Requisition (Processing) Request. . . . . . . . . . . . . . . . . . . . . . . . . . .161
Viewing Job Requisitions in the Position Organization Chart. . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Mapping Job Requisition Picklist Values in OData Integration. . . . . . . . . . . . . . . . . . . . . . . . . . 165
Changing Integration with Recruiting from SF API Basis to New Basis. . . . . . . . . . . . . . . . . . . . 168
4.2 Integration with Succession Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.3 Event Generation with Position Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Configuring Position Management to Generate Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

4 PUBLIC Content
1 Introduction
Change History [page 5]

Learn about changes to the documentation for Employee Central Position Management.
What Is Position Management? [page 8]

Employee Central Position Management makes it easy for you to do a number of things.
Terms "Manager" and "Supervisor" [page 8]

Here's a note about the use of the terms "manager" and "supervisor" in our documentation and the
Position Management solution.
Centralized Data Protection and Privacy [page 8]

Data protection and privacy features work best when implemented suite-wide, and not product-by-
product. For this reason, they’re documented centrally.
1.1 Change History
Learn about changes to the documentation for Employee Central Position Management.
2H 2022
Type of Change Description More Info
Change We've overhauled the permission sec • Permissions Required for Position
tion of the guide.
Management in General [page
20]
• Permissions for the Position Object
[page 22]
Change We've renamed Functions for Position • Configuration Settings for the User
Management to Configuration Settings
Interface [page 12]
for the User Interface, Imports and APIs
in Position Management and split the in • Configuration Settings for Imports
formation into and APIs [page 18]
• Configuration Settings for the User

Interface
• Configuration Settings for Imports
and APIs
to increase readability.

Introduction PUBLIC 5
New We've added information about two Configuration Settings for the User In
configuration settings for the Manager terface, Imports and APIs in Position
Self-Service user interface, Use Management [page 12]
Company Filter for Positions in MSS Job
Information and History and Allow
Selection Only of Positions That Have
Status ‘To Be Hired’ in MSS Job
Information and Hire.
New We've added a note about the use of the Terms "Manager" and "Supervisor"
terms "manager" and "supervisor" in [page 8]
our documentation and the Position
Management solution.
Change We've overhauled the permission top • Permissions Required for Position
ics, Permissions Required for Position
Management in General [page
Management in General and Permis
20]
sions for the Position Object. You can
now find a link to Configuring Permis • Permissions for the Position Object
sions for an MDF User Role in both top [page 22]
ics with more detailed information
Configuring Permissions for an MDF
about how to set permissions.
User Role
New We've added information to Transition Transition Periods [page 148]

Periods that was part of a Knowledge
Base Article, How to Configure Transi
tion Period :
• For Transition period to overwrite

the check against multiple Incum
bent and against the FTE, the "Po
sition Controlled" flag on the posi
tion must be set to yes.
Changed We removed the New Data Model for

Right to Return and Data Protection
and Privacy topic from the guide since
this feature is now universal.
1H 2022
New We've added validations of position Validations in Position Management

fields when the employee's job informa [page 116]
tion history is changed.

6 PUBLIC Introduction
Change We've broken up the information about • Follow-Up Processes After Job His
Execute Position Processes During Job
tory Import [page 118]
History Import into
• Follow-Up Processes After Termi
• Follow-Up Processes After Job His nation Details Import [page 120]
tory Import
• Error Handling for Job History Im
• Follow-Up Processes After Termina port and Termination Details Im
tion Details Import port [page 121]
• Error Handling for Job History Im
port and Termination Details Im
port
to increase readability.
We've added information about the Job

Relationship Sync to Follow-Up Proc
esses After Job History Import.
New We've added a note saying that if work Event Generation with Position Manage
flows are configured on the position ob ment [page 170]
ject, the corresponding event is gener
ated only after the workflow has been
approved.
New We've added information about Follow- Follow-Up Processes After Termination
Up Processes After Termination Details Details Import [page 120]
Import.
New We've added information about Event Configure Event Reasons for Termina
Reasons for Termination Details Import. tion Details Import [page 125]
New We've added information about how to Configuring the Result Email for Only
configure the result email for only er Errors [page 123]
rors.
New We've added information about the cus Custom Fields in the Position Object
tom field limits in the position object. [page 28]
New We've broken up the information on Ma • Matrix Relationships [page 110]
trix Relationship and Synchronization
into different topics to increase reada
• Synchronization between Matrix
Relationships and Job Relation
bility.
ships [page 110]
• Synchronization Triggers [page
111]
• Synchronization Scenarios [page
112]
• Restricting Access to Positions
Based on Matrix Relationships
[page 114]
New We've added a note that the Matrix Re Synchronization between Matrix Rela
lationship to Job Relationship sync only tionships and Job Relationships [page
supports one of the relationship types. 110]

1.2 What Is Position Management?
Employee Central Position Management makes it easy for you to do a number of things.
You can:
• Create and maintain positions online with appropriate controls.

• Store and track position category (regular, part-time, intern, and so on), current incumbents, and previous
employees in that position.
• Use position control to track the headcount to suit your needs.
• For to-be-hired positions, you can open requisitions in Recruitment, with the required position information.
• Integrate Succession Management with Employee Central positions so that the successors are planned
based on the hierarchy and criticality of existing positions.
• Integrate with SAP Fieldglass to create job postings for contingent workers.
Related Information
List of Role-Based Permissions
1.3 Terms "Manager" and "Supervisor"
Here's a note about the use of the terms "manager" and "supervisor" in our documentation and the Position
Management solution.
 Note
We generally use the word manager in SuccessFactors Position Management to refer to the person who
directs a group of employees. However, SuccessFactors Employee Central often uses the term supervisor.
For example, the label for the manager-id field in Job Information is supervisor. Manager and supervisor are
basically the same thing.
1.4 Centralized Data Protection and Privacy
Data protection and privacy features work best when implemented suite-wide, and not product-by-product. For
this reason, they’re documented centrally.
The Implementing and Managing Data Protection and Privacy guide provides instructions for setting up and
using data protection and privacy features throughout the SAP SuccessFactors HXM Suite . Please refer to the
central guide for details.

8 PUBLIC Introduction
 Note
SAP SuccessFactors values data protection as essential and is fully committed to help customers
complying with applicable regulations – including the requirements imposed by the General Data
Protection Regulation (GDPR).
By delivering features and functionalities that are designed to strengthen data protection and security
customers get valuable support in their compliance efforts. However it remains customer’s responsibility to
evaluate legal requirements and implement, configure and use the features provided by SAP
SuccessFactors in compliance with all applicable regulations.
Related Information
Implementing and Managing Data Protection and Privacy

2 Basic Setup
There're some basics you need to set up before you can use more advanced features of Position Management.
 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.
Important Initial Settings for Position Management [page 10]

Make some important initial settings for Position Management.
Configuration Settings for the User Interface, Imports and APIs in Position Management [page 12]
Get an overview of configuration settings for the user interface and APIs in Position Management.
Defining the Leading Hierarchy [page 51]

Define a leading hierarchy to reduce the effort involved in keeping the position hierarchy and reporting
line hierarchy in sync.
Defining Fields to Be Copied [page 67]

Define which fields are copied from the current position when you create a new peer position or lower-
level position from the position organization chart.
Setting up the Automatic Update Of “To Be Hired” Field [page 68]

There is a feature you can use to automatically update the "To Be Hired" status for the position.
Optimistic Locking [page 76]

Learn about what happens if two users attempt to edit a position concurrently.
Position Organization Chart [page 77]

As HR admin responsible for Position Management, the position organization chart is your go-to point
for viewing and maintaining the position hierarchy at your company.
2.1 Important Initial Settings for Position Management
Make some important initial settings for Position Management.
Procedure
1. Enable Position Management.

a. Go to the Admin Center and choose Manage Employee Central Settings.
b. In the Others section, move the Position Management switch to On.
2. Add Position field to Succession Data Model.

10 PUBLIC Basic Setup
a. The Position field is new and must be added to your Succession Data Model if it’s not already there. To
do so, download the XML file from Provisioning under Succession Management Import/Export
Data Model .
 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.
b. Add the Position field in the jobInfo hris-element section. The default visibility is “none,” but if you want
to use the field, you need to set visibility to “both,” as shown below.
<hris-element id="jobInfo">
...
<hris-field max-length="256" id="position" visibility="both">
<label>Position</label>
<label xml:lang="de-DE"> Position </label>
<label xml:lang="en-GB"> Position </label>
...
</hris-field>
...
</hris-element>
As a result, you will be able to make permission settings for positions.
 Caution
If you uploaded a Succession Data Model, check that there is no Position-id field in the jobInfo hris-
element section. If there is, please change it to Position as shown above.
Related Information
Permissions Required for Position Management in General [page 20]

Basic Setup PUBLIC 11
2.2 Configuration Settings for the User Interface, Imports
and APIs in Position Management
Get an overview of configuration settings for the user interface and APIs in Position Management.
2.2.1 Configuration Settings for the User Interface
An overview of settings for the user interface in Position Management.
User Interface
Table 1: Interface: Manage Data
Configuration Setting Availability on the User Interface
Applying the leading Hierarchy (hierarchy adaptation) Yes. Configurable. Default: Yes; overruling through Position
Type possible.
Synchronization from Position to Job Information (pos2jo No

bInfo)
Synchronization from Position matrix relation to Job rela Yes. Configurable. Default: No.
tionship
Position Reclassification N/A
Position Transfer N/A
Setting "to be hired" flag after Position Assignment/Unas N/A

signment
Setting "to be hired" flag after FTE change of incumbent N/A
Setting "to be hired" flag after target FTE change of Position Yes. Configurable. Default: No
Table 2: Interface: Manage Positions
Type possible.
Synchronization from Position to Job Information (pos2jo Yes

bInfo)

tionship

signment
Table 3: Interface: Position Organization Chart (Position Quick Card)
Type possible.
Synchronization from Position to Job Information (pos2jo Yes. Configurable: always, never, popup.
bInfo)
tionship

signment
Table 4: Interface: Manager Self-Service
Applying the leading Hierarchy (hierarchy adaptation) Yes. Configurable. Default: Yes.
Synchronization from Position to Job Information (pos2jo Job info fields are propagated on change of the position
bInfo) through rule.
Synchronization from Position matrix relation to Job rela According to Position Management Settings when assigning
employee to a new position.
tionship

Position Reclassification Yes (event reason with Follow-Up Activity in Position Position
Reclassification)
Position Transfer Yes (event reason with Follow-Up Activity in Position Position
Transfer)
Setting "to be hired" flag after Position Assignment/Unas Yes. Configurable. Default: No.
signment
Setting "to be hired" flag after FTE change of incumbent Yes. Configurable. Default:No
Setting "to be hired" flag after target FTE change of Position N/A
Use Company Filter for Positions in MSS Job Information Yes. Configurable. Default:No
and History
 Note
If you want to filter positions by company in the Man
ager Self-Service (MSS) Job Information and History UI,
you need to set the value to Yes. If you select No, the po
sitions will still be filtered by company in the hire proc
ess.
Allow Selection Only of Positions That Have Status ‘To Be Yes. Configurable. Default:No
Hired’ in MSS Job Information and Hire
 Note
If you only want to allow the selection of positions that
have status To Be Hired in the Manager Self Service
(MSS) Job Information and Hire UI, you need to set the
value here to Yes. Even if you do this, all positions, what
ever their status, are selectable in the Job Information
History UI.
Table 5: Interface: Job Information History
Applying the leading Hierarchy (hierarchy adaptation) No
Synchronization from Position matrix relation to Job rela No

tionship
Position Reclassification No
Position Transfer No

Setting "to be hired" flag after Position Assignment/Unas No

signment
Setting "to be hired" flag after FTE change of incumbent No
Use Company Filter for Positions in MSS Job Information Yes. Configurable. Default:No
and History
 Note
If you want to filter positions by company in the Man
ager Self-Service (MSS) Job Information and History UI,
you need to set the value to Yes. If you select No, the po
sitions will still be filtered by company in the hire proc
ess.
 Note
The Job Information History UI is a kind of correction and expert admin tool. This means that the position
validation feature displays a warning, but, as an admin, you can still save. The "Current FTE vs. Target FTE"
check and the "Multiple Incumbents Allowed" checks are only performed when you insert a Job Information
record using MSS or the New Hire UI.
Table 6: Interface: Hire
Applying the leading Hierarchy (hierarchy adaptation) Yes (direct report section always available)
 Note
In case of internal hire, the hierarchy adaptation of the
previously assigned position is not executed by Position
Management.
Synchronization from Position matrix relationship to Job re According to Admin Center Position Management
lationship Settings when assigning employee to a new position.
Reclassification)

signment
Table 7: Interface: Rehire
Applying the leading Hierarchy (hierarchy adaptation) Yes (direct report section always available)
Synchronization from Position to Job Information (pos2jo Job information fields are propagated on change of the posi
bInfo) tion through rule.
Synchronization from Position matrix relationship to Job re Yes. Configurable. Default: No.
lationship
Reclassification)
signment
Table 8: Interface: Termination
Applying the leading Hierarchy (hierarchy adaptation) Only the position hierarchy can be applied.
Applying Position Type settings Not possible at this time.
Synchronization from Position to Job Information (pos2jo Job information fields are propagated on change of the posi
bInfo) tion through rule.
Synchronization from Position matrix relationship to Job re N/A.
lationship

Setting "to be hired" flag after Position Assignment/Unas Yes. Configurable. Default: No
signment
Table 9: Interface: Right to Return from Global Assignment or Leave of Absence
Applying the leading Hierarchy (hierarchy adaptation) Yes, for direct reports.
 Note
• When a user is unassigned from a position, their su
pervisor will not be changed.
• If the start or end date of the leave of absence (LoA)
or global assignment (GA) is changed, hierarchy
adaptation will not take place.
Synchronization from Position to Job Information (pos2jo N/A

bInfo)
Synchronization from Position matrix relationship to Job re Matrix relationship changes are not synchronized to job rela
tionship when reassigning the user to the original position
lationship
Position Reclassification Yes
Setting "to be hired" flag after Position Assignment/Unas Yes, if "to be hired" adaptation has been set up in Admin
signment
Center Position Management Settings.
Setting "to be hired" flag after Delete or End Global Assign Yes, if "to be hired" adaptation has been set up in Admin
ment
Center Position Management Settings.
If the leave of absence (LOA) or global assignment (GA) is al

ready over, the "to be hired" record for the position will not
be moved if the start/end date of the LOA or GA is changed.

2.2.2 Configuration Settings for Imports and APIs
A list of configuration settings for imports and APIs in Position Management.
Imports and APIs
Table 10: Position Import/MDF OData
Configuration Setting Availability for the Import or API
Applying the leading Hierarchy (hierarchy adaptation) Yes. Configurable. Default: Yes.
Synchronization from Position to Job Information (pos2jo Import: Yes. Configurable. Default: No.
bInfo)
You can use the technicalParameter = SYNC in the API. The
technicalParameters field must be set to editable in the Posi
tion object through Configure Object Definition.
 Tip
We recommend creating a user interface with
Configuration UI and setting the default screen to that
UI.
lationship

signment
Table 11: Job History Import
Applying the leading Hierarchy (hierarchy adaptation) Yes. Configurable. Default: No.
Synchronization from Position to Job Information (pos2jo Yes, when rules are executed during import. Configurable.
bInfo) Default: No.
lationship

Position Reclassification Yes. Configurable. Default: No.
Position Transfer Yes. Configurable. Default: No.
signment
Setting "to be hired" flag after FTE change of incumbent Yes. Configurable. Default: No.
Table 12: Job History Import with Hire Event Reason
Applying the leading Hierarchy (hierarchy adaptation) Yes. Configurable. Default: No.
bInfo) Default: No.
lationship
Position Reclassification Not possible at this time.
signment
Table 13: Job History Import with Event Reason Rehire
Applying the leading Hierarchy (hierarchy adaptation) Yes. Configurable. Default: No..
bInfo) Default: No.
Position Reclassification Not possible at this time.
signment

Table 14: Termination Details Import (OData EmpEmploymentTermination)
Applying the leading Hierarchy (hierarchy adaptation) Yes.
Synchronization from Position to Job Information (pos2jo N/A

bInfo)
Synchronization from Position matrix relation to Job rela N/A

tionship
Position Reclassification N/A.
signment
2.3 Permissions and Workflows
2.3.1 Permissions Required for Position Management in

General
Get an overview of the general permissions you need for Position Management in SAP SuccessFactors.
Generic MDF Objects
You need permissions to access a number of generic MDF objects to create, edit, and delete configuration and
transactional objects in Position Management. Refer to the Related Information for detailed instructions on
how to set them.
• Administrator Permissions Metadata Framework Configure Object Definitions

• Administrator Permissions Metadata Framework Manage Data
• Administrator Permissions Metadata Framework Configure Business Rules

• Administrator Permissions Metadata Framework Access to non-secured objects
Position Field in Job Information
To assign permissions for the Position field in Job Information, go to User Permissions Employee Central
Effective Dated Entities , and select the respective permissions to Create, Edit/Insert, Correct, and Delete. For
more information about Employee Central Effective Dated Entities, refer to the link given in Related
Information.
 Note
Position is only shown in this list if you have entered the position field in the Succession Data Model.
In addition, the permission must be granted to the target group. Refer to Enabling Permissions for Target Group
given in Related Information.
Using Position Management
To use Position Management, users must have the following role-based permissions:
Table 15:
Action Required Permission
Access position organization chart. Administrator Permissions Manage Position Access

Optional: User needs to display the position organization Position Organization Chart
chart for a specific date:
Administrator Permissions Manage Position Change
Display Date of Position Organization Chartt
Create up to 100 new positions by copying an existing posi Administrator Permissions Manage Position Mass
tion
Copy of Position in Position Organization Chart
Create and view position requisitions from the position or Administrator Permissions Manage Position Create
ganization chart
Requisition in Position Organization Chart
and
Administrator Permissions Manage Position View
Requisition in Position Organization Chart
Select a job requisition template when a job requisition or Administrator Permissions Manage Position Job
job requisition request is created in the position organization
Requisition Template in Position Organization Chart
chart
Move an employee's position when they get a new manager Administrator Permissions Manage Position Option
to move Position to New Supervisor on Job Info Change

Action Required Permission
Create new positions from the Position Organization Chart Administrator Permissions Manage Position Create
Position from Position Organization Chart
Make Position Management settings. Only roles with this Administrator Permissions Manage Position Access
permission can see the Position Management Settings entry
Position Management Settings in Admin Center
in the Admin Center.
The Manage Employee Files permission must also be set for Administrator Permissions Manage System Properties
users who have the Access Position Management Settings Manage Employee Files
permission.
Related Information
Configuring Permissions for an MDF User Role

Enabling Permissions for Target Group
Employee Central Effective-Dated Entities
2.3.2 Permissions for the Position Object
You can define the Position object as subject to permission checks so only certain users have access to it.
Prerequisites
Under Configure Object Definitions Take Action Make Corrections , in the Security section, the Secured
field of the object must be set Yes. You must also define a permission category, for example, Miscellanous
Permissions.
• User Permissions Miscellaneous Permission

• In the generic object definition, scroll down to the Security section, select Yes for the object and save your
changes. You must also define a permission category, for example, Miscellanous Permissions.
• Specify the target population for the other objects section. You can restrict the target population as you
want. By default, All is selected, which means that the permissions you granted for this role are valid for all
positions in the system.
• If you are using Matrix Relationships on the Position object, you can also restrict access to positions based
on the Matrix Relationships.
For more information about this configuration, refer to the Related Information section.

Related Information
Adding Security
2.3.2.1 Special Handling of the Create Permission
By default, granting the Create permission allows the user granted this permission to create any position in the
system. So, the target criteria are not respected for the Create permission.
If you want to respect the defined target criteria for the Create permission also, you need to set the Create
Respects Target Criteria flag to Yes for the Position object. You do this in the Admin Center by choosing
Configure Object Definitions .
With this setting, it's possible to realize, for example, the following requirement:
Managers need to be able to view all positions in the system but are allowed only to create new positions that
are below their own position.
Here's how you set this up:
1. Change the Position object definition and set the flag Create Respects Target Criteria to Yes
2. Create a new Permission role with Position permissions View Current and View History and grant this role to
all position as target criteria.
3. Create a new Permission role with Position permission Create and grant this role with position restriction
Include access to Position in the hierarchy below the Granted User’s Position with All levels.
 Note
The Create permission is only validated when the position is saved or you submit the workflow. If you don't
have permission to create the position, the system doesn't allow you to save or submit.
2.3.3 Creating Approval Workflows
You can use workflows to protect the Position object against changes.
Procedure
1. Create the foundation object Workflow that you want to use for Position.
2. Create a rule by going to the Admin Center and choosing Configure Business Rules.
• Rule Name, Rule ID, and Start Date.

• Scenario Rules for MDF Based Objects.
• Have Position as the base object and Workflow as the purpose.
• You can use the IF or ELSE-IF statement to specify which conditions must be fulfilled for the workflow
to be triggered.
• You can use the THEN statement to set the workflow you created in step 1 to the wfConfig field of the
Position.
3. Assign your rule to the event onSave of the position object definition. You do this in the Admin Center by
choosing Configure Object Definitions. For more information, look at the Configuration the Object Definition
section of the Implementing the Metadata Framework (MDF) documentation.
4. Set the Pending Data field in the Position object definition to "Yes", thereby ensuring that, once a workflow
is used, records are not visible in the system unless approved. Note: We strongly recommend this setting
for using workflows in positions.
5. If you want to group workflows of positions in the ToDo block by their own category, enter Position
Management Request in the ToDo Category field.
2.4 Defining The Position Object
2.4.1 Fields in Position Object
A table listing the most important fields in the Position object and explaining their purpose.
Table 16: Fields in Position Object
Field What it's for
mdfSystemEntityId This is a technical field that should not be set to visible.
mdfSystemRecordId This is a technical field that should not be set to visible.
mdfSystemProxyUser This is a technical field that should not be set to visible.
mdfSystemVersionId This is a technical field that should not be set to visible.
transactionSequence This is a technical field that can't be set to visible.
legacyPositionId This is a technical field that should not be set to visible.
technicalParameters This is a technical field that should not be set to visible.
internalId This is a technical field that should not be set to visible.
mdfSystemRecordStatus This is a technical field that should not be set to visible.

Field What it's for
code The position code is the unique identifier for the position.
You can have the system generate the code automatically.
Take a look at the Automatic Generation of Position Code
[page 32] documentation for more information on this fea
ture.
externalName This is the position title also shown in the position organiza
tion chart. It can be translated into other languages.
effectiveStatus The position status indicates whether this position is active

and can be staffed and used in processes. Setting a position
to inactive is not possible when, for example, the position
has an incumbent or active lower-level positions are availa
ble.
effectiveStartDate The date from which the position changes are effective in the
system.
effectiveEndDate This is a technical field that could be set to read only but
must never be set to editable.
type You can use position types to drive different behavior for po
sitions. Take a look at the Position Types [page 85] docu
mentation for more information on this feature.
positionCriticality This field is relevant for Succession Management only and

should only be set to visible if Succession Management is
used.
targetFTE The target FTE (full-time equivalent) expresses the amount

of accumulated FTE that may be assigned to this position. If
you want the system to control this capacity for overcharg
ing, please set the positionControlled attribute to True.
positionControlled This attribute controls whether the target FTE is checked

when an employee is assigned to this position. In addition,
the attribute triggers the stable headcount processing when
an employee is assigned to a new position during Position
Transfer or Position Reclassification.

Field What it's for
multipleIncumbentsAllowed This attribute controls whether the system allows the as
signment of more than one employee to this position at any
point in time.
 Note
Under certain conditions, it is possible to replicate
shared positions - meaning positions with multiple in
cumbents - from Employee Central. Take a look at the
Replicating Organizational Data from Employee Central
to SAP ERP (Integration Guide) for information on the
conditions.
vacant This field indicates whether anyone will be hired for this posi
tion. It is shown on the position organization chart if set to
True.
standardHours This is the standard field for the standard hours on job infor
mation and position and can be included in the synchroniza
tion between position and employee. In this case, the em
ployee's FTE value will be calculated based on the standard
hours inherited from the employee's assigned position.
description You can use this field to enter a description for the position.
positionTitle This is a deprecated field. Please use externalName instead.
criticality This field is relevant for Succession Management only and

used.
comment You can use this field to add comments.
incumbent This field is only relevant for Succession Management and

must always be set to invisible. In Employee Central Position
Management, the assignment between a position and the in
cumbent is made using the position field on Job Information.
changeReason This field is relevant for Succession Management only and

used.
jobCode This is the standard field for the job classification on job in
formation and position and can be included in the synchroni
zation between position and employee. When set, the job
classification can propagate other job-related fields. Take a
look at the Propagation Of Job-Related Fields [page 30]
documentation for more information on this feature.

Field What it's for
jobTitle This is the standard field for the job title on job information
and position and can be included in the synchronization be
tween position and employee.
jobLevel This is the standard field for the job level on job information
employeeClass This is the standard field for the employee class on job infor
tion between position and employee.
regularTemporary This is the standard field for the type of employment (regular
or temporary) on job information and position and can be in
cluded in the synchronization between position and em
ployee.
payGrade This is the standard field for the pay grade on job informa
tion and position and can be included in the synchronization
between position and employee.
company This is the standard field for the company on job information
businessUnit This is the standard field for the business unit on job infor
tion between position and employee.
division This is the standard field for the division on job information
department This is the standard field for the department on job informa
location This is the standard field for the location on job information
costCenter This is the standard field for the cost center on job informa
createdBy This field holds the user who created the position.
createdDate This field holds the date when this position was created.

Field What it's for
lastModifiedBy This field holds the user who last modified the position.
lastModifiedDate This field holds the date when this position was last modi
fied.
mdfSystemObjectType This is a technical field that should not be set to visible.
parentPosition This is the higher-level position for this position.
payRange This is a transient field, showing the pay range for a position.
Take a look at the Showing Pay Range on Position [page 127]
documentation for more information on this feature
positionMatrixRelationship This represents a relationship of this position to another po

sition of a specific job relation type. Take a look at the Matrix
Relationships [page 110] documentation for more informa
tion on this feature.
rightToReturn As of the Q1 2018 release, this field is not supported any

more. If you're still using the old data model for Right to Re
turn, we recommend that you migrate to the new data model
in the Upgrade Center.
2.4.2 Custom Fields in the Position Object
Here's a list of the limits on custom fields in the Position object.
You can create custom fields in the Position object to include additional information, according to your
business needs.
The Position object can have up to:
• 30 custom String fields

• 55 custom Number fields
• 20 custom Decimal fields
• 15 custom Date fields
For information on how to add fields to the Position object and how they are mapped to MDF data types, refer
to the link in the related information.
Related Information
Custom Field Limits on Pre-delivered and Custom MDF Generic Objects

Adding Fields

2.4.3 Defining Field Details
Define your own field labels if you don't want to use the default labels, and define the visibility of all the fields
you require.
Procedure
1. Go to the Admin Center and choose Configure Object Definitions.
2. Search for Position and select Take Action Make Correction .

3. Define the field labels if you don’t want to use the default labels, and define the visibility of all needed fields
by clicking Details of the corresponding field. If a field isn't needed for Employee Central, you must set the
visibility to Not Visible.
How you need to set the Incumbent field depends on whether you also use Succession Planning.
If you use… Set the Incumbent field to…
Position Management and Succession Planning Not Visible
Position Management only Not Visible
Succession Planning only Editable
The Source of Creation field indicates whether a position was created:

• By copying an existing position from the position organization chart.
• By import.
• As a new position during position reclassification or position transfer.
This field is invisible by default.
4. If you want to use the audit report feature, set the MDF Version History to Yes. You will then be able to
capture the MDF Audit data at an object level whenever any operations are performed on the records for an
object.
5. If you want to use the fields jobLevel, employeeClass or regularTemporary, create the MDF picklists
manually with exactly the same names. The external codes used for the MDF picklist values must be the
same as those defined in the csv file for the regular picklists jobLevel, employeeClass, and
regularTemporary. Otherwise, the synchronization between jobInformation and position will not work for
those fields. For more information about this step, refer to the link given in the Related Information section
regarding picklists.
6. Remember that, for any of the fields that use a picklist, the picklist values are usually displayed with
external codes. If you want to have the values displayed without these codes, choose Details and enter
displayPickListWithoutExternalCode in the uiFieldRenderer field.
7. Remember also that generic objects are, by default, displayed with external codes. If you want to have the
fields displayed without these codes, choose Details and enter displayGOWithoutExternalCode in the
uiFieldRenderer field.
8. More about picklists (see step 5 above). With cascading picklists you can restrict the value of a field based
on a previous selection. Take a look at Cascading Picklists in the Implementing the Metadata Framework
(MDF) guide for full information on how to use them.

Related Information
Defining Default Values [page 31]

Define Synchronization of Common Position and jobInfo Fields for Position Reclassification and Position
Transfer [page 35]
Fields in Position Object [page 24]
Picklists in SAP SuccessFactors
2.4.4 Propagate Job-Related Fields
You can specify that relevant jobCode fields are filled automatically when the user enters a jobCode when
creating or changing a position.
Context
To do so, you must define a rule and assign this rule to the jobCode field.
Procedure
1. Go to the Admin Center and choose Configure Business Rules.

2. Click Create New Rule, enter a rule ID, a rule name, select Position from the Base Object dropdown menu,
and select a suitable rule type.
3. Set up the rule as required. The following table shows the default set of common fields that can be filled
automatically. If the jobCode object and the Position object have more common custom fields, these fields
can be added here as well.
Position Field Equivalent JobCode Field
jobTitle jobCode.jobTitle
jobLevel jobCode.jobLevel
regularTemporary jobCode.isRegular
employeeClass jobCode.employeeClass
payGrade jobCode.grade
4. To assign the rule to the jobCode field in the Position generic object, go to the Admin Center and choose
Configure Object Definitions
5. Search for Position.
6. Click Take Action Make Corrections

7. Scroll down to the jobCode field and click Details.

8. Under Rules assign the rule you've just created.
2.4.5 Defining Default Values
You can define default values for fields in the position that are filled automatically each time a new position is
created.
Prerequisites
 Note
Alternatively, you can use the Default Value field on the object to set the FTE value. This does not require
setting up a rule. However, the Default Value you set this way will be global.
For more information about the default value, refer to Default Value entry in the table of the topic in the
Related Information section, Adding Fields.
If you need your FTE values to be localized, create a business rule by following these steps:
Procedure

2. Click Create New Rule, enter a rule ID, a rule name, select Position from the Base Object dropdown menu,
and select a suitable rule type.
3. Create the rule as required and save your entries.
To define that the FTE field always has the default value “1” and that the default value for the Company field
is always “Ace Germany”, create a rule as shown in the screenshot:

4. To add the rule to the position generic object, go back to the Admin Center and choose Configure Object
Definitions.
5. Search Position Take Action Make Corrections

6. Scroll down to the Rules section, and click Details.
7. Under initializeRules, enter the name of the rule you've just created.
Related Information
Adding Fields
2.4.6 Setting up Automatic Position Code Generation
If you activate this feature, you can have the system generate position codes for you, based on template
entries.
Procedure
Setting Up the Number Sequence

1. The first task is to set up the number sequence you want to use. Here's how:
a. Go to the Admin Center and choose Manage Sequence.
b. In the resulting screen, choose Admin Center Manage Sequence , then make these entries:
• An external name and an external code.
• The number at which the sequence should start.
 Note
This number can't be zero or a minus number, such as -1
• How big each step should be.
Defining the Rule

2. Now, you need to configure the business rule needed for autogenerating the external code. You do this in
the Admin Center too, by choosing Configure Business Rules.

This graphic shows an example of the entries you need to make for setting the external code:
• Rule ID
• Rule Name
• Base Object: This must be Position
• Rule Type
• Validate: This muste be Purpose
• The If condition must be as shown above.
In the Then condition, you can use the sequence object and set the external code. In the example, the
external codes will be generated as Position1, Position2, and so on. You can choose to use the text
template to create an external code that includes text, rather than only numbers. To enter text rather
than a numeric value, you can also choose Text and make the entry you need, like the text Position_%d
in the example.
• For the template, you can use the Format String Syntax from Java (see http: docs.oracle.com/
javase/7/docs/api/java/util/Formatter.html). If, for example, your sequence starts with 1, but the code
for the position will always be an 8-digit number starting with 1 and filled with zeros, you would use this
pattern: 1%07d.
Adding Rule to Position Object Definition
3. To add the rule to the Position object definition, go back to the Admin Center and choose Configure Object
Definitions. Assign the rule to the Save event.
Additionally, you must set the external code in the Position Object Definition to Read only.
Position External Code
4. Finally, you set the Is the Position External Code Auto Generated? to Yes on the General tab in Position
Management Settings.

2.4.7 Define Searchable Fields
You can define which fields of the Position object the system should take into account when you search for a
position.
Context
You might conduct such searches in, for example, the position organization chart or in the Position field on the
Job Information screen.
 Tip
The more searchable fields there are, the longer the search will take. So, we recommend that you only make
important fields searchable.
Procedure
2. Search for Position and select Take Action Make Corrections .

3. Scroll down to the bottom of the Object Definition screen and define searchable fields. If, for example, you
enter jobTitle as a searchable field, users can then type in a job title (such as "UI Designer") to find all
positions with the corresponding job title. If you enter department, users can type the name of a
department (such as "HR Recruiting") to see all the positions within that department.
2.4.8 Creating New Positions
Create new positions from Manage Positions or the position organization chart.
Context
 Restriction
The first position in the system can be created from Manage Positions, but we recommend you create it
from the position organization chart, from where you can then create any other positions you require. Do
not create positions from the Manage Data UI.

Procedure
1. To create the first position, choose Manage Positions.
2. Select Create New Position .

3. Enter all mandatory fields as well as other fields as you need them.
4. Save your entries.
5. Once you have created your first position, you can create any others you need from the position
organization chart.
Results
A new position is created.
2.5 Synchronization
2.5.1 Define Synchronization of Common Position and

jobInfo Fields for Position Reclassification and
Position Transfer
Define synchronization rules to specify which common fields between the Position generic object and the
jobInfo employment object are synchronized when changes are made in the Position object or the jobInfo
object.
Procedure
You can define:
• Which common fields are synchronized to the jobInfo employment object when changes are made in the
Position object.
• Which common fields are synchronized to the Position object when changes are made in the jobInfo
employment object. Note that this only applies to changes that the system regards as a position
reclassification or position transfer. To learn more about this, see Position Reclassification and Position
Transfer.
Related Information
Position Reclassification and Position Transfer [page 46]

2.5.2 Synchronization Between Position and Incumbent
Defining Synchronization Position to Job Information [page 36]

Define a rule to specify which common fields between the Position object and the Job Information
employment object are synchronized when changes are made in the Position object.
Defining Synchronization Job Information to Position [page 41]

Define a rule to specify which common fields between the Position object and the jobInfo employment
object are synchronized when changes are made in the jobInfo employment object that the system
regards as a position reclassification or position transfer.
2.5.2.1 Defining Synchronization Position to Job

Information
Define a rule to specify which common fields between the Position object and the Job Information employment
object are synchronized when changes are made in the Position object.
Context
This rule is triggered for back-end synchronization. Use the rule for the following use case:
• a position with incumbents is changed from the position organization chart or Manage Positions
• the user wants to update the incumbents‘ Job Information with the data from position fields defined for
synchronization.
 Note
If you want to trigger synchronization when you're importing positions, add the technicalParameters
column to your position import file. Enter SYNC as the value in the technicalParameters column for those
position records that are to trigger a synchronization to the Job Information object. When you define the
object, technicalParameters field must be set to editable but not visible on the UI.
• The system carries out synchronization on the effective start date of the corresponding position
record.
• When defining the position generic object, the technicalParameters field must still be set to Visible.
• For position imports, no workflow is triggered for Job Information because of the synchronization of
position to Job Information.
• Synchronization only takes place if the position is changed in the position organization chart using
Manage Position or is imported in a CSV file. Synchronization doesn't take place through an API.
• If any records in the mass change run contain an optimistic locking exception, then the whole batch is
rolled back. For more information, refer to Optimistic Locking [page 76]
• Let's consider multiple incumbents are allowed for a position. If the update of Job Information for one
user in the synchronization can’t be done during the mass import of positions, the entire batch is rolled
back to the state before the import.

• Let's consider the user changes the parent position and by doing so, they change the leading position
hierarchy. If in parallel, this changes position attributes that are synchronized to employee’s Job
Information, two records are created in Job Information.
 Restriction
It's not possible to modify job relationships in the position to Job Information sync rule that has been
created with the recommended Synchronize Position Changes to Incumbents rule scenario.
Procedure
1. Go to the Admin Center and select Configure Business Rules.

2. Select Create New Rule and the Synchronize Position Changes to Incumbents scenario.
3. Set up the rule as you require. Here's a screenshot, showing an example of fields that need to be
synchronized:
 Note
• Set this rule to only be triggered if a position is assigned to the Job Information (If condition in the
rule).
• If you don't use business rules for event reason derivation, you need to enter the event reason to be
used for updating the incumbents' Job Information records after position change. Go to Admin
Center Position Management Settings , and enter the event reason in the Event Reason for
Synchronization Incumbents after Position Change field.

 Restriction
The RAISE MESSAGE option isn't available for the rule on synchronizing position to Job Information.
The rule is created with the recommended Synchronize Position Changes to Incumbents rule scenario.
 Restriction
You're only allowed to use ‘THEN’ Action SET. In addition, the following Job Information fields must not
be part of the rule for Position To Job Information synchronization as using them can lead to serious
data inconsistencies:
• Any field of type Attachment
• Position
• Sequence number
• Workflow configuration
• Start date
• Event reason
• Full-time equivalent (FTE)
• Effective latest change
• Supervisor
• PositionCostAssignmentItems
The manager is set automatically based on the leading hierarchy and is never set by the
synchronization rule. Refer to the link about Define Leading Hierarchy in the related information for
more information.
Whenever you adapt an existing rule created with the recommended Synchronize Position Changes to
Incumbents rule scenario, the system checks whether one of these Job Information fields is used in the
rule. If it is, the system displays an error message.
4. Tell the system which rule it must trigger when common fields between position and Job Information must
be synchronized. Go to the Admin Center and select Position Management Settings. Enter the rule in the
Rule for Synchronizing Position to Job Info field.
There's a setting that governs how position changes can be synchronized with incumbent Job Information
using the position organization chart. You make this setting in the Admin Center under Position
Management Settings. The settings are on the Synchronization tab.
Make the setting in the Position Synchronization field, choosing one of these options:
• Never
If you choose this, no synchronization takes place.
• User Decision
If you choose this, a popup appears after every position change asking whether the incumbents must
be synchronized.
• User Decision If Required
If you choose this, a popup appears, but only if the position and incumbents aren’t in sync.
 Restriction
You can only make this selection if the rule for synchronizing position to Job Information doesn’t
include ELSE or ELSEIF statements.

• Automatic
If you choose this, synchronization takes place in the background.
If you want to use this rule for UI propagation, too, add the rule as onChange rule to the Position HRIS field
in the Succession Data Model or on BCUI. The onChange rule looks like this:
This means that the common fields between Job Information and position that you added to this rule are
filled with default values automatically if:
• The HR admin selects a position on the Add New Employee screen.
• The manager changes the position assignment of an employee under Employee Name → Action
"Change Job and Compensation Information" .
• The HR admin changes the position assignment of an employee through the history.
These values can be overwritten.
 Note
When position to Job Information synchronization runs, onSave rules are always triggered. These
include cross-entity rules where the following apply:
• The rule scenario, Cross-Entity Rule, must be defined for the cross-entity rule to be triggered by
position to Job Information synchronization.
• Job Information Model must be the base object of the cross-entity rule.
• In Manage Business Configuration, the cross-entity rule is defined as the onSave rule in Job
Information.
• In Details, the rule context is set to Position to jobInfo Sync = Yes.
Cross-entity rules only supported for the following entities:

• Job Information
• Compensation Information
• Pay Component Recurring
• Pay Component Non-Recurring
• Job Relationships
• Employment Details
We also recommend that you do not set or change the Event Reason field in the target entity as part of
your cross-entity rules. During rule execution, the event reason of the source entity is also used for the
changes in the target entity.

 Note
We advise you to keep objects in the business rule in sync with the hierarchy structure of these pay
scale objects:
• Pay Scale Area.
• Pay Scale Type.
• Pay Scale Group.
• Pay Scale Level.
If you want, you can swap the order in which Pay Scale Area and Pay Scale Type appear in the business
rule.
• Pay Scale Group.
• Pay Scale Level.
These fields are associated with each other. Let's consider someone updates the business rule
attached to the position to Job Information synchronization with the wrong order. In this case, the
fields aren't synchronized and it's possible that users are able to create inconsistent data.
The following conditions must be fulfilled:

• The position is staffed with at least one incumbent.
• The field that is changed on the position is defined in the rule for synchronization of position to Job
Information.
• The change leads to an update in the employee's Job Information. If this is the case, synchronization of
position to Job Information happens as described in the following table.
Insert Correct Delete
Position organization chart New record New record No impact

Edit
Manage Position New record New record No impact
Manage Data No impact No impact No impact
Import (with technical pa New record New record No impact

rameter "SYNC")
 Note
• New records are only created on the Job Information if there are changes to the previous record.
• Let's consider the position and the Job Information are out of sync. In this case, all relevant
changes of fields defined in the rule for synchronization of position to Job Information are
synchronized to the Job Information whenever a position field is changed.
• The Position to Job Information sync supports XML workflows through centralized services .
Task overview: Synchronization Between Position and Incumbent [page 36]

Related Information
Defining Synchronization Job Information to Position [page 41]

Workflow For Synchronizing Position To Job Information [page 41]
Centralized Services for Employee Data Imports
Defining the Leading Hierarchy [page 51]
2.5.2.1.1 Workflow For Synchronizing Position To Job

Information
If you want to use a workflow scenario for the changes to job information arising after a position change, you
need to set up position types. Take a look at the Position Types documentation for details.
Related Information
Position Types [page 85]
2.5.2.2 Defining Synchronization Job Information to

Position
Define a rule to specify which common fields between the Position object and the jobInfo employment object
are synchronized when changes are made in the jobInfo employment object that the system regards as a
position reclassification or position transfer.
 Note
The system does not trigger Job Information to Position object synchronization when you create a Leave of
Absence. The system doesn't regard this as a position reclassification or position transfer.
For more information see Position Reclassification and Position Transfer given in the Related Information.
Note that synchronization only takes place in the following cases:
• The manager changes the job information under Employee Name → Action "Change Job and Compensation
Information" or Manage Positions. In the hiring process, the position reclassification and position transfer
can be configured. Note that synchronization is not carried out when changes are made from the Job
Information History.
• A value was maintained in the Follow-Up Activity on Position field for the event reason that is used for the
job info change.
• A position is maintained both in the “old” job info record and in the “new” job info record and the position
wasn't changed manually.

• When job information is changed during hire or rehire.
To specify which common fields are synchronized when changes are made in the jobInfo object that the system
regards as a position reclassification or position transfer, follow this sequence:
For information on this step... See the following task...
Step 1: Define a rule Define Rule
This rule is triggered whenever the system is to treat an action performed under
Employee Name → Action "Change Job and Compensation Information" as a position
reclassification or position transfer.
Step 2: Change the visibility of the Change Visibility of implicit-position-action Field

implicit-position-action field
If you want to use the implicit-position-action field, you need to set the visibility to
"both” in the Corporate Data Model for the element Event Reason. The label of the
field is Follow-Up Activity in Position.
Step 3: Check and upload master Upload Employee Central Master Picklist
Employee Central picklist
Check if the Employee Central master picklist in your system contains the values
Position Reclassification and Position Transfer for the implicit-position-action field on
the screen. If not, upload the latest master Employee Central picklist.
Step 4: Set the Follow-Up Activity in Set Follow-Up Activity in Position Field
Position field to Position
The follow-up activities Position Reclassification or Position Transfer are triggered for
Reclassification or Position Transfer
all event reasons in which you set this field.
in event reasons
 Note
You should keep objects in the business rule in sync with the hierarchy structure of these pay scale objects:
• Pay Scale Area

• Pay Scale Type
 Note
If you want, you can swap the order in which Pay Scale Area and Pay Scale Type appear in the
business rule.
• Pay Scale Group

• Pay Scale Level
These fields are associated with each other. That means that, if someone updates the business rule that is
attached to synchronization of position to job information with the wrong order, the fields are not
synchronized. It's possible that users will thus be able to create inconsistent data.
 Note
A direct synchronization is triggered from job information to position when fewer than 5 job information
records are imported. Otherwise, a scheduled job is created.

Parent topic: Synchronization Between Position and Incumbent [page 36]
Related Information
Defining Synchronization Position to Job Information [page 36]

Define Rule [page 43]
Change Visibility of the Implicit-Position-Action Field [page 45]
Set Follow-Up Activity in Position Field [page 48]
2.5.2.2.1 Define Rule
Define a rule to regulate synchronization of the job information to positions.
Context
Note that this rule is not triggered when an employee’s history is changed.
Procedure

2. Select Create New Rule and the Synchronize Incumbent's Changes to Position scenario.
3. Set up the rule as you require.
When defining the rule, there are some things you need to bear in mind:
• Only the fields configured in the rule are used to search for a matching position for position
reclassification and position transfer.
• If the system doesn't find a matching position and creates a new position for position reclassification
and position transfer, values are automatically assigned to the fields configured in the rule. This means
that if, for example, the costCenter field is not defined in the rule, the value for the costCenter field
from the jobInfo object will not be assigned to the new position.
• If an existing position is updated for position reclassification, only the fields configured in the rule are
updated.
 Note
The following screenshot shows an example of fields that should be synchronized:

 Note
The rule should only be triggered if a position is assigned to the job info.
 Note
As of the 2H 2020 release, you can't include the following in rules:

• Matrix relationships
• Right to return composite
• Position Type
• wfConfig
• To Be Hired
• Source of Creation
• Any Attachments
• Subject To Position Control
As of the 2H 2021 release, you can't include the following in rules:

• PositionCostAssignmentItems
If you have used any of these in earlier releases, you can continue to use them, but if you now try to
change them, the system displays an error message.

 Note
You should keep objects in the business rule in sync with the hierarchy structure of these pay scale
objects:
• Pay Scale Area
• Pay Scale Type
 Note
If you want, you can swap the order in which Pay Scale Area and Pay Scale Type appear in the
business rule.
• Pay Scale Group

• Pay Scale Level
These fields are associated with each other. That means if someone updates the business rule that is
attached to the Position to JobInfo sync with the wrong order, the fields will not be synced and it's
possible that users will be able to create inconsistent data.
4. To tell the system which rule to trigger when common fields between jobInfo and Position must be
synchronized, go to the Admin Center and choose Position Management Settings.
5. Assign the rule you’ve just created to Rule for Synchronizing Position after Job Information Change.
 Note
If you don't use business rules to derive event reasons, you must select two event reasons on the
Position Management Settings screen. The first event reason is then used when a new employee is
hired and assigned to a position with direct reports at the lower-level position. These direct reports are
then automatically assigned to the new employee and their employee records are changed. The second
event reason is used when you change a position from the position organization chart and decide to
update the employee records by clicking Yes on the Synchronize Incumbents popup window.
2.5.2.2.2 Change Visibility of the Implicit-Position-Action

Field
To use the implicit-position-action field, you need to set its visibility.
Context
The implicit-position-action field controls which follow-up activities [page 48] are required if job information is
changed with this event reason. To use it, you need to set visibility to "both” in the Corporate Data Model.
The default label to be shown on the screen is Follow-Up Activity in Position.

Procedure
1. Download the XML file from Provisioning under Import/Export Corporate Data Model.
 Remember
Support.
2. Change the visibility of the implicit-position-action field in the eventReason HRIS element section as shown
below:
<hris-element id="eventReason">
<hris-field max-length="32" id="implicit-position-action"
visibility="both">
<label>Follow-Up Activity in Position</label>
...
<picklist id="positionActionType"/>
</hris-field>
</hris-element>
2.5.2.2.3 Position Reclassification and Position Transfer
Sometimes, it's necessary to reclassify or transfer positions.
When is a position reclassification or position transfer required?
Activity System Behavior
A manager makes changes under Employee Name → Action Position reclassification or position transfer
"Change Job and Compensation Information".
Job information changes are made (new job, new depart Position reclassification
ment, and so on).
The manager changes. Position transfer
 Note
If you initially set or change a position on the Job Information Manager Self-Service or through Job History
import (OData API), the system doesn't trigger position reclassification or position transfer. In this case,
only the Job information is saved. The system only triggers reclassification when you hire an employee
through the Add New Employee user interface.
In Internal Hire, the system also triggers reclassification and transfer if the position ID changes.

What does the system do when a position reclassification is required?
The system reacts differently depending on whether more than one employee is assigned to the position
(shared position):
If only one employee is assigned at a time If more than one employee is assigned (shared position)
The system changes the assigned position based on the Job The system does not change the position. By default, the
Information to Position Sync rule. system first searches for a matching position with status To
Be Hired below the parent position of the position to which
the employee is assigned. If it doesn’t find a position, it cre
ates a new position below this parent position and assigns
the employee to this new position. This does not affect direct
reports and lower-level positions.
Note that if a new position is created, it is created with the

current FTE value of the employee assigned to the matching
position.
 Note
• The system matches only the fields that are config-
ured in the Job Information to Position Sync rule.
• The new position is created with the same attrib
utes as the original position and updated with job
information values as defined in the Job Informa
tion to Position Sync rule.
 Note
The new position is created with the same attributes as the original position and updated with job
information values as defined in the Job Information to Position Sync rule.
What does the system do when a position transfer is required?
The system reacts the same way regardless of whether one employee is assigned to the position or more
employees are assigned to it.
By default, the system first searches for a matching position with status To Be Hired below the new manager's
position. If it finds one, it assigns the employee to this position.
If the system doesn’t find a suitable position, it creates a new position below the new manager's position and
assigns the employee to this position. Note that the position left behind doesn't get status To Be Hired and the
new position is created without the status To Be Hired.
Note that if a new position is created, it's created with the current FTE of the employee assigned to the
position.
If direct reports were assigned to the transferred employee, these direct reports are assigned to the employee’s
previous manager. Lower-level positions are not changed.

2.5.2.2.3.1 What can you do if you don't want to search for an
existing position?
Speed the process of creating a new position when needed.
Procedure
• Position Reclassification Required

• If you want the system to create a new position straight away and not to search for an existing position with
status To Be Hired, proceed as follows:
a. Go to the Admin Center and choose Position Management Settings. Then go to the Synchronization
tab.
b. In the Search for Position in Position Reclassification field, select No.
• Position Transfer Required
• If you want the system to create a new position straight away and not to search for an existing position with
status To Be Hired, proceed as follows:
a. Go to the Admin Center and choose Position Management Settings. Then go to the Synchronization
tab.
b. In the Search for Position in Position Transfer field, select No.
2.5.2.2.3.2 Set Follow-Up Activity in Position Field
Procedure
1. Go to the Admin Center and choose Manage Organization, Pay and Job Structures.
2. Search for the event reason for which you want the system to carry out a position reclassification or a
position transfer.
3. Choose Insert New Record.
4. In the popup window, enter the date when you want the changes to take effect and choose Proceed.
5. Set the Follow-Up Activity in Position field to Position Reclassification or Position Transfer as required.
6. Save your changes.
7. Repeat steps 2-6 for all event reasons for which you want the system to carry out a position reclassification
or a position transfer.
Based on the event reasons that are derived from business rules or that you have defined yourself, a
position reclassification or position transfer takes place when a manager makes changes under Employee
Name → Action "Change Job and Compensation Information" .

 Note
If any errors occur while the position is being processed, you'll receive an email with an error code. To
view the details of exactly what went wrong, go to Admin Center Manage Data Import Queue
Monitor and enter the code from the mail.
You can review the error message items one by one and check whether you can correct the error
manually. If so, you can manually initiate the reprocessing of the failed record by changing the Action of
the monitor to Import Resend and saving the monitor.
If the system can now process the failed records successfully, the complete monitor is deleted and a
success mail is sent. If there are still errors, the monitor is updated with the new error information and
another error mail is sent.
2.5.2.2.4 Define Stable Headcount Area
If you switch on the positionControlled field, you can define the level on which the headcount must remain
stable when a position transfer or position reclassification takes place and the system searches for a suitable
position or creates a new one.
Procedure
1. To define a stable headcount area, go to the Admin Center.

2. Go to Position Management Settings and open the Synchronization tab.
3. In the Stable Headcount Area for Position Control Mode dropdown menu, select the value as required.
2.5.2.2.4.1 Scenarios
A variety of scenarios are possible for handling the FTE value in the context of stable headcount areas.
When this activity takes place... The system deals with FTE value as follows:
Position reclassification: matching position found If an employee is assigned to a shared position, the position
is not changed. Instead, the system checks if a matching po
sition that has status To Be Hired exists below the current
parent position and assigns the employee to this position.

Position reclassification: new position created In a position reclassification activity, the system creates a
new position if no matching position was found or the cus
tomer defined that a new position is always to be created.
The following scenarios are possible:
• Reclassification within stable headcount area

If the employee is assigned to a newly created position
and both the position left behind and the “receiving” po
sition belong to the same stable headcount area, the
FTE value of the position left behind is reduced by the
transferred employee’s current FTE value. Note that a
position’s FTE value is never negative. If automatic re
duction results in a negative FTE value, the FTE value is
set to 0.
• Reclassification outside stable headcount area
If the employee is assigned to a newly created position
and the position left behind and the “receiving” position
don't belong to the same stable headcount area, the
FTE value of the position left behind isn't reduced.
Position transfer: matching position found In a position transfer, the system first checks if a matching
position is found below the new manager’s position. The fol
lowing scenarios are possible:
• Transfer within stable headcount area

If the employee is transferred to an existing position be
low the new manager and both the position left behind
and the “receiving” position belong to the same stable
headcount area, the FTE value of the position left be
hind isn't reduced.
• Transfer outside stable headcount area
If the employee is transferred to an existing position be
low the new manager and the position left behind and
the “receiving” position don't belong to the same stable
headcount area, the FTE value of the position left be
hind isn't reduced either.

Position transfer: new position created In a position transfer, the system creates a new position be
low the new manager’s position if no matching position was
found or the customer defined that a new position is always
to be created. The following scenarios are possible:
• Transfer within stable headcount area

If the employee is transferred to a newly created posi
tion below the new manager and both the position left
behind and the “receiving” position belong to the same
stable headcount area, the FTE value of the position left
behind is reduced by the transferred employee’s current
FTE value.
• Transfer outside stable headcount area
If the employee is transferred to a newly created posi
tion below the new manager and the position left behind
and the “receiving” position don't belong to the same
stable headcount area, the FTE value of the position left
behind isn't reduced.
2.6 Defining the Leading Hierarchy
Define a leading hierarchy to reduce the effort involved in keeping the position hierarchy and reporting line
hierarchy in sync.
Context
Changes made to the leading hierarchy are automatically made to the other hierarchy.
 Note
If you use a position that allows multiple incumbents as a parent position and assign multiple employees to
it, the system will assign a supervisor to all incumbents assigned to the corresponding child positions
randomly.
You can also opt to have no leading hierarchy. You should do this if you don't want to use hierarchy adaptation,
meaning that neither the position hierarchy nor the reporting line is changed when the other hierarchy is
changed.
 Note
SAP SuccessFactors recommends that the leading hierarchy be set to the Position Hierarchy, to reduce
effort involved in keeping the hierarchies in sync. Changes made to the position hierarchy are automatically
made in the reporting hierarchy.

Procedure
1. To define a leading hierarchy, go to the Admin Center.

2. Choose Position Management Settings.
3. In the Leading Hierarchy dropdown menu on the Hierarchy Adaptation tab, select the value required.
 Note
• By default, the position hierarchy is the leading hierarchy. We recommend that you keep it this way,
as many Position Management functions are designed with the assumption that the position
hierarchy is the leading one.
• You also have the option of suppressing the supervisor/position defaulting in hire, MSS, or history.
To do this, choose No in the Default The Supervisor Or The Position In Hire, MSS Job Information
And History field.
For information on a feature you can use to have the system synchronize hierarchies for you, see the
Automated Daily Hierarchy Adaptation [page 145] documentation.
 Note
When you transfer multiple employees of child positions to a new manager, the number of employees
might exceed the threshold specified in the Admin Center under Position Management Settings
Hierarchy Adaptation Threshold for running Adoption of Reporting Line and Job Relations as a job .
 Restriction
For performance reasons, you must set the Threshold for running Adoption of Reporting Line and
Job Relations as a job to a number between 5 and 20.
If you are using business rules to derive event reasons and a threshold is defined for the hierarchy
adaptation, you need to define the event reason to be used for the hierarchy adaptation in the job. To
do this, go to the Admin Center and choose Company System and Logo Settings Default Event
Reason to use when processing direct subordinates and job relationships offline .

2.6.1 Scenarios for the Leading Hierarchy
Here, we examine the possible leading hierarchy scenarios.
The following scenarios are possible:
Action Leading Hierarchy System Behavior Comment
Change Position hierarchy The manager of all employees assigned to the n/a
the parent changed position is changed. This means that

position in the system determines the next available man
the posi ager from the changed position hierarchy and
tion or the incumbents of the changed position report
ganization to this manager. If there isn’t a manager, the in
chart, or cumbents no longer report to any manager.
when im
Reporting hierarchy The reporting hierarchy isn’t changed. This n/a
porting
positions. means that the position hierarchy is now differ-
ent from the reporting hierarchy.
Change Position hierarchy The position hierarchy isn't changed. This n/a
the man means that the position hierarchy is now differ-

ager in the ent from the reporting hierarchy.
employ
ee’s job in
formation
(under
Employee
Name →
Action
"Change
Job and
Compensa
tion
Informatio
n") but
this
change
doesn’t
lead to a
new posi
tion

Reporting hierarchy The position hierarchy is adjusted as follows: n/a
• The parent position of the changed employ

ee’s position is changed. The new parent
position will be the new manager’s position.
If the new manager doesn’t have a position,
the employee’s position will no longer have
any parent position. The same applies if the
manager is changed to No Supervisor.
• If the employee’s position is not a position
with multiple incumbents (or a regular
position), all lower-level positions will stay
with the position.
• If the employee’s position is a shared posi
tion, a new position is created (based on
the existing one) below the new manager’s
position.
 Note
If the field Search for Position in
Position Reclassification is set to Yes in
the position management settings,
then the system searches for a match
ing position first.
The lower-level positions whose incum

bents report to the changed employee will
be transferred to the newly created posi
tion.

Change Position hierarchy Effects on the user interface: When the admin *1 Direct reports of the
the posi selects a position, the Supervisor field is filled changed employee mean
tion in the automatically with the next available manager in those incumbents in posi
employ the position hierarchy. tions below the changed em
ee’s job in ployee’s position who ac
The direct reports *1 of the changed employee
formation tually report to this changed
will report to the employee's previous manager
(under employee (this means, the
*2 irrespective of whether the previous position
Employee changed employee is main
was a shared position or not. If there isn’t any
Name → tained in the manager field of
manager in the position hierarchy, the incum
Action the their job information re
bents won’t report to any manager (anymore).
"Change cords).
Job and All incumbents of the lower-level positions of
*2 The employee’s previous
Compensa the changed employee's newly assigned posi
manager is not necessarily
tion tion report to the changed employee - provided
the actual supervisor who is
Informatio that this position doesn’t have any incumbents
maintained in the Supervisor
n"). yet. *3 If the position already has other incum
field of the employee’s job in
bents, only those incumbents of lower-level po
formation record. It’s the pre
sitions who don't report to any of these incum
vious manager according to
bents will report to the changed employee.
the position hierarchy, but
ideally the position hierarchy
and the reporting hierarchy
are in sync. If the hierarchies
aren’t in sync (that is, the
manager maintained in the
Supervisor field is not the in
cumbent of the higher-level
position of the employee’s
previous position), the sys
tem determines the manager
based on the position hierar
chy.
*3 To whom the direct re

ports should report when the
changed employee leaves the
position can be configured
differently from the default
system behavior with the
help of position types, or you
can use one of these options:
• To no manager
• To another incumbent
on the position (if the
position has other in
cumbents)

Reporting hierarchy Effects on the user interface: *4 For each lower-level posi
tion of the previous position,
• When the administrator selects a manager,
the system checks if all in
the Incumbent of Parent Position field is fil-
cumbents assigned to this
led automatically and the Position field is
lower-level position report to
filled automatically with a suitable position.
the changed employee. Only
• When the administrator selects an em
in this case will the lower-
ployee in the Incumbent of Parent Position
level position become the
field, the Supervisor field is filled automati
lower-level position of the
cally and the Position field is filled automat
changed employee’s newly
ically with a suitable position.
assigned position.
If the employee’s previous position wasn’t a
shared position, all lower-level positions are
transferred to the employee’s newly assigned
position except positions without any incum
bent.
If the position already has other incumbents,

only the incumbents of the lower-level positions
who don't report to any of these incumbents re
port to the changed employee.
If the employee’s previous position was a

shared position, the lower-level positions
whose incumbents report to the changed em
ployee are transferred to the employee’s newly
assigned position. Positions without an incum
bent are not moved.*4
Hire a new Position hierarchy Effects on the user interface: n/a
employee
• When the administrator selects a position,
and assign
the Supervisor field is filled automatically
to a posi
with the next available manager in the posi
tion.
tion hierarchy.
• The administrator can decide if all incum

bents assigned to the lower-level positions
of the selected position should report to
the new hire or not.

Reporting hierarchy Effects on the user interface: n/a
• When the administrator selects a manager,

the Incumbent of Parent Position field is fil-
led automatically and the Position field is
filled automatically with a suitable position.
• When the administrator selects an em
ployee in the Incumbent of Parent Position
field, the Supervisor field is filled automati
cally and the Position field is filled automat
ically with a suitable position.
• The administrator can decide if all incum
bents assigned to the lower-level positions
of the selected position should report to
the new hire or not.

Position Position hierarchy The system always searches for a position be *5 Direct reports of the
assign low the current parent position. changed employee means
ment those incumbents in posi
The direct reports of the changed employee *5
changed tions below the changed em
report to the employee's previous manager. *6
in position ployee’s position who ac
If there isn’t a manager in the position hierarchy,
reclassifi- tually report to this changed
the incumbents no longer report to any man
cation be employee (this means, the
ager.
cause the changed employee is main
previous All incumbents of the lower-level positions of tained in the Supervisor field
position the changed employee’s newly assigned posi of their job information re
was a tion will report to the changed employee - pro cords).
shared po vided that the position that was found doesn’t
sition. An have any incumbents yet.
existing
*7 If the position already has other incumbents, the actual manager main
position
only those incumbents of lower-level positions tained in the Supervisor field
was
who don't report to any of these incumbents will of the employee’s job infor
found.
report to the changed employee. mation record. It’s the previ
ous manager according to
chy.
*7 To whom should the direct

reports report? when the
differently from the default
• To no manager
on the position (if the
position has other in
cumbents)

Reporting hierarchy The system always searches for the position be *8 For each lower-level posi
low the current parent position. tion of the previous position,
The lower-level positions whose incumbents re
port to the changed employee are transferred to
the position that was found.*8
assigned position.

Position Position hierarchy The system always creates the position below *9 Direct reports of the
assign the current parent position. changed employee means
will report to the employee's previous manager.
*10 If there isn’t any manager in the position hi
reclassifi- tually report to this changed
erarchy, the incumbents will no longer report to
cation be employee (this means, the
any manager. *11
cause the changed employee is main
previous tained in the Supervisor field
position of their job information re
was a cords).
shared po
sition. A
new posi
the actual manager who is
tion was
created.
formation record. It’s the pre
vious manager according to
chy.

differently than the default
help of position type, or you
• To no manager
on the position, provide
that the position has
other incumbents.

Reporting hierarchy The system always creates the position below *12 For each lower-level posi
the parent position. tion of the previous position,
The lower-level positions whose incumbents re
port to the changed employee will be transfer
red to the newly created position. *12
assigned position.

Position Position hierarchy The system always searches for a position be *13 Direct reports of the
assign low the manager's position. changed employee means
will report to the employee's previous manager
*14 irrespective of whether the previous posi
transfer. tually report to this changed
tion was a shared position or not. If there isn’t
An exist employee (this means, the
any manager in the position hierarchy, the in
ing posi changed employee is main
cumbents will no longer to any manager. *15
tion was tained in the Supervisor field
found. All incumbents of the lower-level positions of of their job information re
the changed employee's newly assigned posi cords).
tion will report to the changed employee - pro
vided that the position that was found doesn’t
have any incumbents yet.
If the position already has other incumbents, maintained in the Supervisor
only those incumbents of the lower-level posi field of the employee’s job in
tions who don't report to any of those incum formation record. It’s the pre
bents will report to the changed employee. vious manager according to
cumbent of the parent posi
tion of the employee’s previ
ous position), the system de
termines the manager based
on the position hierarchy.

• To no manager
on the position, provided
other incumbents.

Reporting hierarchy The system always searches for a position be *16 For each lower-level posi
low the manager’s position. tion of the previous position,
If the employee’s previous position was not a
shared position, all lower-level positions are
transferred to the position that was found.
If the employee’s previous position was a in this case will the lower-
shared position, the lower-level positions level position become the
whose incumbents report to the changed em lower-level position of the
ployee are transferred to the position that was changed employee’s newly
found. *16 assigned position.

Position Position hierarchy The system always creates the position below *17 Direct reports of the
assign the manager's position. changed employee means
Direct reports of the changed employee *17 will
report to the employee's previous manager *18
in position ployee’s position, who ac
irrespective of whether the previous position
transfer. A tually report to this changed
was a shared position or not. If there isn’t any
new posi employee (this means, the
manager in the position hierarchy, the incum
tion was changed employee is main
bents will no longer report to any manager. *19
created. tained in the Supervisor field
of their job information re
cords).

formation record. It is the
previous manager according
to the position hierarchy, but
chy.

• To no manager
on the position, provided
other incumbents.

Reporting hierarchy The system always creates the position below *20 For each lower-level po
the manager’s position. sition of the previous posi
tion, the system checks if all
If the employee’s previous position was not a
incumbents assigned to this
shared position, all lower-level positions will be
transferred to the newly created position.
If the employee’s previous position was a in this case will the lower-
shared position, the lower-level positions level position become the
whose incumbents report to the changed em lower-level position of the
ployee will be transferred to the newly created changed employee’s newly
position. *20 assigned position.

Transfer Position Hierarchy The direct reports will report to the manager of The direct reports won't re
or termi the manager who is transferred or whose em port to the peers of the man
nate the ployment is terminated. ager who is transferred or
employ whose employment is termi
ment of a nated.
manager
who:
1. has
lower
-level
posi
tions
with
direct
re
ports
and
2. is as
signe
d to a
posi
tion
to
which
other
in
cum
bents
are
as
signe
d.
(mul
tiple
in
cum
bents
al
lowed
)
Change None Neither the Supervisor field nor the Position n/a
the posi field is automatically filled when an employee is

tion in the selected in the Incumbent of Parent Position
employ field.
ee's job in
However, the Supervisor field is filled automati
formation.
cally with the next available manager in the posi
tion hierarchy when the position is selected.

Change None Neither the Incumbent of Parent Position field n/a
the man nor the Position field is filled automatically when

ager in the a manager is selected
employ
ee's job in
formation
Enter a re None If a new position has to be created in the context n/a
classifica of the position reclassification or position trans
tion or fer, the new position is created below the man
transfer. ager's position.
 Note
The default setting is for the hierarchy not to be adapted if you carry out a Job Information import, but you
can switch adaptation on. Take a look at the Follow-Up Processes After Job History Import [page 118]
documentation for more information.
2.7 Defining Fields to Be Copied
Define which fields are copied from the current position when you create a new peer position or lower-level
position from the position organization chart.
Context
 Note
Do not copy the Higher-Level Position field from Source Position to New Position. The higher-level position is
derived from the position hiearchy when you create peer positions or lower-level positions in the position
organization chart.
When fields are copied, the permission settings are kept, meaning if permissions for a field on the original
position were restricted, then those restrictions will be kept in the rule. However, the system will only
validate these permissions setting when the position is saved.
Procedure
1. To define which fields are copied from the current position, go to the Admin Center.

2. Select Configure Business Rules.
3. Choose Create New Rule and select the Default Position Attributes in Position Organization Chart scenario.
4. Enter a code and a name for the rule, along with a start date, and click Continue.
5. Set up the rule as required. For example, you may want to define that the Company field is always filled with
the value from the position from which you created this position.
6. Save your changes and go back to the Admin Center.
7. Select Position Management Settings.
8. Select the rule you’ve just created in the Rule for Defining Copy-Relevant Position Fields field on the UI
Customizing tab in Position Management Settings.
2.8 Setting up the Automatic Update Of “To Be Hired” Field
There is a feature you can use to automatically update the "To Be Hired" status for the position.
Context
You can specify that the To Be Hired status is automatically updated for the position whenever an employee is
assigned to the position or unassigned from the position.
When an employee is assigned to a position, you can When an employee is unassigned from a position, you can
choose from the following options: choose from the following options:
• Never • Never
Select this option to define that the position status is Select this option to define that the position status is
never reset and remains To Be Hired when an employee never set to To Be Hired when an employee is unas
is assigned to the position. signed from the position.
• Always • Always
Select this option to define that the position status To Select this option to define that the position status is al
Be Hired is always reset as soon as an employee is as ways set to To Be Hired when an employee is unas
signed to a position. signed from the position.
• Only If Planned FTE Value is Reached • Only If Current FTE Value is Below Planned Value
Select this option to define that the position status To Select this option to define that the position status To
Be Hired is only reset when an employee is assigned to Be Hired is only set when an employee is unassigned
the position if the planned FTE value for the position has from the position if the current FTE value for the posi
been reached. tion is below the planned FTE value.
You can specify that the position To Be Hired status is automatically set or reset if the position Target FTE is
changed.
• When you choose Yes, the system checks whether the sum of the incumbent's FTE is less than the
position Target FTE. If it is, the system sets the To Be Hired status to "True"; if it is not, the system sets the
To Be Hired status to "False".
• When you choose No, the To Be Hired status is not adapted.

You can specify that the position To Be Hired status is automatically set or reset if the incumbent's FTE is
changed via Manager Self Service (MSS) or a job information import.
• When you choose Yes, the system checks whether the sum of the incumbent's FTE is less than the
position Target FTE. If it is, the system sets the To Be Hired status to "True"; if it is not, the system sets the
To Be Hired status to "False".
• When you choose No, the To Be Hired status is not adapted.
Note that this check only takes place when the position assignment is not changed simultaneously
• You can disable the To Be Hired status adaptation during the job information import.
 Note
The To Be Hired status is not updated if the position assignment or the incumbent's FTE is changed in the
job information history.
 Note
In the case of a leave of absence (LOA) import, the To Be Hired adaptation is always triggered, regardless of
whether you activate the Adapt Hierarchy During Import of Leave of Absence Records setting automatic
adaptation or not.
Procedure
1. To define whether the To Be Hired status is updated, go to the Admin Center and choose Position
2. Go to the General tab.
3. From the Set ‘To Be Hired’ Status if Incumbent is Unassigned from a Position dropdown menu, select the
required setting.
4. From the Reset ‘To Be Hired’ Status if Incumbent is Assigned to a Position dropdown menu, select the
required setting.
5. From the Set or Reset ‘To Be Hired’ Status if Position 'FTE' is Changed dropdown menu, select the required
setting.
6. From the Set or Reset ‘To Be Hired’ Status if an Incumbent's 'FTE' is Changed dropdown menu, select the
required setting.
7. From the Adapt The Position ‘To Be Hired’ Status During Job Information Import dropdown menu on the
Import tab, select the required setting.
8. Save your entries.
9. You can also set the system to show only positions that have status To Be Hired in the Manager Self Service
(MSS) Job Information UI and Hire UI. To do this, go to the UI Customizing tab and set the Show only
positions that have status To Be Hired in the Hire UI and in the MSS Job Information UI option to Yes. Even if
you do this, all positions, whatever their status, are shown in the Job Information History UI.

2.9 Standard Hours
2.9.1 Determining Standard Weekly Hours
This section addresses both the derivation of standard weekly hours in Position Management and how they are
reflected in terms of full-time equivalents.
 Caution
If you used standard weekly hours using propagation in earlier releases, you need to delete that from the
propagation XML now before using standard weekly hours determination with Position.
Business Background
The job information section of an employee's Employment Information includes a field showing the standard
number of hours the employee is expected to work. You can enter this number directly in the job information,
or change information already there. However, if you have a lot of employees where you need to enter this
information, this can be time-consuming.
So it is possible to have the system derive the figure for you from a combination of any or all of the following
fields:
• Company
• Location
• Job Classification
• Position
Here's an illustration of the cascade logic used in such cases.

Figure 1: Cascade Logic in Standard Hours Derivation
When propagating the standard hours information, the system looks first in the most specific object — that is,
the position. If no standard hours information exists there, it looks in the more general ones, proceeding, if
need be, all the way to the most general one — that is, the company.
For this propagation to work, you have some setup to do.
 Note
You must create rules as described here if you are using Position, either alone or with other objects, as part
of standard hours derivation. However, if you are using some or all of the other objects without using
Position, creating rules is optional.
2.9.1.1 Entering Derivation Rules
You create the derivation rules using the standard rule function.
Go to the Admin Center and choose Configure Business Rules. Choose object Job Information and make the
entries shown here:
• If
Position.Standard Weekly Hours is not equal toNull
and
Position.Standard Weekly Hours is not equal to to 0

• Then
Set Standard Weekly Hours to be equal to Position.Standard Weekly Hours
• Else If
Job Classification.Standard Weekly Hours is not equal to Null
and
Job Classification.Standard Weekly Hours is not equal to 0
• Then
Set Standard Weekly Hours to be equal to Job Classification.Standard Weekly Hours
• Else If
Location.Standard Weekly Hours is not equal to Null
and
Location.Standard Weekly Hours is not equal to 0
• Then
Set Standard Weekly Hours to be equal to Location.Standard Weekly Hours
• Else if
Company.Standard Weekly Hours is not equal to Null
and
Company.Standard Weekly Hours is not equal to 0
• Then
Set Standard Weekly Hours to be equal to Company.Standard Weekly Hours

2.9.1.2 Completing the Succession Data Model
With the rules in place, you need to enter them in the Succession Data Model so that they can be triggered from
there.
Procedure
1. First, access the hris-element jobInfo.
2. Then go to the hris-fields Position, JobCode (for the Job Classification), Location, and Company, and
maintain the propagation rule as onChange rule there, like this:
2.9.1.3 What about new hires?
What we've looked at so far applies to existing employees. In the case of new hires, the same entries need to be
made as described above, but you need an additional rule, which is triggered in the event ‘onInit’ when the user
clicks the Job Information step.
This rule uses the Base Object ‘Employee Information’ instead of ‘Job Information’. The standard hours field is
derived from the Company selection discussed above.
The rule should look like this.

As with the others, you need to include this trigger in the Succession Data Model.
Related Information
Calculating Full-Time Equivalents [page 75]
2.9.1.4 Calculating Full-Time Equivalents

The job information in an employee's profile includes an FTE (full-time equivalent) field.
Context
The system calculates the value for this field by using a formula:
FTE = standard weekly hours in Job Information/standard weekly hours in base object, where the term
“base object” refers to the Position, Company, Location, or Job Classification.
For this to work, you need to define a rule and enter the trigger in the Succession Data Model.
Here's what you do.
Procedure
1. Define the rule you need, like this:

Rule implementation cascades through the THEN segment like this:
• If Standard Hours are defined in the Position and are not zero, then FTE = Weekly Standard Hours /
Standard Hours of Position.
• If Standard Hours are not defined in the Position or are defined as zero, then FTE = Weekly Standard
Hours / Standard Hours of Job Code.
• If Standard Hours are not defined in either the Position or the Job Code or if they are defined as zero,
then FTE = Weekly Standard Hours / Standard Hours of Location.
• If Standard Hours are not defined in either the Position or the Job Code or the Location or if they are
defined as zero, then FTE = Weekly Standard Hours / Standard Hours of Legal Entity.
• If Standard Hours are not defined in either the Position or the Job Code or the Location or the Legal
Entity, or if they are defined as zero, then FTE = 0 (zero).
2. Now maintain the Succession Data Model. The FTE should be triggered by onChange for the Standard
Hours field in hris-element JobInfo.
2.10 Optimistic Locking
Learn about what happens if two users attempt to edit a position concurrently.
If two users are editing a position at the same time, it becomes a case of “first change wins”. That is, the first
user’s changes are applied, but the second user receives an error message. The second user then has to
refresh the screen and submit their changes again when the first user is finished.
This restriction is called optimistic locking. It ensures that no conflicting changes can be made at the same
time. During the mass import of positions, the whole batch is rolled back if there's an optimistic lock exception
on any of the records.
For more information about optimistic locking, refer to the Related Information section.

Related Information
Optimistic Locking
Optimistic Locking
2.11 Position Organization Chart
As HR admin responsible for Position Management, the position organization chart is your go-to point for
viewing and maintaining the position hierarchy at your company.
You can view positions and the people who occupy them, see how all the positions relate to each other, and,
depending on your role-based permissions, do the following:
• Create positions.
• Edit positions.
• Change position associations (that is, reassign them to other positions).
• Deactivate positions.
• View positions and position details in the past and future.
 Note
The permission to view position is the permission to view the incumbent
When you create a new session with a fresh login, the date is set to Today, regardless of the date you
chose in another session.
When you navigate from one tab to another in Company Info, or duplicate a tab in the browser, the
position start date you've set previously is retained.
• Create a job requisition for a position.

• Start an employee hiring process.
Prerequisites
Depending on your responsibilities and tasks, and in order to access the chart, you need to have been assigned
the necessary permissions as described in Permissions Required for Position Management in General. For more
information, refer to the Related Information section at the end of this topic.
Accessing and Navigating in the Chart
To find the position organization chart, go to Company Info Position Org Chart . You see all the positions
that you’re responsible for, and all the positions beneath them in the hierarchy. The data shown for each
position depends on how the chart has been configured and on your role-based permissions. Once you've

accessed the chart, it will always be loaded with the last position you viewed and the position directly below
that.
 Note
• If there are a large number of positions in a hierarchy, they’ll be displayed in a compact view to save
space. The position organization chart is optimized to work with hierarchies of up to 100 positions
below a maximum of one position.
• If you try to load more than 1000 positions under one parent, only the first 1000 positions are
displayed. The system considers direct positions first, then matrix positions. You see an information
message to this effect. All this means that, if there are more than 1000 direct positions, only the first
1000 direct positions are displayed. No matrix positions are displayed at all.
Side Panel
Click any position to open the side panel. The exact information displayed here depends on how the panel has
been configured (see Setting Up The Position Organization Chart [page 80]), but here’s everything you can
potentially see and do:
In this section You can
Position Details View the staffing info and whether the position allows multi
ple incumbents, as well as the current status of the position
(for example, active, inactive, or the incumbent is on global
assignment).
The data displayed for a position is based on the visible

fields defined in Configure Object Definition.
Position History See a record of when the position was created, and the previ
ous and next change to the position.
Position Hierarchy Details View the data of all positions below the selected position in
the hierarchy. You are shown the number of positions with
planned vs. staffed FTE, the number of positions to be hired,
and the number of incumbents.
 Note
The Field Level Overrides permission isn't considered for
FTE and "To Be Hired" fields for the Position Hierarchy
Details in the side panel.
The system limits the number of positions displayed in

the Position Hierarchy Details in the side panel to
150,000.

In this section You can
Incumbent Details View all the people that are currently assigned to the posi
tion, and as of when. Only up to a maxiumum of 1000 in
cumbents are displayed at a time. "Today" is not included in
the calculation of the number of days the user has been in a
position. If you want to see more details about a particular
person, just click the quickcard beside their name.
Depending on the permissions you’ve been assigned, you

can also edit a person’s details using Take Action.
Job Requisition Details See if a job requisition (or job requisition request) exists for
the position. If so, you can see the status of the job requisi
tion, the number of candidates, the roles and people respon
sible for the recruiting process, and the date on which it was
created.
You can also carry out a wide range of tasks directly from Show Menu in the top-right of the side panel.
• Show Incumbent History

See everyone who has held this position in the past, and everyone who is scheduled to hold it in future.
• Add Lower-Level Position
Add a position beneath this one in the hierarchy. Depending on the business rules used at your company,
some of the fields of the new position might be pre-filled. To be able to do this, you need the Create
permission, without restrictions. See the Special Handling of the Create Permission documentation for full
information.
• Add Peer Position
Add a position on the same level as this one in the hierarchy. Depending on the business rules used at your
company, some of the fields of the new position might be pre-filled. To be able to do this, you need the
Create permission, without restrictions. See the Special Handling of the Create Permission documentation
for full information.
• Copy Position
Create one or more duplicates of this position with the exact same attributes. For more information, see
Mass Copy of Positions [page 92].
• Create Job Requisition
Find a new person to hold the position. For more information, see Setting Up Integration with Recruitment
[page 152].
 Note
The options available under Show Menu depend on your permissions and the position management
settings at your company.
Editing Positions from the Quickcard
Use the quickcard icon beside a position to see more detailed information it. Here you have two options – Edit
and Manage.

With Edit, you can change any attribute of the position (for example, the pay grade or department) and,
depending on the configuration, the changes will be immediately synced to the relevant job information data of
the assigned incumbents.
With Manage, you can see the history of the position (including all past and future changes), and can edit or
delete this historical data if necessary.
Other Options
Up in the top-right of the chart, you see a row of icons with which you can do the following:
• Zoom in and out.

• Choose whether to display child positions, matrix positions, and inactive positions.
• Create a new position.
• Add a new employee (that is, start a hiring process).
• Download the current view of the chart in either PDF or JPG form. Note that, if a position name exceeds a
certain length, the full name is not displayed and no ellipsis (…) appears either. The name is simply cut
short.
• Hide the header section of the screen. This gives you more room in which to display the chart.
Related Information
Using URL Parameters in the Search [page 83]

Limit on Loading and Processing of Data [page 84]
2.11.1 Setting Up The Position Organization Chart
Set up the position organization chart, a graphical representation of positions, who occupies them, and how
they relate to other positions, whether those are higher-level positions, lower-level positions, or peer positions.
You can also create positions and job requisitions in the position organization chart.
Prerequisites: Positions and Permissions
There's some work to do setting up the position organization chart, but before you can start this, you need to
define the Position object. For more information, refer to the Related Information section at the end of this
topic. In addition, users need the Access Position Organization Chart permission.
Display Date Settings
You can determine whether you want to enable date selection in the position organization chart. For more
information, refer to the Related Information section at the end of this topic.
If you load the position organization chart on a specific date, the position hierarchy and the data for the
positions is loaded with this date. This is different than loading the position in Manage Data or Manage Position.

Here, the data of the position is always loaded with the effective start date of the position record as there is no
display date selection available.
Let's look at an example. You have maintained this company in your system:
If you load a position that has this company assigned in the position organization chart with display date
07/01/2015, the assigned company is shown with name “SAP SE”.
If you would load the same position record in Manage Data or Manage Position, the company name is shown as
“SAP AG” as the data is loaded here with effective start date 01/01/2010 from the record shown.

Customize the Position Tile
You determine which fields should be displayed directly on the position tile. To do this, go to the Admin Center
and choose Org Chart Configuration, then open the Position Organization Chart tab.
Here's an example of how that can look:
There is a checkbox for determining whether the incumbent photos appear in the chart.
In the list itself, you can:
• Check the box next to fields that you want displayed in the Position tile in the position organization chart.
• Use the green arrows to move the fields up and down, determining the order in which they appear in the
Position tile.

Configuration UI
If you have configured and assigned a Configuration UI for the position, this is also shown in the position
organization chart as a Quickcard. You can then make use of the advanced features. For example, you can sort
and group fields so that they are displayed according to your needs.In addition, ad-hoc changes are supported
- for example, customers can define whether fields are visible and/or required.
Customize the Side Panel
Here's how to choose which sections appear on the side panel and in what order they appear:
1. Go to the Admin Center and choose Org Chart Configuration Position Organization Chart .
2. Under Set the Side Panel Sections that are displayed in the Position Organizational Chart, select the
checkboxes for any sections you want to be displayed in the side panel.
Use the up and down arrows to control the order in which the sections are displayed.
3. Once you save your settings, the new layout of the side panel is immediately available the next time users
log on.
Related Information
Defining Field Details [page 29]

Propagate Job-Related Fields [page 30]
Defining Default Values [page 31]
Setting up Automatic Position Code Generation [page 32]
Define Searchable Fields [page 34]
Creating New Positions [page 34]
2.11.2 Using URL Parameters in the Search
There are two URL parameters you can use to see all the info for a particular position in the position
organization chart.
The URL parameters are as follows:
• selected_user
Here's an example where you want to load the position organization chart for user "cgrant": <server>/sf/
orgchart?type=position&selected_user=cgrant
Effect: When you access the position organization chart, the chart for the specified person ID is loaded.
• selected_position
To use this, you enter the external code for the relevant position.
Here's an example, where you want to load the position organization chart for the position with external
code "CEO": <server>/sf/orgchart?type=position&selected_position=CEO

Effect: When you access the position organization chart, the chart for the position with the specified code
is loaded.
 Note
If the code contains special characters, you need to encode it; you can't enter it directly.
Here's an example, where you want to load the position organization chart for the position with external
code "CEO&CTO": <server>/sf/orgchart?type=position&selected_position=CEO%26CTO
2.11.3 Limit on Loading and Processing of Data
There is a limit on the number of positions and incumbents loaded and processed in the position organization
chart.
The limit restricts the number of positions and incumbents displayed to 1000 when there’s a large number of
positions or incumbents to be loaded and processed.
In the position organization chart, the limit is applied in:
• The Incumbent Details section of the side panel

• The Incumbent History
If more than 15 positions exist on a hierarchy line, the position is displayed in a list view. It's not possible to
define the order in which positions are shown.
The limit improves system usability and performance.
 Note
If you have configured onLoad rules under Manage Data Object Configuration for the position object
to fill a field value on load, no rule is triggered in the position tile of the position organization chart. Neither
is the rule triggered in the position details side panel. You must navigate to the entity details with the quick
card, Show Position.

3 Enhanced Setup
3.1 Position Types
You may use position types to modify standard system behavior for one or more positions. This configuration is
optional.
Prerequisites
You only need position types if you need special system behavior when workflows are triggered or to certify to
whom the direct reports should report for certain type of positions. For further use cases, please check the
context below. Please note that you don't have to use position types to be able to assign multiple employees to
a position.
You don't have to use position types to be able to assign multiple employees to a position. For more
information, please refer to the multipleIncumbentsAllowed entry in the table in Fields in Position Object [page
24]
Context
Which standard system behaviors can you influence using position types?
• You can opt to trigger a workflow on job information if position changes have been synchronized to
incumbents.
• You can specify to whom direct reports should report if their current manager leaves his or her position.
• You can specify whether the reporting line should be adapted after the position hierarchy has been
changed.
• You can determine whether and how job relationships for this employee are adapted.
• You can set up and manage transition periods for more than one position.
 Note
You only need position types if you need special system behavior when workflows are triggered or to certify
to whom the direct reports should report for certain type of positions. For further use cases, please check
the context below. Please note that you don't have to use position types to be able to assign multiple
employees to a position.
You don't have to use position types to be able to assign multiple employees to a position. For more
information, please refer to the multipleIncumbentsAllowed entry in the table in Fields in Position Object
[page 24]

Enhanced Setup PUBLIC 85
Here's how to go about doing any or all of these:
Procedure
1. In the Admin Center, choose Position Management Settings, then go to the General tab and set the field Use
Position Types to Yes. Once you have done this, the system automatically generates 2 default position
types. These are RP (regular position) and SP (shared position). These represent standard system
behavior for regular positions (one incumbent assigned, if any) and shared positions (more than one
incumbent assigned). You can find the generated position types in the Manage Data function.
2. If you want to create position types of your own in addition to the default position types, go to Manage Data
and choose Create New Position Type . To proceed, you must choose one of the delivered custom
position codes (Custom Position 1, Custom Position 2, and so on).
3. Before you can assign your positions to the position types as you want, you have to make the Type field in
the Position object definition editable. You do this in Configure Object Definitions .
4. Now you can make the assignment by selecting the corresponding position type in the Type field in your
position.
5. If you want to change the standard position types generated in step 1, you need to make sure that all your
positions have been assigned to one of those types. If you change them without making the assignment,
the default behaviors will still apply.
Workflow for Position To Job Synchronization
Instead of the immediate job info update, you can execute a workflow on job information changes if you need to
synchronize position changes with incumbents.
First, there's some setup work to do.
• Use of position types has to be enabled. You do this by setting the Use Position Types option in Position
Management Settings to Yes.
• Once use of position types has been enabled, a position can be assigned to a position type. A workflow for
synchronization of position changes to incumbents will only be triggered if the configurable option Execute
workflow on Job Information if Position Changes are synchronized to Incumbents? is set to Yes for the
position type assigned to the position in question.
• A further prerequisite is that the workflow to be triggered is assigned to the event reason used for
synchronization of position changes to incumbents. The event reason is determined either in Position
Management Settings or by event reason derivation.
 Note
• Executing the workflow on position changes is an alternative to the immediate update. That means that
it is only triggered if position changes are to be synchronized to incumbents. That is, a workflow
request is only created if synchronization-relevant changes are to be executed. If no synchronization-
relevant job info field has to be changed for a user, no workflow is created.
• If no workflow can be derived by workflow derivation XML or business rules, no workflow is triggered.
Instead, the incumbents’ job info is updated immediately.

86 PUBLIC Enhanced Setup
• If the update of the position is synced to more than one incumbent, a workflow request is created for
each incumbent.
• If the workflow request is declined, the user’s job info is not synchronized with the position change. The
position changes themselves are not rolled back.
• Functional behavior differs in the Import Scenario. This means that, when you are importing a position
or position changes, separate workflow requests are created for synchronization to incumbents.
To whom shall the direct reports report if the manager leaves

the position?
With this field in the position type, you can influence system behavior in the event that a manager leaves his or
her position.
If an employee leaves a position that has other incumbents assigned, the incumbents of the child positions
need to be assigned to a new supervisor if the position hierarchy is the leading hierarchy.
The permitted values are as follows:
• To manager on next higher-level position.

• To next manager on leaving position if available.
• To no manager.
The default values are as follows:
• For default position type RP (Regular Position)

To manager on next higher-level position.
• For default position type SP (Shared Position)
To manager on next higher-level position
Now we'll look at some examples, using the reporting line and position structure shown here, where the letter P
means "position", M means "manager", and E means "employee".

Employees E1 and E2 report to manager M2. Manager M2 reports to manager M1. Manager M1 is assigned to
position P1. Manager M2 and a third manager, M3, are both assigned to position P2. Employee E1 is assigned to
position P4, employee E2 is assigned to position P3. P3 and P4 are lower-level positions of P2. Position P2 is a
lower-level position of P1.
1. To manager on next higher-level position
The value is used by default for all positions that have no position type.
If you enter a position type with this value in the To whom shall the direct reports report if the manager leaves
the position? field to position P2 and unassign manager M2 from this position, here's what happens:
1. Read all employees assigned to a direct lower-level position of position P2 and reporting to manager M2,
who is leaving.
2. Read the position hierarchy upward from position P2 until a position with an incumbent is found.
3. Assign all employees from the first step to this new manager.
4. If no new manager is found, the employees from step 1 will not report to any manager.

2. To next manager on leaving position if available
If you assign a position type with this value in the To whom shall the direct reports report if the manager leaves
1. Read all employees assigned to a direct lower-level position of position P2 and reporting to manager M2,
who is leaving.
2. Check whether another incumbent is assigned on the leaving position.
• If the answer is yes, assign all employees from the first step to this manager.
• If the answer is no, read the position hierarchy upward until a position with an incumbent is found, then
assign all the employees from the first step to this new manager. If no new manager is found, the
employees from step 1 will not report to any manager.

3. To no manager
If you assign a position type with this value in the To whom shall the direct reports report if the manager leaves
1. Read all employees assigned to a direct lower-level position of position P2 and reporting to leaving
manager M2.
2. Change the manager of all employees from the first step to report to "No Manager".
 Note
Position types are not taken into account if you are terminating a user.
Adapt Reporting Line If Position Hierarchy Is Changed
You can use this field to influence system behavior. How does this work? If the position hierarchy is leading and
is then changed, the system automatically sets the supervisor of all incumbents of the changed position to the
incumbent of the new parent position.
The permitted values are as follows:
• Yes, incumbents of the position should report to the incumbent of the new parent position.
• No, incumbents of the position should report to their existing manager.
The default values are as follows:

Yes, incumbents of the position should report to the incumbent of the new parent position.
Yes, incumbents of the position should report to the incumbent of the new parent position.
Synchronize position matrix relationships to job relationships

of incumbents?
You can use this field to determine whether and how the job relationships for this employee are adapted.
Synchronization can be triggered when:
• The position assignment of the employee changes.

• The matrix relationship of the position changes.
Here's a list of the permitted values:
• Always - Synchronization takes place every time either of the above things happens.
• Never
• Only when position assignment of the employee is changed.
• Only when matrix relationships of the position are changed.
There are default values in each case:

• Always, if matrix relationship is not set to invisible in position object definition.
• Never, if matrix relationship is set to invisible in position object definition.
• Always, if matrix relationship is not set to invisible in position object definition.
• Never, if matrix relationship is set to invisible in position object definition.
 Note
• The inheritance of Job Relations from position to position incumbent isn't triggered during the import
of Job History data - that is, when you are changing the position assignment of an employee using such
an import.
• In all cases, inheritance takes place regardless of the leading hierarchy.
• You can use a new job relationship manager by leveraging the position hierarchy in the workflow.
• Synchronization of matrix relationships does not take place if you change an employee's position using
Manage Pending Hire.
Position Type Examples
So, when might you want to use position types? Here are some examples.
• Regular positions

This is a default position type. You can't add this yourself.
Regular positions would be occupied normally by one employee.
• Shared position
This is another default position type that you can't add yourself.
Shared positions are positions usually occupied by two or more employees sharing the same position and
job. For example, if two assistants working part-time share the same one position
• Positions with multiple incumbents allowed
Positions with multiple incumbents allowed could be occupied by up to 50 or 100 employees. For example,
seasonal workers in production or retail industries. Depending on the requirements, such positions could
allow for less inheritance from the position hierarchy. For example the job classification and/or the
supervisor could be skipped in synchronization.
• External positions
External positions could group several external workers on one position.
Transition Periods in Position Types
A transition period occurs when an employee leaves a position (for example, due to transfer or termination)
and a successor is appointed to that position before the incumbent leaves it. This means that the position is
overstaffed for that time.
You can manage transition periods for more than one position by making the required settings in the relevant
position type. Take a look at the Transition Periods [page 148] documentation for details.
3.2 Mass Copy of Positions
It is possible to create up to 100 positions at a time by copying an existing position.
Prerequisites
The person wanting to create positions needs the relevant permission. To activate this, go to the Admin Center
and choose Set User Permissions Manage Permission Roles . In the resulting screen, access the Manage
Position role and activate the relevant permission, shown below.

Outcome
Once the permission is activated, the Copy Position option appears in the list you can use on tiles in the position
organization chart. In the resulting popup, you can enter a number between 1 and 100. If you enter anything
other than that, an error message appears in red.
Take a look at the Setting Up The Position Organization Chart [page 80] information for full details of
permissions.
When you choose OK, the system creates the specified number of positions, based on the old one. The copies
have all the attributes of the original, except right to return.
Note
When copying a position in the position organization chart, you can define that a configured workflow is
triggered. To this end, there's a field on the UI Customizung tab in Position Management Settings called
Respect Workflow at Copy Position in Position Organization Chart. Setting this to Yes triggers the configured
workflow. A separate workflow is created for each new position. After approval, the corresponding positions are
displayed in the position organization chart.
If you set this to No, copied positions are created without any workflow being triggered.

The default is for no workflow to be triggered.
3.3 Mass Changes to Positions
There is a mass change feature you can use to make changes simultaneously to a large number of positions.
Overview
• You can use a single rule to define the position target population and the change attributes.
• Changes are effective dated.
• Changes to positions can be synced to incumbents.
• The default is for the Mass Change Run object to be secured by a role-based permission (RBP). Only users
with the relevant permission can make mass changes.
 Note
For more information about Mass Data Management, please refer to the Related Information section.
Prerequisites
• The Mass Change Run object is RBP-secured by default. You grant access to it by going to the Admin
Center and choosing Manage Permission Roles . You can find the permission under Miscellaneous
Permissions.
• You grant access to Manage Mass Changes for Metadata Objects also in Manage Permission Roles, this time
under Metadata Framework.
Restrictions
• If a pending position is valid for the change, but the effective start date is before the change date, the
relevant record can't be updated.
• No role-based permissions are applied to selecting and changing the positions.
• Only Set statements are allowed in the Select And Update Rule THEN condition.
• If any records in the mass change run contain an optimistic locking exception, then the whole batch will be
rolled back. For more information, see the Related Links section below.

Creating A New Mass Change Run
You create a mass change run by going to the Admin Center and choosing Manage Mass Changes for Metadata
Objects. Here's an example, showing the sort of entries you can make:
Here's what the fields you see here mean:
• Code
Unique code for the new mass change run.
• Name
Translatable name for the new mass change run.
• Object Type To Be Changed
Indicates whether the object is a position or a time object.
• Change Date
This is the date on which the changes take effect. All records (active, inactive, pending) valid from this date
that match the IF condition of the Select And Update Rule are included.
• Synchronize To Incumbents
This indicates whether the changes in the position objects should be synchronized to the incumbents.
• Select And Update Rule
Enter a rule that defines which objects are selected and what is updated. Use IF conditions to restrict the
number of objects to be changed by this mass change run. Use SET statements in the THEN condition to
define the new values of objects.
 Note
Only rules created with the Update Rule for Mass Change Run rule scenario can be selected. Only SET
statements are supported in the THEN condition.
• Execution Mode
You can choose Run or Simulate. When you choose Simulate, the mass changes aren't saved, but you can
see the result in the log. When you choose Run, the mass changes are executed and saved. You can
monitor the progress and check results of the job in the Scheduled Job Manager page.
 Note
The status of these jobs will continue to be available in the legacy Monitor Jobs page.

• Execution Status
This field shows the status of the mass change run:
• Scheduled means that the mass change run is scheduled and will run soon
• In Progress means that the mass change run is still running.
• Executed means that the mass change run was successful.
• Failed means that there were errors in the last mass change run.
• Log
The log shows information about the executed mass change run. The information includes the number of
updated and failed objects/records and CSV field with detailed information about each record.
 Note
The log is purged after six months.
If you select Simulate or Run as the execution mode and then save the mass change run, the system
triggers a QUARTZ Job (Name MassChangeRun_<Code><UniqueNumber>) that processes the change.
So, it may take a while before the run starts. You can review the status of the QUARTZ Job if you reload the
mass change run in Execution Status.
After the mass change run has finished, the user who started the mass change run receives an email. The
details can be found in the Log section of the mass change run.
 Note
In order to ensure that the mass change runs execute as smoothly as possible, we recommend that you
enable the rule cache.
1. In the Admin Center, go to Configure Object Definitions.

2. For the relevant mass change run, set the Use Rule Cache field to Yes.
The result is that the mass change run is much quicker than before, and you're significantly less likely to
encounter a timeout.
Processing Details
Let's assume the mass change run discussed above is executed. The assigned rule "PosJobTitleChange" would
look like this:

Before the run, the positions data in the system looks like this:

You set the change date of the mass change run to 12/31/2016. This means that not all position records are
relevant for this mass change run. Only records that are valid as of the change date or records that are valid
after the change date are relevant for the run. In the chart below, you can see 2 records that are only valid
before the change date. These are not valid for the mass change run.
Once the relevant records are found, they are passed to the rule defined in Select And Update Rule. Only those
matching the IF condition are changed. In the chart below, you can see that Position 2 is not changed at all
because it does not satisfy the IF condition.

Mass Changes to Composite Objects
It is also possible to modify the data of a composite object, such as Matrix Relationship. The rule shown in the
picture below is an example of such a rule.
The IF condition returns all positions that are assigned to company = SAP and that already have a matrix
relationship maintained with Type = HR Manager Position and Related Positions is not equal to Expert
Developer. The SET statement updates this existing matrix relationship and sets the related positions to Expert
Developer.

 Note
The SET statement on a composite object creates a new record if no record specified by the Select-
Statement in the SET-Condition was found. So, it's important to restrict this in the IF condition as shown in
the screenshot above.
Related Information
Mass Data Management

Optimistic Locking [page 76]
3.4 Positions That Allow Multiple Incumbents
Positions That Allow Multiple Incumbents are positions to which more than one employee may be assigned.
Context
The multipleIncumbentsAllowed field has been added to the position generic object definition. By default, it is
set to Not Visible. To use it to specify that more than one employee may be assigned to a position, you must
change the visibility.
A position can have, at most, one incumbent if the field is set to Invisible or the field value is “false”.
The system checks the fields if:
• A position is assigned to a new hire.

• An employee’s job Info is changed under Employee Name → Action "Change Job and Compensation
Information".
• Changes are made in the jobInfo history.

• You try to change a position that allows multiple incumbents to a position to which only one employee may
be assigned.
• A job information import takes place.
Remember that, if you intend to use positions that allow multiple incumbents and are using or intend to use
integration with other ERP solutions, assignment of multiple employees to one position is not supported in
many ERP solutions. For more information, take a look at the Organizational Data Replication documentation.
 Note
If you use a position that allows multiple incumbents as a parent position and assign multiple employees to
it, the system will assign a supervisor to all incumbents assigned to the corresponding child positions
randomly.
Procedure
2. Search for Position and select Take Action Make Corrections .

3. Scroll down to the multipleIncumbentsAllowed field and click Details.
4. Change the visibility to Editable and save your changes.
If you want to set positions as positions that allow multiple incumbents by default, set the Default Value
field to true.
3.5 Capacity Control
If a position is subject to position control, the full-time equivalent (FTE) values of all incumbents assigned to
the position must not be higher than the FTE value assigned to the position.
Context
This is checked when:
• A new employee is hired.

• The manager assigns a new position to an employee or changes the FTE of an employee under Employee
Name Action "Change Job and Compensation Information" .
• The position or FTE value is changed in the History.
• The FTE value of the assigned position is changed.
• The system searches for a suitable position when a position transfer or position reclassification is enabled.

 Note
• If a position is subject to position control, the system checks, for each imported job info record,
whether the FTE values of all incumbents assigned to the position must not be higher than the FTE
value defined for position. This can be very time consuming, especially if there are multiple incumbents
assigned to a position, as we know this for "cumulative positions" with multiple records. Please
consider this impact in time when performing a jobinfo import. We recommend that you set the
position control to NO in such cases.
• The system doesn't perform a validation check for positions that have more than 1000 target FTEs.
Even if Position Control is set to Yes, no validation occurs in the following scenarios:
• You save Job Information through Centralized services, either through import or on the Job
Information history.
and
• You change the position target FTE to a value greater than 1000.
The positionControlled field is in the Position generic object. If you want to use the field, proceed as follows:
Procedure

2. Set the positionControlled field to Editable or Read Only.
When you create a new position, you can now specify whether the position is subject to position control.
3.6 Forward Propagation
Forward propagation of future records means that a change in the value of a field in an object, such as Job
Information or Position, 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
maintained that is different than the original field value.
Forward propagation for positions also supports propagation of composites, such as matrix relationships, and
of valid-when associations, such as the parent position.
There are limits on where forward propagation is supported in Position Management and what for. This table
shows the details.
Position Org Chart Edit Manage Data Manage Position
Insert New Record Supported Supported Supported
Make Correction Supported Not Supported Not Supported

3.6.1 Example
Let's look at a forward propagation example.
Procedure
1. We display a position by going to the Admin Center and choosing Manage Positions.
We see that this position has 2 records. Originally, it had pay grade Z09, but the history shows that a
change has been scheduled to take effect from December 1. From then, the pay grade for this position will
be Z11.
2. Now, we go to Admin Center again and choose Manage Data, then call up the data for Position. We insert a
new position record on November 1, between the first record mentioned in step 1 and the second.

We make some changes to the position data, including changing the pay grade from Z09 to Z10.
3. Now, we go back to the position record we looked at earlier.

We see that all the changes we made in the data have been propagated to the last position record. The
exception is the pay grade, where the system found a change was already in place and did not change it
again in line with entries made in the data. The history shows a summary of all the changes.
3.7 Right to Return
The term "right to return" describes a situation where an employee on global assignment or leave of absence
can return to their original position if the position hierarchy is the leading hierarchy, as we recommend.
To use this feature, you need to have installed some other Employee Central features:
• Global Assignments
Install this if you want to handle the right to return in connection with global assignments. If you create a
global assignment, the actual return date of the global assignment and of the corresponding right to return
are the same. If you create the global assignment with a planned end date, the planned end date of the
corresponding right to return is set to 31.12.9999.
If you create two consecutive global assignments without ending the first one, the system creates a right to
return for each global assignment. As is the case with only one global assignment, the actual return date of
each global assignment and its corresponding right to return are the same. If you create the global
assignment with a planned end date, the planned end date of the corresponding right to return is set to
31.12.9999.
• Time Off
Install this if you want to handle the right to return in connection with leaves of absence.

You can find out more about global assignments and Time Off by referring to the relevant handbooks.
It might happen that an employee in your business has to leave their current position, not permanently, but for
a period longer than mere vacation would account for. Examples might include a leave of absence to take care
of a sick relative, or a global assignment.
In such cases, you need to decide whether the employee should be unassigned from their current position and,
if yes, whether they have a right to return to the position once their global assignment or leave of absence is
over.
 Caution
Global assignments can currently only be created through the user interface. You cannot create a right to
return for global assignments through import.
When adding multiple leaves of absence (Time Off) or global assignments, you must add an actual return
date to the leave of absence or end the global assignment before adding a new one. This ensures that the
rights to return (including position assignments) are created correctly.
Therefore, for global assignments, we strongly recommend that you set End Global Assignment
Automatically to Yes to ensure that the system ends global assignments before creating new ones.
Visualization of Right to Return in the Position Organization Chart
If a position has a right to return as of the date displayed in the position organization chart, this is highlighted
by means of an icon, as shown here:
The icon shows that a right to return exists. Click the icon and you can see more detailed information in the side
panel under Right to Return Details.
 Note
If an employee is assigned back to the position for which a right to return exists, there's no automatic check
to ensure that the position won't be overstaffed by people or FTE. Please check this manually.

Before you can use the right to return, you need to make some settings in Employee Central Position
Management.
3.7.1 Position Management Settings for Right to Return
There is some setup work to do before you can use the right to return feature.
Context
In Position Management, use of the right to return depends on rules. In addition, if you want to use the right to
return in connection with Global Assignments, you need to enter 2 event reasons.
 Note
For the right to return to work correctly for Leave of Absence and Global Assignment, you must set up and
insert all the rules and event reasons as described here.
Procedure
1. Let's take a look at the fields in Position Management Settings. They're on the Right To Return tab and you
can specify 2 rules each for use with leave of absence and global assignments.
a. The first rule (Unassign from Position) is used to decide whether the employee in question is
unassigned from his or her current position while he or she is away.
b. The second rule (Create Right to Return) is used to decide whether the employee has a right to return
to that position when he or she comes back.

Choose Show Right to Return to see more details.
 Note
• If you change the leave of absence or global assignment start date for a user with the right to
return, the start date in the Right to Return object is changed as well.
• If a user is unassigned from their position due to a leave of absence or global assignment, they
will still report to their existing supervisor.
• If a supervisor is unassigned from their position due to a leave of absence or global
assignment, their direct reports will report to the next available manager according to the
position hierarchy for the duration of the supervisor's leave of absence or global assignment. If
the reporting line is the leading hierarchy, the reporting line remains unchanged.
• If a supervisor is unassigned from their position due to a leave of absence or global assignment
and the start/end date of the leave of absence/global assignment is changed later, the
hierarchy will not be reset with the new start date.
2. In the case of global assignments, you also need to specify 2 event reasons
a. The first event reason (Event Reason for unassign Position) is used to delete the position in the home
user's job info record.
b. The second event reason (Event Reason for assign Position) is used to add the position again for which
a right to return exists in the home user's job info record. This does not happen until the user actually
returns.
3. So, what about those rules?

a. Two rules need to be created. Go to the rule maintenance screen. You can do this either by going to the
Admin Center and choosing Configure Business Rules, or using the "+" icon next to the Right to Return
rule in the Position Management Settings.
b. On the selection screen, enter the respective rule scenario, a rule name, rule ID, start date and, if you
want, a description. For the Unassign from Position rule, the rule scenario Unassigned Incumbent from
Position for Right to Return is required. For the Create Right to Return rule, the rule scenario Create
Right to Return for Incumbent is required. Both rule scenarios can be found in the Position
Management section. Both rules are needed when a Global Assignment or a Leave of Absence is added
to ensure that the right to return works correctly.
4. Now go to Position Management Settings and make the appropriate entries under Right To Return. For
both Leave of Absence and Global Assignment, enter the relevant rule in the field Unassign from Position
and Create Right to Return. For Global Assignments, you need to enter event reasons too.

 Caution
Please don't try to enter the right to return manually using, say, Manage Data. It will be created
automatically if needed in the leave of absence process or global assignment process.
3.8 Matrix Relationships
Here's information about how matrix relationships can simplify how you create job relationships in your
organization.
You can define matrix relationships for a position rather than job relationships for a person. When an employee
assumes a position, in other words, becomes the incumbent, the employee automatically has these job
relationships. That way, you don't have to create job relationships for each employee individually.
3.8.1 Synchronization between Matrix Relationships and Job

Relationships
You can synchronize position matrix relationships with the employee's job relationships when you assign an
employee to a position.
Synchronization is triggered when you select Change Job and Compensation Info on the Employee Profile
screen or when you assign an employee to a position. When you do this:
• The system updates existing job relationships if the employee's newly assigned position has a position
matrix relationship of the same relation type. In addition, the related position must have at least one
incumbent and no direct supervisors. This means that the incumbent of the related position becomes the
manager for the job relation.
• The system doesn't change existing job relationships if the newly assigned position either:
• has no position matrix relationship of the same relation type or
• there’s no incumbent for that related position.
• Where related positions have at least one incumbent, job relationships are added for those position matrix
relationships of the employee's newly assigned position.
You don't see the sync happening on the UI. It happens in the background when you save the employee's job
information.
When you transfer multiple employees to a new job relation manager based on matrix position relationships,
the number of employees might exceed the threshold specified in the Admin Center under Position
Management Settings Hierarchy Adaptation Threshold for running Adoption of Reporting Line and Job
Relations as a job . In this case, the transfer of the employees is executed asynchronously using a job.
 Restriction
For performance reasons, you must set the Threshold for running Adoption of Reporting Line and Job
Relations as a job to a number between 5 and 20.

Remember
You need to set the PositionMatrixRelationship association on the position object to editable. Then you need to
create the MDF picklist, PositionMatrixRelationshipType, and fill it with exactly the same values as the Employee
Central picklist for job relationship types.
The PositionMatrixRelationship picklist doesn't allow for multiple picklist values with the same external code or
nonunique external code. However, you can manually select multiple values for the same matrix relationship on
the position.
 Note
The Matrix Relationship to Job Relationship sync only supports one of each relationship types. This means
that, if you've selected two values for HR manager, Matrix Relationship Sync only supports one of those. the
HR manager is defined by the system at random.
3.8.2 Synchronization Triggers
Here's information about job matrix relationships and job relationships synchronization triggers and the
configuration of synchronization triggers.
 Remember
The Synchronization tab in Position Management Settings contains the Matrix Relationship Synchronization
definition.
It is visible when the matrix relationship is activated. You can choose from different synchronization options or
use this field to switch off matrix synchronization. If position types are activated, the settings there override the
settings from the Matrix Relationship Synchronization definition. The advantage of this setting is that you can
use it to prevent global synchronization for all positions without having to add the position type for each
individual position manually. The default value for this function is Yes.
Job relationships are synchronized when:
• the matrix relationships of a position are changed

• an employee is assigned to a position that has matrix relationships
• an employee is referenced by matrix relationships of other positions. (If an employee is referenced, the
position has matrix relationships to other positions.)
By default, synchronization is always executed. You can switch it off globally in position management settings
or for specific positions by using position types. Look at the Synchronize position matrix relationships to job
relationships of incumbents? section of the Position Types [page 85] information for details.
 Caution
If you manually select job relationships while adding an employee in the Hire Wizard or try to set it by rule,
the sync is overwritten and the matrix relationships are not synced from the position.

 Note
• Job Information UI: The administrator has the option to choose whether to trigger Position Matrix to
Job Relationship sync or, to retain all existing relationships when a position is changed or assigned.
• You are required to configure or enable the HRIS field triggerMatrixRelationSync in Manage
Business Configuration. If you don't configure or enable this field in Manage Business
Configuration then you don't have the option to decide on an adhoc basis. However,
synchronization will happen if the field is set to Always.
The triggerMatrixRelationSync field is a transient field.
• Job Information Import:You can now trigger the Position Matrix to Job Relationship sync during job
information imports. You can enable this from the Imports tab in the Position Management Settings.
 Remember
"Transient" means that the content of the field isn't saved to the database, but is calculated on-the-fly
3.8.3 Synchronization Scenarios
Here are examples of when the system synchronizes matrix relationships and the job relationships of an
employee.
Table 17: Scenarios

Scenario System Behavior Limitation
The position assignment is changed us Matrix relationships for the employee's n/a
ing the Manager Self-Service user inter newly assigned position are synchron
face (MSS UI) or a position assignment ized with the job relationships of the
is added using the MSS UI or New Hire employee. Existing job relationships are
UI. preserved if:
• the job relationship has no corre

sponding matrix relationship on
the position side
• if the related position of the corre
sponding matrix relationship
doesn't have any incumbents
The position assignment is removed No changes occur to the employee's job n/a
from the employee (without assigning relationships.
the employee to a new position)
through the MSS UI.

The position assignment is changed in The system synchronizes matrix rela n/a
the context of position reclassification tionships of the newly assigned position
or position transfer. The position that with the job relationships of the em
the employee is now assigned to is an ployee. Existing Job relationships are
existing position that has matrix rela preserved if:
tionships.
• the job relationship has no corre
For more information on Position Re sponding matrix relationship on
classification and Position Transfer, re the position side
fer to the related link. • the related position of the corre
sponding matrix relationship
doesn't have any incumbents.
A position is updated with a new matrix The new or changed matrix relation n/a
relationship or a matrix relationship is ships of the position are synchronized
changed (meaning that the related po with the job relationships of the position
sition is changed), either using the UI or incumbents.
during the position import, but only if
the related position has an incumbent.
A matrix relationship is removed from a The corresponding Job relationship will n/a
position, either using the UI or during be removed from the job relationships
the position import. of the position incumbents.
An employee is assigned to a position The job relationships of the incumbents n/a

referenced in matrix relationships of of the referencing positions are
other positions. The position is not a synchronized based on:
position for which multiple incumbents
are allowed.
• the matrix relationships referenc
ing the position that was assigned
to a new employee.
If some incumbents already have corre

sponding job relationships for some
reasons, the job relation manager refer
enced in these job relationships is up
dated with the new employee.
An employee is assigned to a position Corresponding job relationships refer n/a

referenced in matrix relationships of ring to the new employee are added,
other positions. The position is a posi but only for those incumbents of the
tion for which multiple incumbents are referencing positions who do not have
allowed. them yet.
An employee is unassigned from a posi If an employee is transferred or unas n/a

tion that is referenced in matrix rela signed from a position, the correspond
tionships of other positions. The posi ing job relationships of the incumbents,
tion is not a position with multiple in which refer to the employee who left the
cumbents allowed. position, are removed.
An employee is removed from a posi The corresponding job relationships of When a position record with a matrix re
tion that is referenced in matrix rela the incumbents of the referencing posi lationship is deleted, the corresponding
tionships of other positions. The posi tions, which refer to the employee who job relationships aren't removed from
tion is a position for which multiple in left the position, are synchronized so the job relationships of the position in
cumbents are allowed. that they refer to another incumbent of cumbents.
the position. This incumbent is chosen
arbitrarily by the system.

The incumbent of a matrix position is If the original incumbent's termination The incumbent of a matrix position is
terminated. A replacement is hired dur date is reached, the job relationships terminated. A replacement is hired dur
ing the Transition Period. The position are transferred to the new incumbent ing the Transition Period. if the replace
then has two incumbents during this by triggering the Position Matrix to Job ment incumbent of the matrix relation
time. Relationship sync. ship position is removed or terminated
during the transition period, then the
transferred job relationships will not be
updated for any newly created incum
bents for the same position.
Related Information
3.8.4 Restricting Access to Positions Based on Matrix

Relationships
You might need to restrict the access to certain positions or certain allowed position actions for a user to
positions that have a certain matrix relationship to the user's own position.
You do this by defining the MDF object target criteria in an RBP role. For more information about each
configuration/process, refer to the Related Information section.
In the target criteria screen, you will find the Include access to Position that have an association with the
specified type below the Granted User's Position section if the matrix relationship association is not set to
invisible in the Position object definition.
In this section, you can define the association (currently only Matrix Relationship is supported), the
association type (external codes of MDF picklist PositionMatrixRelationshipType) and the level of child
positions that are relevant for the position target population.

Now let's look at an example.
Let’s assume this position hierarchy is maintained in the system.
• Position P1 has position P2 as direct child position.

• Position P3 is matrix assigned with type “PM” to position P1 and position P4 is matrix assigned with type
“HR” to position P1.
• Position P4, in addition, has a direct child position P5 and P5 has a direct child position P6.
• Employee E1 is the incumbent of position P1.
If you set up the position target criteria as we saw in the screenshot with type “HR” and level = 1) it means that
a user assigned to this RBP role has access to positions that reference the user's own position with matrix
relationship type “HR” and additionally 1 level of the child positions found.
In the example, the user E1 has access only to position P4 and P5.
 Note
• The target criteria restriction for matrix relationships always excludes the employee's own position.
• If you are checking more than one restriction for a target criterion, the restrictions are concatenated
with an AND.
For example, in the setting here, the user sees the positions based on the matrix type and job title =
Developer.

Related Information

3.9 Validations in Position Management
Here's information about the validations that the system can perform when the Job Information History of an
employee is changed, or when there's a Job History Import using Centralized Services.
Types of Validation
 Note
The validations can be activated or deactivated with the Validate Position Assignment During Job
Information Import setting. You can find the setting on the Import tab under Position Management Settings.
Related Information
Forward Propagation in Job Information and Job Relationships

Job History Imports
Data Validation for Job Information (MSS and History UI)

3.9.1 Types of Validation
If activated, the system performs the following validations in Position Management:
• Position Status Validation. Employees can be assigned to only active positions. Refer to Fields in Position
Object [page 24] for more information on the effectiveStatus field in the Position object.
• Multiple Incumbents Validation. This validation verifies that you allow multiple incumbents for the
position. Refer to the entry for multipleIncumbentsAllowed in Fields in Position Object [page 24] and
Position Types [page 85].
• Full-Time Equivalent (FTE) Validation. This validation depends on whether the position is subject to
position control, as well as the FTE value. Refer to Capacity Control [page 101] for information about full-
time equivalent validation.
These validations are performed independently of each other. If there are issues related to multiple validations,
the user is informed about all issues.
Note that we only validate the effective latest change Job Information record because the position doesn't
support multiple changes each day.
 Tip
We strongly recommend that you avoid changing fields that are relevant for position validation when using
transition periods. These fields are, for example, FTE, Transition Period, Position Status, Multiple
Incumbents Allowed, and Position. This ensures that the transition period is always applied correctly and
isn't impacted by any change to validation-relevant fields. For more information on Transition Periods, refer
to Transition Periods [page 148].
3.9.2 Validation Logic During Import
Here's information about the validation logic during import.
Validation Logic During Import

If one Job Information record for a given position fails during any of the validations of the Job Information
import, then all the Job Information records for that position fail, regardless of the user and start date. This
behavior ensures atomicity at the position level because we consider all the records from both the database
and the Job Information input template while calculating capacity. This behavior ensures data consistencies
because a partial save can lead to inconsistencies.
3.9.3 Validation in Case of Forward Propagation
Validation in Case of Forward Propagation

If forward propagation gets triggered, the corresponding changes in business data are validated. For more
information on forward propagation, refer to Forward Propagation of Data with Imports. This ensures that all
changes go through the same process and leads to a consistent behavior.

Example
User A moves from position A to position B and user B is assigned to position A. If user A can’t be assigned to
position B for whatever reason, user B can’t be assigned to position A. This is because the position validation
assumed that position A is unassigned, which is now invalid and both users can’t be transferred to the
positions.
3.10 Follow-Up Processes
3.10.1 Follow-Up Processes After Job History Import
Here's information about the follow-up processes that happen after a Job History import.
Follow-Up Processes
The follow-up processes are triggered for succesfully imported entities and run in the background.
Adapt the Hierarchy

To enable this process in import, you need to go to the Admin Center and choose Position Management
Settings. Then go to the Import tab and, under Adapt Hierarchy After Job Import, set Adapt Hierarchy to Yes.
If the position hierarchy is leading, the reporting line is automatically adapted after the Job Information History
import:
• If the employee's position assignment is changed, the manager is automatically derived based on the
position hierarchy. If the employee's position assignment is removed, the manager assignment is removed
too. Note that the employee’s manager assignment is also removed if the system can't find a suitable
manager.
• In addition, the transfer of the direct reports is triggered in a way similar to when an employee's position
assignment is changed using the MSS UI: The employee's direct reports - that is, the incumbents of the
child positions to the employee's previous position, who actually report to him or her - are transferred
either to the employee's previous manager, or to the other position incumbent (if there is one), or to no
manager - depending on the Position Type configuration if position types are used. In addition, if the
employee is assigned to a new position, the incumbents of the child positions of the employee's new
position are transferred to the new employee.
If the reporting line is leading, the position hierarchy is adapted automatically after the Job Information History
import:
• If the employee’s manager assignment is changed, the position is derived automatically, based on the
reporting line. If the employee’s manager assignment is removed, the position assignment is also removed.
Note that the employee’s position assignment will also be removed if the system cannot find a suitable
position.
• In addition, the transfer of child positions are triggered in a similar way as is the case when the manager
assignment of an employee is changed via the MSS UI. The child positions of the employee's previously

assigned position are transferred to their newly assigned position. Note that a child position is only
transferred by the system if either its parent position - that is, the employee’s previously assigned position
- has no other incumbent or, if there is another position incumbent, if all child position incumbents report
to the employee transferred to the new position.
 Note
• The imported Job Information records, whose manager/position will be automatically adapted, are
changed as a correction with the defaulted manager/position.
• For direct reports, which will be transferred to a new manager, a new Job Information record is inserted
with the new manager.
• For child positions, which will be transferred to a new parent position, a new position record is inserted
with the new parent position.
• If the system will default the manager/position of the imported Job Information records, the business
rules assigned to Job Information in the Succession Data Model will only be executed when the changes
are saved if you have switched on the Enable rules execution during Job Information import flag reached
from the Admin Center by choosing Company System and Logo Settings.
Adapt the To-Be-Hired Status on the Position

The system can automatically set the correct to be hired status of the position if an employee is assigned to a
position, unassigned from a position, or if the incumbent's FTE is changed using the Job Information import.
Take a look at Automatic Update Of "To Be Hired" Field [page 68] for more on this.
To disable this default process in import, you need to go to the Admin Center and choose Position Management
Settings. On the Import tab, set Adapt The Position 'To Be Hired' Status After Job History Import to No.
Reclassify or Transfer Positions

You can opt to have positions reclassified and transferred based on the selected event reason after a Job
History import. If you want this to happen, go to the Admin Center and choose Position Management Settings.
On the Import tab, set Execute Reclassification Or Transfer After Job Information Import to Yes.
No reclassification is executed if the imported job info records have already been changed because of a
hierarchy adaptation.
For cases in which reclassification and transfer are not triggered, refer to the note in Position Reclassification
and Position Transfer, given in the Related Information section.
Job Relationship Sync

You can synchronize changes to job relationships when a matrix position is assigned or changed through the
Job Information import.
To do this, go to Admin Center Position Management Settings , and on the import tab, Set Execute Job
Relationship Sync to Yes. Then choose the following options for Job Relationship on Position Assignment to
determine how the system synchronizes job relationships when a position is assigned or changed after Job
information import.
• Sync Position Matrix to Job Relationship: Choose this option to sync position matrix to job relationship
when the changed position is a matrix position.
• Retain Existing Job Relationship: Choose this option to retain the existing job relationship when the
changed position is a matrix position.

 Note
By default, the system sends a result email for the follow-up processing in cases of both success and error.
If you want to only receive the result email if an error has ocurred, you can enable this by following the steps
given in the related links.
Related Information
Job History Imports

Data Validation for Job Information (MSS and History UI)
Configuring the Result Email for Only Errors [page 123]
3.10.2 Follow-Up Processes After Termination Details Import
Here's information about the follow-up processes that happen after a Termination Details import using
centralized services.
 Note
To use centralized services for Termination Details Import, under Admin Center Search Tools , enter
Company System and Logo Settings. The setting, Enable Centralized Services for Termination Details
(Applicable only for data imports from UI and API), must be selected. For more information regarding the
Termination Details Import, please refer to Termination Details Imports in the related links.
Position Follow-Up Processes
The position follow-up processes are triggered for employees whose employments have been successfully
terminated and run in the background.
Adapt the Hierarchy

If the position hierarchy is leading, the system assigns the direct reports of the employee whose employment
was terminated to a new manager according to the position hierarchy.
If the reporting line is leading, the system doesn't adapt the hierarchy after the Termination Details import has
finished.
 Note
• Follow-up processes are triggered only on initial termination of the employment, not for corrections.
• For direct reports, which are transferred to a new manager, the system inserts a new Job Information
record.

• When terminating the employment of a job relationship manager, the job relationships of the related
employees aren't updated, even if there's a position matrix relationship.
Adapt the "To Be Hired" Status on the Position

The system can automatically set the correct to-be-hired status of the position if the employment of an
employee is terminated. Refer to Automatic Update Of "To Be Hired" Field [page 68] for more information.
 Note
By default, the system sends a result email for the follow-up processing in cases of both success and error.
If you want to only receive the result email if an error has occurred, follow the steps given in the related
links, Configuring the Result Email for Only Errors.
Related Information
Termination Details Imports

Configuring the Result Email for Only Errors [page 123]
Error Handling for Job History Import and Termination Details Import [page 121]
3.10.3 Error Handling for Job History Import and Termination

Details Import
Here's information about error handling during follow-up processes after Job History import and Termination
Details import.
If errors occur while the position logic is being processed, an Import Queue Monitor instance with the
information about the error is created. An email notification is sent with the information about the newly
created Import Queue Monitor object.
You can load the Import Queue Monitor from the Admin Center by choosing Manage Data, selecting Import
Queue Monitor as object type and selecting the code you received by email. You can do this for up to 90 days
after the original import. After 90 days, the ImportQueueMonitor object will automatically be permanently
deleted in order to ensure that too many objects don’t build up and start impacting system performance.
 Note
You can configure the searchable fields of the Import Queue Monitor object to make it easier to search for
an object. Then, you can search for the object by userID and start date of the imported record. To do this,
you must add items.objectKey to the searchable fields of the Import Queue Monitor object definition.
"Items" of items.objectKey refers to the associated Import Queue Monitor Item. Refer to Adding Searchable
Fields in the Implementing the Metadata Framework guide given in the related links for information on how
to do this.
The object itself has information about the status and the email address to which the error was sent stored at
root level. The user who triggered the import receives the email. If a user works on behalf of another user by

means of a proxy, both users receive the email. Additionally, the change source indicates which action triggered
the follow-up processes, that is, either the Job Information import or Termination Details import.
A separate item is stored in the monitor for each imported Job Information record that was a source of the
position process failure. Each item has the following information:
• Status
The status of the imported records follow-up process.
• Object Type
The type of the imported source record. At this time, only Job Information is supported.
• Object Key
External business key of the imported source record. It has the format "<user ID>|<start date>|<sequence
number>".
• Data Operation
Operation performed on the source record (INSERT, CORRECT, or DELETE).
• Module
The module that raised the follow-up error. At this time, only Position Management, Time Off and Global
Assignment use this feature.
• Message
Detailed error message raised by the module.
You can review the error message items one by one and check whether you can correct the error manually. If
so, you can manually initiate the reprocessing of the failed record by changing the Action of the monitor to
Import Resend. Then save the monitor.
If the system can now process the failed records, the complete monitor is deleted and a success email is sent.
If there are still errors, the monitor is updated with the new error information. Another error email is sent if the
setting, Admin Center Company System and Logo Settings Send result email for Job History import and
Termination Details import follow-up processing only if an error occurred , is deactivated.
Related Information
Adding Searchable Fields

Termination Details Imports

3.10.4 Configuring the Result Email for Only Errors
Configure the result email so that you only receive it if there's an error.
Context
By default, the system sends a result email for the follow-up processing in cases of both success and error. If
you want to receive the result email only if there is an error, follow these steps:
Procedure
1. To configure the email notification, go to Admin Center, and in the Search Tools field, enter Company
System and Logo Settings.
2. Select the email notification, Send result mail for Job Information import follow-up processing only if an
error occurred.
3. Select Save Company Settings.
Results
You have successfully configured the result email to be sent only in case of errors.
3.11 Event Reasons for Imports
3.11.1 Configure Event Reasons for Job History Import
There are different configuration options for the event reason to be used for the adaptation of the manager
when Job Information records are being imported.
The event reason can either be:
• a fixed event reason

• an event reason derived using event reason derivation
• the event reason from the original import record
. There's some setup work to do before all these options are available.
1. If you want the event reason derivation to be available, you need to switch on Enable Business Rules for
Event Reason Derivation for your company in Provisioning.

 Caution
Be sure not to activate the Enable Business Rules for Workflow Derivation option directly below event
reason derivation at the same time as you activate event reason derivation.
 Note
 Remember
Product Support.
2. Go to Admin Center Position Management Settings .

On the Import tab, you find the Adapt Hierarchy During Job Information Import section. Here, you can:
1. Define whether the nonleading hierarchy is adapted during the Job Information import.
2. Select an event reason for the manager or position assignment change.
 Note
The selection of an event reason for the manager or position assignment change is only relevant if
you have selected to adapt the hierarchy.
3. Specify whether the event reason is ignored.
 Note
The Ignore Event Reason Derivation option only appears if you activate event derivation as
described above.
3. The default sequence looks like this:

• Event Reason Derivation used
• If you set the Ignore Event Reason Derivation option to No, the event reason derived using business
rules for the supervisor/manager change.
• If you set the Ignore Event Reason Derivation option to Yes, the event reason selected in the Event
Reason For Supervisor/Position Assignment Change field in Position Management.
• The original event reason from the Job Information record.
• Event Reason Derivation not used
• The event reason selected in the Event Reason For Supervisor/Position Assignment Change field in
Position Management Settings.
• The original event reason from the Job Information record.
 Note
Even if the event reason derivation is suppressed in Position Management Settings - that is, Ignore Event
Reason Derivation is set to Yes - all rules are executed, if the user has the permission to do that.
This means that, whenever there is an onSave rule that does not check the previous event reason for null, it
overwrites the event reason used. This is because we first set the event reason and then execute onSave
rules on Job Information.

Event Reason Written to Record
The system writes an event reason to the Job Information record that is created after the Job Information
import. The following table lists the possible entries.
Table 18: Event Reasons

Event Reason Derivation Event Reason Created in the new Record
Active • If you set the Ignore Event Reason Derivation option to

No, the event reason derived using business rules for
the manager/position change.
• If you set the Ignore Event Reason Derivation option to
Yes, the event reason selected in the Event Reason For
Supervisor/Position Assignment Change field in Position
Management.
Deactivated • The original event reason from the Job Information re
cord.
• If no event reason is specified in the Job Information re

cord, the event reason selected in the Event Reason For
Supervisor/Position Assignment Change field in
Admin Center Position Management Settings.
Import .
3.11.2 Configure Event Reasons for Termination Details

Import
There are different configuration options for the event reason to be used for the adaptation of the manager
when Termination Detail records are being imported.
The event reason can either be:
• an event reason derived using event reason derivation

• a fixed event reason
There's some setup work to do before these options are available.
• If you want the event reason to be derived using event reason derivation, you must make event reason
derivation available.
You need to switch on Enable Business Rules for Event Reason Derivation for your company in Provisioning.
 Caution
Be sure not to activate the Enable Business Rules for Workflow Derivation option directly below event
reason derivation at the same time as you activate event reason derivation.

 Note
 Remember
Product Support.
• If you want the event reason to be a fixed one, event reason derivation must be deactivated.
If so, go to Admin Center Position Management Settings .
On the Hierarchy Adaptation tab, you can
1. Define whether the nonleading hierarchy is adapted during the Termination Details import.
2. Select an event reason for the manager change in the Event Reason For Assigning Employees to New
Manager field.
Event Reason Written to Record
The following table lists the possible entries.
Table 19: Event Reasons

Event Reason Derivation Event Reason Written to Record
Activated • The event reason derived using business rules for the
manager change.
Dectivated • The event reason selected in the Event Reason For

Assigning Employees to New Manager field on the
Admin Center Position Management Settings
Hierarchy Adaptation tab
3.12 Moving Positions When Changing An Employee's

Manager Assignment
Set up the system so that, when an employee gets a new supervisor, his or her position is also moved.
Prerequisites
• The Option to move Position to New Manager on Job Info Change permission must be set under Manage
Position in Permission Settings.
• Users making this change in the job information must have the View Current permission for the Position
object. Otherwise, the button, Move currently assigned position below new Supervisor’s Position, does not
appear in the Job Information.
• The position hierarchy must be the leading hierarchy.

• The employee is assigned to a position and the position assignment isn't changed.
• The employee's new manager is assigned to a position.
• The manager change is done in MSS.
• The Supervisor field is configured, using manage business configuration, as part of the job information
section.
Effect
• If an employee gets a new manager, users with the relevant permission are asked to decide whether the
employee's position should also be moved to the new manager.
• If the user decides yes, the position is transferred along with the employee. All lower-level positions of
the position are moved as well, including their incumbents. If the position to be moved allows multiple
incumbents, all incumbents are moved at the same time.
• If the user decides no, then the employee is moved but the position is not.
3.13 Showing Pay Range on Position
You can show the pay range or details of it as transient fields on the position. The calculation of the pay range is
executed with the same derivation as for job information.
Prerequisites
• Pay Range is a transient, invisible field on the position. "Transient" means that the content of the field isn't
saved to the database, but is calculated on-the-fly.
Here's how you can change the visibility:
2. Select the Position object and choose Details for the Pay Range field.
3. Change the visibility to Read Only and save the Position object.
• Calculating the pay range for a position depends on the job information configuration. This means that all
fields for job information need to be configured with the same data types as for the position. If the pay
range depends on a custom MDF object, for example, a field with this data type must exist in both Position
and Job Information.
• You are using the standard UI, meaning that no default screen is entered in the Position object. For details
on this, see KBA 2458839.
Setting Up The Pay Range
Pay Range Calculation Rule
You can use a rule to define how the pay range is calculated. There's a rule function called Get Pay Range By
Position(). Take a look at the rule function documentation [page 132] for details.

Here's an example of how the rule could look.
Derive Pay Range Attributes
You can also set attributes of the pay range to custom transient field. Before you enhance the rule, add the
custom string field to the object definition of the position.
Show Pay Range When Page is Loaded
If you want the pay range to be calculated when the Position is shown on the UI, you need to assign the rule as
an onLoad rule for the Position object. Here's what you do:
1. Go to the Admin Center and choose Manage Data.

2. Create a new Object Configuration for object type Position.
3. Add your new pay range calculation rule in the Manage Data On Load Rules section.
Trigger Pay Range Determination During Edit Mode
When you want to trigger the calculation of the pay range when the position is being edited, you need to add
the pay range calculation rule as onChange rule to all the fields that alter the determination of the pay range
such as location, job code, and legal entity. You do this by going to the Position object definition, clicking Details
for a field, and adding the rule.
Derive Pay Range Attributes at Specific Point in Time
You can define a rule that derives the pay range attributes for a specific date, such as today. There is a rule
function called Get Pay Range Attributes, which you can use on string fields. Take a look at the Rule Functions
in Position Management [page 132] documentation for details.

Before creating the rule, you need to add custom string fields to the object definition of the Position for the pay
range attributes such as Mid Point. Here's a rule example.
Example for Pay Range Calculation and Pay Range Attributes Derivation with Specific Behavior for
Position Records in the Past and Future
Now, we'll look at an example showing a calculation of the pay range calculation and the derivation of its
attributes with different behavior for records in the past and records in the future.
When you view historical records of the position, the pay range is derived for the end date of the record.
When you view future dated records, the pay range is derived with the start date of the record.
If you view records valid on the current date, the pay range is derived with the current date.

Restrictions
There are some restrictions on using the pay range feature:
• The pay range is only calculated in Manage Data, Manage Positions, or the Position Quickcard in the
position organization chart. It is not calculated on other pages such as the workflow approval page.
• You can't configure the pay range field into the Position tile via Org Chart Configuration for the position
organization chart.
• If pay range field values are being imported for positions, this is not stored in the database as the data is
calculated on load.
• You can't use the pay range to derive dynamic groups.
3.14 Business Rules in Position Management
Rule scenarios and rule functions specific to Position Management are available.
Rule Scenarios Available in Position Management [page 131]

Various different rule scenarios are available in Employee Central Position Management.
Rule Functions in Position Management [page 132]

Position Management includes a number of rule functions, making it easy to arrive at certain data.
3.14.1 Rule Scenarios Available in Position Management
Various different rule scenarios are available in Employee Central Position Management.
Here's a list of the scenarios:
• Synchronize Position Changes to Incumbents

You can use this scenario to synchronize changes of a position to the incumbents. You must first register
the rule in Position Management Settings, in the Rule for Synchronizing Position to Job Information field on
the Synchronization tab. The rule should also be triggered if the position field is changed in job information.
• Map Fields from Position to External Job Requisition in Fieldglass Integration
You can use this scenario to define the field mapping between a position and the external job requisition to
be created in Fieldglass. You must first register the rule in Position Management Settings, in the Rule for
Mapping Fields between Position and Fieldglass field.
• Synchronize Incumbent's Changes to Position
You can use this scenario to synchronize changes in an incumbent’s job information to the assigned
position. You must first register the rule in Position Management Settings, in the Rule for Synchronizing Job
Information to Position field on the Synchronization tab.
• Default Position Attributes in Position Organization Chart
You can use this scenario to default values if a new position is created in the position organization chart
using the Add Lower-Level Position action or the Add Peer Position action. You must first register the rule in
Position Management Settings, in the Rule for Defining Copy-Relevant Position Fields field on the UI
Customizing tab.

• Update Rule for Mass Change Run
You can use this scenario in a mass change run to define the target criteria of objects to be updated, as well
as the updated values.
• Unassigned Incumbent from Position for Right to Return
You can use this scenario to decide whether an incumbent should be unassigned from the position in a
right to return scenario or not. You must first register the rule in Position Management Settings, in the
Unassign from Position field on the Right to Return tab.
• Create Right to Return for Incumbent
You can use this scenario to decide whether a right to return should be created in the incumbent's position
in a right to return scenario or not. You must first register the rule in Position Management Settings, in the
Create Right to Return field on the Right to Return tab.
• Derive Job Requisition Template in Recruiting Integration
You can use this scenario to derive the job requisition template ID that should be used for the job
requisition. You must first register the rule in Position Management Settings, in the Rule for Deriving Job
Requisition Template ID field on the Integration tab.
• Map Fields from Position to Job Requisition in Recruiting Integration
You can use this scenario to define the field mapping between the position and the job requisition to be
created. You must first register the rule in Position Management Settings, in the Rule for Mapping Fields
Between Position and Job Requisition field on the Integration tab.
3.14.2 Rule Functions in Position Management
Position Management includes a number of rule functions, making it easy to arrive at certain data.
Get Incumbent By Position
Use this rule function to find out who occupies a particular position as of the specified date. You need to enter a
position code and a date. The rule will look like this:
As the help text says, the rule returns the user ID of the incumbent of the position. If more than one incumbent
satisfies the rule, only one is returned.

Get Matrix Position Code By Type
This rule function returns the code of the matrix position that is assigned by the specified type.
Get Next Available Manager By Position
Use this rule function to determine the available manager closest in the hierarchy to the current position.
Get Number Of Child Positions
Use this rule function to determine how many positions are child positions to the current position.

Is Position Below User's Position In Hierarchy (Old Version)
Use this rule function to determine whether a position is in a user's hierarchy and, if so, is below that user's own
position in the hierarchy.
 Note
You cannot use this version of the rule function to create new positions - for example, when adding lower-
level positions in the position organization chart.
Is Position Below User's Position In Hierarchy (New Version)
Use this rule function to determine whether a position is in a user's hierarchy and, if so, is below that user's own
position in the hierarchy.
 Note
You can use this version of the rule function to create new positions - for example, when adding lower-level
positions in the position organization chart.
Pay Range
There are 2 rule functions associated with the pay range.
Get Pay Range By Position
Use this rule function to determine the pay range of a position. The pay range is determined using associations
with Foundation Objects, such as Location or Job Code. You need to enter a position and a date.

Get Pay Range Attributes
Use this rule function to determine the attributes of a pay range such as Minimum Pay, Maximum Pay, Mid
Point, Currency, and Frequency. You need to enter a pay range, the pay range field, and a date.
Features
It is possible to combine rule functions. Here's an example, combining the Get Incumbent By Position rule
function with the Get Matrix Position Code By Type rule function.

3.15 Configuring the Position Default or Supervisor Default
You can have the system default the supervisor or position from the job information. You can also switch off this
default.
How does this work?
• If the position hierarchy is the leading hierarchy or if you don't have a leading hierarchy, the supervisor is
set to the default value in the event of a change to the position.
• If the reporting hierarchy is the leading hierarchy and there is a change of supervisor for the position, the
Position Under Manager field is set to the same value as the new supervisor. This means that it is either
cleared or a new position is set.
You can opt to switch off this defaulting process in the Hierarchy Adaptation tab of the Position Management
Settings. To do this, select No in the Default The Supervisor Or The Position In Hire, MSS Job Information And
History field. None of the processes described then takes place.
3.16 Using the Check Tool to Solve Issues
Get an overview of potential problems and errors in your configuration that you can try to solve yourself before
you contact Product Support about an issue.
Prerequisites
• You've enabled the Metadata Framework.

• You have the following Administrator Permissions Check Tool permissions:
• Access Check Tool authorizes users to access the tool.
• Allow Configuration Export authorizes users to attach configuration information to a ticket.
• Allow Check Tool Quick Fix authorizes users to run quick fixes for the checks that have this feature. A
quick fix can be used to immediately correct any issues found by that check.
For more information about role-based permissions, refer to List of Role-Based Permissions.
 Tip
Refer to Guided Answers for the Check Tool for a guided navigation through the available check tool
checks and more information on each check.
Context
The check tool provides an overview of the issues found in the system. New checks that are being added in a
new release go through a first initial run to return a result. After the initial run, checks are run on a regular basis
(at least monthly). We recommend you open the check tool after the upgrade to a new release to see if issues
have been found by new checks.
In addition to these runs performed by the system, you can also run individual checks after you made changes
to the system, for example, after updating data models or picklists. For more information, refer to the
application-specific documentation.
Procedure
1. Go to Admin Center Check Tool .
The Check Tool page opens displaying the results of the first tab System Health.
2. Depending on the check type of the check you're interested in, select the corresponding tab.
Tab Description
System Health Displays configuration checks that have returned errors or

warnings after the last run. We recommend you solve
these in a timely manner.
To display all checks, select all result types in the Result

Type search filter and select Go.
Migration Displays the migrations that are still pending, either be
cause the check tool couldn't automatically migrate all is
sues or because new issues have been found after the last
run. We recommend you solve these in a timely manner.

Tab Description
To display all checks, turn on the Show completed

migrations also search filter and select Go.
Validation Displays a list of all validation checks.
 Note
Validation checks require one or more parameters for
execution, therefore we can't run these checks auto
matically. You need to enter input parameters and run
the corresponding check manually to get results.
3. To solve a check that returned issues, click on it.
The detail view opens to the right side of the screen with more information on the check and on how to
solve the issue.
4. Evaluate the results and resolve the issues. If the check provides a quick fix that you can use to
immediately correct issues found during a check run, select the Quick Fix button.
5. If you encounter an error you can’t resolve, contact Product Support by creating a ticket.
Next Steps
To verify that you've solved the underlying issue, select the checkbox for the corresponding checks and choose
Run Checks. You can also wait until the next automatic run to see if the issue has been solved.
 Note
If the check you selected requires one or more prechecks (checks that need to be run successfully first),
the prechecks are run first even if you haven't selected them.
Related Information
Running Checks [page 139]

Using the Quick Fix Feature [page 144]
3.16.1 Benefits of the Check Tool
The SAP SuccessFactors check tool helps you identify and resolve issues when your system doesn’t work as
you expect.
If your SAP SuccessFactors applications are behaving in unexpected ways, it is likely that it has a configuration
or data conflict: you have some data that is inconsistent or a configuration error. The check tool quickly

identifies these types of problems so that you can avoid support tickets. You might still need to create a
support ticket if the problem is severe, but even in severe cases, the check tool can save you time because it
can export the results of the check and your configuration for Product Support. The support engineer,
therefore, can identify the issue more quickly.
When you open the check tool, you see:
• A list of issues in your configuration or data and the severity of each issue.
• A solution or recommendation to address the issue.
3.16.2 Running Checks
Trigger the execution of individual checks to find potential issues in the system, or to check if an issue has been
solved in the meantime.
Prerequisites
• You've enabled the Metadata Framework.

• You have the following Administrator Permissions Check Tool permissions:
• Access Check Tool
• Allow Configuration Export
• Allow Check Tool Quick Fix
Context
In addition to the job runs performed automatically by the system, you can also run individual checks. For
example:
• You want to check if the issue has been solved.

• You want to run a check as a prerequisite or post-step of a task. For example, you made changes to the
system (such as updating data models or picklists), and you want to verify your changes didn't cause any
new issues. For more information, refer to the application-specific documentation.
• Validation checks need to be run manually as they require input parameters.
Procedure
The Check Tool page opens displaying the results of the first tab System Health.
2. Depending on the check type of the check you want to perform, select the corresponding tab.

A list of checks is displayed in the results table according to the predefined selection criteria.
3. Optional: If the check you're searching for is not listed in the results table, adjust the selection criteria and
choose Go.
You get a list of checks that fulfill the selection criteria you've entered.
4. Select the corresponding checks, and choose Run Checks from the top right of the results table.
 Note
Please note that for checks on the Validation tab, you can only select one row at a time. Execution of
multiple checks at once is not possible.
Also, for validation checks you need to enter the required input parameters when running a check.
 Note
If the check you selected requires one or more prechecks (checks that need to be run successfully
first), the prechecks are run first even if you haven't selected them.
The Results column displays any issues found.
Next Steps
Investigate and solve the underlying issue.
3.16.3 Check Types
Overview of the different check types and their purpose.
The check type groups those checks that have a common purpose. On the Check Tool page, each tab
represents a check type.
Table 20: Overview of Check Types

Check Type Description Automatic Job Runs
System Health Checks that run without parameters • Automatic initial run at the begin
and check configuration and data is
ning of a new release
sues that need to be fixed.
• Periodic runs (usually monthly)
The predefined selection criteria dis
plays only those that have returned er
rors or warnings after the last run. We
recommend you solve these in a timely
manner.
To display all checks, select all result

types in the Result Type search filter
and select Go.

Check Type Description Automatic Job Runs
Migration Checks that perform an automatic mi • Automatic initial run at the begin
gration of features. ning of a new release
When you open the page, only pending

• Periodic runs (usually monthly)
migrations are displayed. To display

also the competed migrations, turn on
the Show completed migrations also
search filter and select Go.
Validation Checks which need one or more param Only triggered through user
eters for execution, for example:
• A specific template
• A specific user
• A specific time frame
Validation checks can be triggered by

single selection and choosing the Run
button. A popup appears with input
fields for the parameters. Execution of
multiple checks at once is not possible.
3.16.4 Check Results
After you run checks in the check tool, it returns the results of the check so that you can resolve issues that it
found.
The results of a check are displayed in the Result column. If you run the checks multiple times to see how
you’re resolving issues, you can select a previous result from the History dropdown list.
 Note
To display the History dropdown list, click on a check. On the details screen that opens on the right side of
the page, expand the header. The History dropdown list is directly below the check title.
Table 21: Possible Results of Check Tool
Result Action
No issues found If the tool can’t find issues, you see a green check mark in the Result column.
Issues found If the tool finds issues, it reports the number of issues and a yellow warning icon or a red
alarm icon.
• The yellow icon indicates a low severity issue. The system proposes a solution.
• The red icon indicates a high severity issue. You must take action, which could include
creating a support ticket.

Result Action
Pending migrations If the tool finds pending migrations that need to be completed by the user, you can see a yel
low warning icon or a red alarm icon in the Status column on the Migration tab.
Completed If the tool finds no issues with migration, or the migration has already been completed, you
see a green check mark in the Status column on the Migration tab.
 Note
• The maximum text size of a cell is limited, which can result in the text being truncated in the Result or
Details column. Select the Export Results button to download the check results and view the complete
text.
• The downloaded check result table can display a maximum number of 10,000 rows.
Related Information
Creating Product Support Tickets from the Check Tool [page 142]
3.16.5 Creating Product Support Tickets from the Check Tool
When the check tool reports a serious issue that you can't solve, you might need to contact Product Support.
You can create a support ticket from within the check tool.
Prerequisites
You've run the check tool. You can find the check tool by going to Admin Center Check Tool . You create
the ticket from the details page of the tool.
Procedure
1. Click on the check you can't solve.
The detail view opens to the right side of the screen with more information on the check and on how to
solve the issue.
2. On the Result tab, scroll down to the results table to look for the errors you want to report on.
You usually contact Product Support for high severity issues not low severity issues.
3. On the Check Information tab, under Need Assistance?, copy the component ID.
For example, LOD-SF-EC is the component ID for Employee Central.

4. Create a customer incident in the relevant category.
5. When you create the ticket, paste the component ID into the ticket.
3.16.6 Exporting Configuration Information
Export the configuration information from your system and attach it to the Support ticket created from the
check tool. This information can help Support identify the issue of a check you can't solve yourself.
Prerequisites
You have the Administrator Permissions Check Tool Allow Configuration Export permission.
Context
 Note
Not all applications have this feature enabled.
Procedure
The Check Tool page opens.

2. In the top-right corner, select Use legacy Check Tool UI.
The legacy check tool UI opens with a list of all applications for which you can use the check tool.
3. Select the corresponding application.
If the application has the export configuration feature enabled, you can see an information message at the
bottom of the page with a link.
4. Choose the Export Configuration link in the information message.
Results
The system downloads a file with the configuration information for the application you’ve selected.

Next Steps
Attach the downloaded file to the Support ticket you created from the check tool.
3.16.7 Using the Quick Fix Feature
The check tool includes a quick fix feature that you can use to immediately correct issues found during a check
run.
Prerequisites
The checks which you want to solve with a quick fix have run and provide a check result with error or warning.
Procedure

2. Click on the corresponding check you want to fix.
The details screen opens on the right side of the page with more information about the check. If the check
includes a quick fix, the Quick Fix button is displayed on the Result tab, under Proposed Solution.
3. Choose Quick Fix to start fixing the issue.
A third screen opens to the right side, with step 1, called Select Correction, that shows one or more
corrections for the issue.
4. Select the correction you want to carry out and choose Step 2 to proceed to Final Approval.
In the Final Approval step, you can opt to change your mind and not carry out the fix.
5. If you want to proceed, choose Step 3.
The system confirms that the fix is now running.

6. Choose Close to complete the procedure.
The system verifies that the fix has run correctly after a short time by running the check again.

3.16.8 Exporting a List of All Checks
Get an overview of all checks available in the system by exporting a CSV file.
Procedure

2. In the top-right corner, select Export all checks.
A CSV file with all checks available in the system is downloaded, including check descriptions and
application area.
 Note
The list includes also checks that you can’t access from the user interface if you don’t have the
corresponding applications set up, or if you lack the required permissions.
3.17 Automated Daily Hierarchy Adaptation
There are some situations in which the hierarchies aren't in sync.
Prerequisites
 Remember
Support.
You have the Administrator Admin Center Permissions Monitor Scheduled Jobs permission.
You have the Manage User Allow users to view all the jobs. (By Disabling this option, users can view only
their job status.) permission to access to results of MDF jobs. Otherwise, you can view MDF jobs but only
have access to results of MDF jobs that are submitted by you.

Context
For example, if you assign employee E0 to position A today and position A has position B with incumbent E1 as
parent position, the system derives E1 as the new supervisor for employee E0. If position A already has a new
parent position with incumbent E2 assigned for the future, the assignment of supervisor E1 will be wrong for
employee E0 with the beginning of the new parent position assignment.
To fix such inconsistencies, you can schedule a job that sets the correct supervisor based on the position
hierarchy.
Procedure
1. Go to Provisioning and schedule the Position Management Daily Hierarchy Adaptation job with daily
recurrence.
2. Go to the Admin Center and choose Position Management Settings. In the Hierarchy Adaptation tab, you
can switch on the feature in Automated Daily Hierarchy Adaptation.
 Note
The report is designed to adapt the hierarchy on a daily basis, not to maintain, update, or correct data
in bulk and not to adapt supervisor information in the past. The supervisor is set on the date the job
runs. The first time you run the job, make sure that the data has been imported/migrated correctly.
3. You can use the Offset in Days to specify the offset in future days to be considered by the daily hierarchy
adaptation. If you want to adapt the hierarchy at the date on which it gets out of sync, set the value to 0. If
you want to adapt it 1 week before it gets out of sync, set the value to 7.
4. You can download the result of the Position Management Daily Hierarchy Adaptation job. Choose Admin
Center Scheduled Job Manager Job Monitor . Filter for job type Position Management Daily Hierarchy
Adaptation. Choose View Details Download Status .
Results
You get a visualization showing that the hierarchies are out of sync.
• If the hierarchy of an employee is out of sync on a future date and will be adapted by the Position
Management Daily Hierarchy Adaptation job, this is shown with an icon next to the effective date in the
employee’s Job Information History UI.

• Detailed information about the change is displayed if you click this icon. In the example shown below, the
employee’s supervisor will be changed twice in the future. This could be because a new parent position
assignment of the employee’s assigned position or because a new incumbent assignment of the parent
position of the employee’s assigned position.

3.18 Transition Periods
A transition period occurs when an employee leaves a position and a successor is appointed to that position
before the incumbent leaves it. This means that the position is overstaffed for that time.
Configuring Transition Periods
There's some setup work to do before transition periods are possible in your system. To make the necessary
settings, go to the Admin Center and choose Position Management Settings, then open the Transition Period
tab. Here's what you do then:
• Set Use Transition Period to Yes.

• Specify how long the transition period should last by entering a number in the Period field and choosing
either Days or Months in the Unit field.
For example, to specify a transition period of 3 months, enter 3 in the Period field and choose Months as
the unit.

 Note
If the multiple incumbents are allowed for the position or if it has shared FTE, the Position Controlled flag on
the position must be set to yes. For more information, refer to the Related Information section.
Transition Periods in Position Types
If you are using position types, you can make the transition period settings in the relevant position types. To do
this, access the relevant position types and make the settings as previously described. Settings entered in this
way always override any settings entered in Position Management Settings.
Look at the Position Types [page 85] documentation for full information on how to use them.
Transition periods and 'To be hired' field
The To Be Hired field on the position also has an impact on assigning employees to a position using transition
periods. This depends on your configuration. For more information, please refer to step 9 of the procedure of
Setting up the Automatic Update of "To Be Hired" Field given in the related links.
 Note
If you want the the transition period to overwrite the check against multiple Incumbent and against the FTE,
the Position Controlled flag on the position must be set to yes.
Related Information
Setting up the Automatic Update Of “To Be Hired” Field [page 68]

Capacity Control [page 101]
3.19 Terminating Employment on the User Interface
Specify when and why an employee is leaving the company.
Context
Go to Company Info Position Org Chart the position organization chart
Procedure
1. Select the name of the employee

2. Choose Take Action Terminate You can specify when and why the employee is leaving, as well as any
other relevant information such as the date of their final salary.
3.19.1 Employment Termination on the User Interface
Specify when and why the employment of an employee is terminated.
 Restriction
When the employment of a job relation manager is terminated, the job relationships of the related
employees are not updated, although the position matrix relationship exists.
• By default, you also have the option to deactivate the employee's position. If you don't want this option to
be available, go to the Admin Center and choose Position Management Settings UI Customizing , and
set Show 'Deactivate Position' option in Employee Termination Screen to No.
• If an incumbent of a matrix position is being updated, the job relations for the employees of this matrix
manager are not updated.
3.20 Transferring Reports in Case of Termination
You can set the system to automatically transfer reports of a manager when you terminate the employment of
a manager.
If the position hierarchy is the leading hierarchy, you can opt in to transfer direct reports according to position
hierarchy. You can either set this as default along with the other existing selection options in the transfer direct
reports section or you can opt in to always transfer direct reports according to position hierarchy. If so, the
other selection options for transferring direct reports are no longer available.
If you default along with the other existing selection options, there are two settings that seem to do the same
thing:
• Everyone to upper manager.

• Everyone according to position hierarchy.
 Caution
Despite appearances, the settings do not do the same thing. Everyone to upper manager is purely a user-
based decision, independent of the position hierarchy. Everyone according to position hierarchy selects the
incumbent of the next available position based on the position hierarchy.
• If you use Automated Daily Hierarchy Adaptation, any transfers you make outside of the position hierarchy
are corrected by the job on the next run date.
• If the employment of an employee being terminated is a manager, you have the option to transfer their
direct reports according to position hierarchy. This means that the direct reports to be transferred because
a manager is being terminated will report to the next available manager according to position hierarchy.
This presupposes, however, that all direct reports to be transferred according to position hierarchy as well

as the manager must be assigned to a position. In addition, the employees' supervisor must be in sync with
position hierarchy. Otherwise, a manual correction is needed.
You can make this configuration by going to the Hierarchy Adaptation tab in Position Management Settings
and choosing Reassign Direct Reports According to Position Hierarchy on Termination Screen. In any case,
only the direct reports are transferred, not the positions in the hierarchy. At this time, there is no option to
transfer positions like this. If you want to transfer them, you have to do so manually or by using mass
change of positions.
The transfer according to position hierarchy respects the threshold defined in the Threshold for running
Adoption of Reporting Line and Job Relations as a job field on the Hierarchy Adaptation tab in Position
If the position to which the direct reports are being transferred has more than one incumbent, the direct
reports are assigned to the first incumbent the system finds. You don't have the option of selecting one.
Note also that the position the manager is leaving remains in the position organization chart, even though it
is now empty. The position organization chart is not modified.
• When you select the Everyone according to position hierarchy option, the Transfer Event Reason set in
Position Management Settings is used unless event derivation is enabled.

4 Integration of Position Management With
Other Applications
Position Management has the scope to integrate and interact with different applications to make its features
more extensible and enhance the process of human experience management.
You can integrate Position Management with applications such as Recruiting Management, Fieldglass, and so
on. By integrating, you establish a channel to exchange data and create a common platform to perform various
operations and increase overall efficiency.
Position Management offers a way of integration that has little or no impact on your existing system functions.
In addition, it offers value added services, such as event generation, that can be subscribed by integrated
applications to automate certain processes.
Find more information about how to integrate Position Management with the application of your choice from
the following documentation.
4.1 Setting Up Integration with Recruitment
Integration between Position Management and Recruitment Management (RCM) brings many benefits.
Context
 Note
The information given here describes oData-based integration. SFAPI integration is no longer supported.
For details of how to migrate, take a look at the Changing Integration with Recruiting from SF API Basis to
New Basis [page 168] documentation.
Once integration is in place, you can:
• Create a job requisition from a position in the position organization chart:

• Automatically determine the job profile for the requisition created.
• If you create on the current date, a job requisition is created immediately in RCM.
• If you create as of a future date, a job requisition processing request is created immediately. Quartz
Job automatically creates a job requisition in RCM when the creation date is reached.
• Note that job requisitions can only be created for positions with status Active.
• Show assigned job requisition or position requisition processing request on the position tile.
• Show more job requisition data in the position side panel.
• Use the Rules Engine to derive the job requisition template to be used for the new requisition.

152 PUBLIC Integration of Position Management With Other Applications
• Use the Rules Engine to define field mapping between the position and the new requisition.
• Use Job Scheduler to automatically create the job requisition from request objects.
• Automatically assign the candidate from the job requisition in “Pending Hires” to the position linked to that
requisition.
Here's an illustration of how all this works when integration has been set up.
To use integration between Employee Central Position Management and RCM, you need to have a system
where both these modules are enabled and configured. Here's what you need to do to set up the integration.
Procedure
1. Activate RCM integration. You do this in Position Management Settings by entering Yes in the Use
Recruiting Integration field on the Integration tab.
2.  Note
When carrying out this step we recommend that you always use the default name for the job
requisition template, since changing or translating the name can cause problems when attempting to
load the template later.

Integration of Position Management With Other Applications PUBLIC 153
You can derive the default name from either the Job Requisition Template XML file or on the Manage
Templates screen in the Admin Center.
Next, create the rule to derive the job requisition template. You need this if you want to create a new
requisition from the position organization chart. Create the rule using the Derive Job Requisition Template
in Recruiting Integration scenario. You can derive the template based on any attributes of the position.
Below is an example, showing that template Job Requisition for Consultants is used if the position has
company=Terra AG. If the position has jobCode=Consultant, the "Job Requisition for Consultants"
template is used. In all other cases, a message is raised to the effect that you can't create a job requisition
for this position.
3. If you want to use custom fields in RCM integration, make sure that your custom fields are visible. To do
this, set the attribute "custom" to "true" in the job requisition template XML. If you don't, you will not be
able to map data to this field when you create the requisitions from the position organization chart.
 Note
The templates used for integration must always have the following standard fields.
• numberOpenings
• std_position_obj or positionNumber

You don't need to map these fields using a rule because the system fills them automatically.
4. Now create the separate rule required to define field mapping. You do this using the Map Fields from
Position to Job Requisition in Recruiting Integration scenario in Configure Business Rules.
In the rule itself, you can define field mappings based on the template derived from the first rule or any
other position attribute.
 Note
• The value you type in the Requisition Field of the created field mapping object must be the Name of
the corresponding job requisition field, which you can find by going to the Admin Center and
choosing OData API Data Dictionary (under Integration Tools). If the requisition field does not
refer to a simple data type, such as a string, but instead refers to another object via navigation
path, you need to map those fields in the following format:
<fieldNameInJobReq>.<fieldNameInReferringObject>. For example, the field hiringManager refers
to JobRequisitionOperator with field usersSysId and must be mapped like this:
hiringManager.usersSysId.
• If you want to map fields of type Boolean or Number, you need to use the format () function.
• If you want to map fields of type Country, you need to map the Country Code (2 char) value - for
example, US for "United States".

• You need to make sure that all required fields of the corresponding job requisition template are
mapped with a value. Otherwise, the job requisition cannot be created. If you want to create the job
requisition without all required fields filled, you need to add an additional Mapping to the rule with
Requisition Field = isDraft and Field Value = true.
To map fields of type Foundation Object or Generic Object, you do as shown here:
• Create = PositionRequisitionMapping.Field Mapping
• Populate Job Requisition for Consultants with
• Text = location
• Field Value = Position.Location.Code
To map fields of type Date or DateTime, the value must be in the format yyyy-MM-dd HH:mm:ss.
Alternatively, you can use the rule function Format Date for Position to Job Requisition Mapping () as shown
here:
• Text = customDate
• Field Value = Format Date for Position to Job Requisition Mapping()
• Date = Position.Start Date
 Note
For future dated positions the Hiring Manager information is not shown.
To map fields of type PicklistOption, the Field Value must be the optionID of the picklist, you do this as
shown here:
• Text = rsn.Vacancy.id
• Field Value Text = 345
• Date = Position.Start Date

For more information, see Mapping Job Requisition Picklist Values in OData Integration [page 165].
5. With your rules now created, you need to register them. To do this, go to the Admin Center and choose
Position Management Settings, then go to the Integration tab and enter the settings as shown below.
• Use Recruiting Integration = Yes
• Rule for Deriving Requisition Template ID = Get Requisition Template
• Rule for Mapping Fields Between Position and Requisition = MapReqFields
6. At this stage, your system is in the default setting, which means that no user is allowed to create or view job
requisitions in the position org chart. To change this, you need to assign the Create Job Requisition in
Position Organization Chart role-based permission and/or the View Job Requisition on Position Organization
Chart role-based permission. To do this, go to the Admin Center and choose Manage Permission Roles,
then scroll down to Manage Position and make the assignment.
7. To ensure that the requisitions planned for creation in the future are actually created, you need to schedule
a periodic job to take care of this. To do this, go to Provisioning for the relevant company and choose
Manage Scheduled Jobs Create New Job .
 Remember
Support.

Select a “Job Name” and “Job Owner”. The job owner should be an admin user who will be notified when
something goes wrong. Select “Position requisition processing” as job type. Please ensure that the job runs
at least once a day.
When the job finishes processing, the admin user is notified whether the creation of the requisitions was
successful or not. An error message is included in the email as shown in this example:
"Creation of a requisition for position with external code Pos3."

4.1.1 Creating Requisitions in the Position Organization
Chart
You can save time by creating job requisitions directly from the position organization chart.
If you have the Create Job Requisition in Position Organization Chart role-based permission and the
corresponding position doesn’t already have a job requisition or position requisition processing request
assigned, the Create Job Requisition option is available in the menu of the position tile. You can then create a
job requisition from the position organization chart.
 Note
When you create a requisition through the position organization chart, the default recruiting team isn’t
added.
Here's the tile, showing the Create Job Requisition option:

If you choose this menu option, a popup for creating a job requisition appears:
If you have the Select Job Requisition Template in Position Organization Chart role-based permission, you can
select from the active job requisition templates when creating your job requisition.
If you choose today's date as the creation date, the system creates a job requisition with values retrieved from
the rule used for field mapping. If you choose a future date as creation date, the system creates a position
requisition processing request that is automatically converted to a job requisition on the selected creation date.

 Note
If the originator is filled in the mapping rule and the recruiting setting Use Originator’s preferred language as
the default language of a new job requisition is enabled, the default language of the job requisition is the
same as the originator’s. If the option isn't enabled, the language of the job requisition is the default
language from the job requisition template.
4.1.2 Validation for Position Job Requisition (Processing)

Request
Here's information about the validation relevant for Job Requisition Processing Requests.
The system performs a validation check when you try to delete a position for which a
• Position Job Requisition Request
or a
• Position Job Requisition Processing Request
has been created. The system also performs the validation check when you try to modify the business key of
that position (business code, start date) or set the status of the position to inactive.
4.1.3 Viewing Job Requisitions in the Position Organization

Chart
If you have the role-based permission for View Job Requisition in Position Organization Chart, and the
corresponding position has a job requisition or position requisition processing request assigned, you can see
directly on the Position tile whether a job requisition or job requisition request is assigned.
Here's the tile showing whether a job requisition is assigned:

If you click the right-hand icon of the two in the tile, you get this side panel showing the detailed information for
the job requisition.

Now, here's the tile showing that a job requisition request is assigned.

If you click the right-hand icon of the two in the tile, you get this side panel showing the detailed information for
the job requisition request.
While viewing the requisition for which the position is assigned, and the requisition has std_position_obj
and positionNumber fields configured, the job requisition is fetched based on the value stored in
std_position_obj. If std_position_obj is configured and has a blank value, or if the requisition has only
positionNumber field configured, the positionNumber is used to fetch the requisition on the Position Org
chart.
If multiple positions are configured on the requisition, the same requisition is fetched for both primary and
secondary positions.

Requisitions Position GO Position Number Remarks
Requisition 1 Position 1 Position 1 When you search for Position

1, Requisition 1 is returned.
Requisition 2 Position 2 - When you search for Position

Requisition 3 Position 4 Position 3 When you search for Position

3, Requisition 6 is returned,
as Position GO value for
Requisition 3 isn’t null.
Requisition 4 - Position 2 When you search for Position

Requisition 5 - Position 5 When you search for Position

Requisition 6 - Position 3 -
4.1.4 Mapping Job Requisition Picklist Values in OData

Integration
You can manage job requisition picklist values in OData integration.
Let's assume you have the following picklists:
A picklist field in a requisition template XML file
A non-MDF/ regular picklist

A custom field of type Picklist in the Position object definition:
In this scenario, you can use either of these configuration options:
• Use the optionID of the regular picklist as the external code of the MDF picklist.
• Use a wrapper to map the optionID of the regular picklist to the external code of the MDF picklist
Using the optionID of the regular picklist as the external code of the MDF
picklist.
Make the following entry in Rule for Mapping Fields Between Position and Job Requisition.
And here's the resulting MDF picklist. Note that the external codes of the entries reflect the optionIDs of the
non-MDF picklist.

Using a wrapper to map the optionID of the regular picklist to the external
code of the MDF picklist
1. In Configure Object Definitions, create a custom MDF object as a wrapper for the MDF picklist.

Note that it has two fields to map the external code of the MDF picklist to the optionID of the regular
picklist.
2. In Manage Data Entries, maintain the mapping for all picklist entries.
3. In Rule for Mapping Fields Between Position and Job Requisition, make this entry.
And here's the resulting MDF picklist.
4.1.5 Changing Integration with Recruiting from SF API Basis

to New Basis
If you're changing from the SF API-based integration with Recruiting to the new basis described in the chapter
Setting Up Integration with Recruitment, there's some setup work to do.
Here's what you need to do:
1. First, disable SFAPI-based integration in Provisioning by unchecking Enable Recruiting Integration with
Position Management there.

You don't need to enter your user from SFAPI -based integration for the new integration.
 Caution
Be careful about this. You can't enable this integration again once you have disabled it.
 Note
 Remember
Product Support.
2. Change the rule registered in the Rule for Deriving Job Requisition Template ID field in Position
In the new integration, job requisition templates can no longer be identified using the ID. The name is used
instead. This means that you need to set the Job Requisition Template Names in the SET condition in rules.
 Note
We recommend that you always use the default name for the job requisition template, since changing
or translating the name can cause problems when attempting to load the template later. You can derive
the default name from either the Job Requisition Template XML file or on the Manage Templates screen
in the Admin Center.
3. Change the rule registered in the Rule for Mapping Fields Between Position and Job Requisition field in
Position Management Settings.
• In the new integration, job requisition templates can no longer be identified using the ID. The name is
used instead. This means that you need to set the Job Requisition Template Names in the IF condition
in rules.
• In the new integration, job requisition SFAPI field names in the CREATE statements in rules can no
longer be used. Instead, you need to use the property names from the JobRequisition object in the
OData API Data Dictionary, which can find in the Admin Center by choosing Company Settings
OData API Data Dictionary
• Some mapping fields have the same name, such as division or location, in both SFAPI-based
integration or the new integration. However, some fields have different names. For example, the field
jobTitle in the SFAPI-based integration needs to be changed to jobReqLocale.jobTitle as the jobTitle is
now a field of the navigation target Job Requisition Locale (jobReqLocale).
• For foundation object fields, such as location, it is now sufficient to map only to external code of the
foundation object and not the string in format <fo_name> (<fo_code>).
• The originator of the job requisition will be the login user by default. If you don’t want to specify
another originator, you don’t need to map it in the rule.
• In the new integration, fields referring to PicklistOption must be mapped with the optionId instead of
the picklist code.

4.2 Integration with Succession Management
Succession Management offers different options for planning successors for employees.
If you want to plan successors based on positions, then succession allows use of the same position object and
hierarchy as Employee Central. By doing so, both modules are integrated and changes in one module show an
immediate result in the other module.
You can use permissions to show different position content to different roles. For example, you might want to
place a focus on succession-relevant fields for succession planners, while showing more job and organization
related fields to an HR administrator in Employee Central.
For further information on how to set up or migrate Succession to work with Employee Central positions, refer
to the Related Information section.
Related Information
Implementing and Managing Succession
4.3 Event Generation with Position Management
Events are system-generated phenomena that can be referred by integrated applications to take specific
actions.
Position Management now enables you to generate events whenever you create or update a given position.
These events can be subscribed by integrated applications to bring a certain level of automation in terms of the
actions required to be taken as a result. Each event stores information about the position you create or update.
Benefits of an "Event"-Based Approach
• Whenever a position is created or updated, an event is automatically triggered based on the predefined
position attributes.
• Follow-up processes can be automatically triggered after a position is created or updated, using Intelligent
Service Center.
 Note
If workflows are configured on the position object, the corresponding event is generated only after the
workflow has been approved.
Configuring Position Management to Generate Events [page 171]

Set up your system to generate events when a position is created or updated.

4.3.1 Configuring Position Management to Generate Events
Set up your system to generate events when a position is created or updated.
Context
To generate events based on your predefined position attributes, you must first set up your system accordingly.
Procedure
1. Go to the Admin Center and choose Position Management Settings.

2. On the Integration tab, select Yes from the Raise Events dropdown.
3. Save your changes.
Results
Your system is configured to generate events.
As a next step, go to Intelligent Services and define actions, such as notification.
 Note
Currently, events are generated only when you create or update a position. There are no events generated if
you delete a position or a position record.

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

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

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

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

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

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

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

additional trademark information and notices.
THE BEST RUN

SF EC Position Management en PDF

Uploaded by

Copyright:

Available Formats

SF EC Position Management en PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SF EC Position Management en PDF

Uploaded by

Copyright:

Available Formats

Implementation Guide | PUBLIC

Document Version: 2H 2022 – 2022-11-11

Implementing Position Management

THE BEST RUN

Implementing Position Management

Implementing Position Management

4 Integration of Position Management With Other Applications. . . . . . . . . . . . . . . . . . . . . . . . .152

Implementing Position Management

Change History [page 5]

What Is Position Management? [page 8]

Terms "Manager" and "Supervisor" [page 8]

Centralized Data Protection and Privacy [page 8]

1.1 Change History

Type of Change Description More Info

• Configuration Settings for the User

Implementing Position Management

New We've added information to Transition Transition Periods [page 148]

• For Transition period to overwrite

Changed We removed the New Data Model for

Type of Change Description More Info

New We've added validations of position Validations in Position Management

Implementing Position Management

We've added information about the Job

Implementing Position Management

• Create and maintain positions online with appropriate controls.

List of Role-Based Permissions

1.3 Terms "Manager" and "Supervisor"

1.4 Centralized Data Protection and Privacy

Implementing Position Management

Implementing and Managing Data Protection and Privacy

Implementing Position Management

Important Initial Settings for Position Management [page 10]

Defining the Leading Hierarchy [page 51]

Defining Fields to Be Copied [page 67]

Setting up the Automatic Update Of “To Be Hired” Field [page 68]

Optimistic Locking [page 76]

Position Organization Chart [page 77]

2.1 Important Initial Settings for Position Management

Make some important initial settings for Position Management.

1. Enable Position Management.

Implementing Position Management

As a result, you will be able to make permission settings for positions.

Permissions Required for Position Management in General [page 20]

Implementing Position Management

2.2.1 Configuration Settings for the User Interface

An overview of settings for the user interface in Position Management.

Table 1: Interface: Manage Data

Configuration Setting Availability on the User Interface

Synchronization from Position to Job Information (pos2jo­ No

Position Reclassification N/A

Position Transfer N/A

Setting "to be hired" flag after Position Assignment/Unas­ N/A

Setting "to be hired" flag after FTE change of incumbent N/A

Table 2: Interface: Manage Positions

Configuration Setting Availability on the User Interface

Synchronization from Position to Job Information (pos2jo­ Yes

Implementing Position Management

Position Reclassification N/A

Position Transfer N/A

Synchronization from Position to Job Information (pos2jo No

Setting "to be hired" flag after Position Assignment/Unas N/A

Synchronization from Position to Job Information (pos2jo Yes

Setting "to be hired" flag after Position Assignment/Unas N/A

Setting "to be hired" flag after Position Assignment/Unas N/A

Synchronization from Position matrix relation to Job rela No

Setting "to be hired" flag after Position Assignment/Unas No

Synchronization from Position matrix relationship to Job re N/A.

Synchronization from Position to Job Information (pos2jo N/A

If the leave of absence (LOA) or global assignment (GA) is al

Setting "to be hired" flag after Position Assignment/Unas N/A