SF EC Position Management en
SF EC Position Management en
1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 What's New in Position Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 What is Position Management?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Data Protection and Privacy Content is Centralized. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Basic Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Important Initial Settings for Position Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Permissions and Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
General Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Position-Related Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Approval Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Defining The Position Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Field Labels and Visibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Propagation Of Job-Related Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Default Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Automatic Generation of Position Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Searchable Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Creating New Positions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Sychronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Define Synchronization of Common Position and jobInfo Fields for Position Reclassification
and Position Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Defining a Leading Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Synchronization Between Position and Incumbent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.5 Define Fields to Be Copied. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.6 Automatic Update Of “To Be Hired” Field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.7 Standard Hours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Determining Standard Weekly Hours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.8 Optimistic Locking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.9 Position Organization Chart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Setting Up The Position Organization Chart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Deep Link Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3 Enhanced Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.1 Position Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Workflow for Position To Job Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
To whom shall the direct reports report if the manager leaves the position?. . . . . . . . . . . . . . . . . 65
Adapt Reporting Line If Position Hierarchy Is Changed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5 Appendixes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.1 Fields in Position Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.2 Functions for Position Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.3 Changing Integration with Recruiting from SF API Basis to New Basis. . . . . . . . . . . . . . . . . . . . . . .138
5.4 New Data Model for Right to Return and Data Protection and Privacy. . . . . . . . . . . . . . . . . . . . . . . 139
This document describes changes to this guide for the recent releases.
Q3 2019
We've added some information on what the onSave rule Define Synchronization Position to JobInfo [page 34]
does not do in synchronization.
We've added some detail to the documentation on what hap Employee Termination [page 109]
pens to direct reports when a manager is terminated.
We've added some configuration information and a recom Execute Position Processes During Job Information Import
mended procedure for the position processes during the job [page 89]
information import.
We've added some information about a limit that applies to Position Types [page 64]
synchronization of matrix relationships using Manage Pend
ing Hire.
We've revised and corrected the documentation about how Forward Propagation [page 80]
forward propagation is used in Position Management.
We've added some information concerning restrictions on Functions for Position Management [page 130]
what the Jobinfo History UI can do.
We've made some changes in the position organization Position Organization Chart [page 56]
chart:
We've added a note to the documentation on mass changes Mass Changes to Positions [page 72]
to positions, warning that the log file is purged after six
months.
We've updated the information on functions in Position Man Functions for Position Management [page 130]
agement to reflect the changes in termination and synchro
nization.
We've made some changes to how Position Management Employee Termination [page 109]
handles employee termination.
There's some important information you need to know about Execute Position Processes During Job Information Import
data purges after job information imports. We've added a [page 89]
note about this to the import documentation.
We've made changes to synchronization from Position to Jo Define Synchronization Position to JobInfo [page 34]
bInfo..
Q1 2019
We've added some information on the effect of the Create Special Handling of the Create Permission [page 11]
permission.
We've clarified what you can and can't do when specifying a Automated Daily Hierarchy Adaptation [page 105]
date for the hierarchy adaptation job run.
We've entered some additional information on what trans Employee Termination [page 109]
fers cover in the case of employee termination.
Q4 2018
There are now two versions of the Is Position Below User's Rule Functions in Position Management [page 98]
Position in Hierarchy rule function.
We've added some information on what the automated daily Automated Daily Hierarchy Adaptation [page 105]
adaptation job is intended for.
Employee Central Position Management makes it easy for you to do a number of things.
You can:
Go to the central data protection and privacy guide for suite-wide information about our data protection and
privacy features.
Data protection and privacy is best when it’s implemented suite-wide, and not product-by-product, so we've
centralized our data protection and privacy information. Refer to the latest centralized content for information
about setting up and using data protection and privacy features.
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.
Remember
As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact your
Implementation Partner. If you are no longer working with an Implementation Partner, contact SAP Cloud
Support.
Procedure
<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>
Note
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.
There are some general permissions you need to set for Position Management.
Procedure
For users to be able to use Position Management, you must assign the Manage Position permission to that
user's role. On the Permission Settings popup window, click Manage Position and assign the permissions as
required
a. To grant users access to the position organization chart, select Access Position Organization Chart.
b. Optional: If you want to grant users permission to display the position organization chart for a specific
date, select Change Display Date of Position Organization Chart.
c. To grant users permission to create up to 100 new positions by copying an existing position, select the
Mass Copy of Position in Position Organization Chart
d. To grant users permission to create and/or view position requisitions from the position organization
chart, select either Create Requisition in Position Organization Chart or View Requisition in Position
Organization Chart or both.
Related Information
Context
You can define the Position generic object as subject to permission checks:
Procedure
○ Use point 3 to grant users access either to every position in the business or to a specific target
group of positions.
○ You can also restrict access to positions lower in the hierarchy than the granted user's position.
○ If you are using Matrix Relationships on the Position object, you can also restrict access to
positions based on the Matrix Relationships.
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 Definition .
With this setting, it is possible the 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.
Note
The Create permission is only validated when the position is saved. If you have restricted permissions on
creating positions, they will only be validated when you save the position or submit the workflow. If you
don't have permission to create the position, the system will not allow you to save or submit.
You can use workflows to protect the Position object against changes.
Context
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.
You can define your own field labels if you do not want to use the default labels, and define the visibility of all the
fields you require.
Procedure
How you need to set the Incumbent field depends on whether you also use Succession Planning.
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.
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.
Related Information
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
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
You can define default values for fields in the position that are filled automatically each time a new position is
created.
Procedure
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.
Context
There is some setup for you to do before you can use these functions.
Procedure
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 in Position Management Settings.
Context
You might conduct such searches in, for example, the position organization chart or in the Position field on the
Job Information screen.
The more searchable fields there are, the longer the search will take. As such, we recommend that you only
make important fields searchable.
Procedure
You can create new positions from the Admin Center or the position organization chart.
Context
Restriction
The first position in the system can be created from the Admin Center, 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 from the Admin Center, choose Manage Positions.
2.4 Sychronization
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, you need to define
synchronization rules.
Procedure
○ 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 lean more about this, see Position Reclassification and Position
Transfer.
Related Information
Context
The leading hierarchy reduces the effort involved in keeping the position hierarchy and reporting line hierarchy
in sync. Changes made to the leading hierarchy are automatically made to the other hierarchy.
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.
Procedure
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 hieararchies for you, see the
Automated Daily Hierarchy Adaptation [page 105] documentation.
Note
When transferring multiple employees of child positions to a new supervisor, 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. For performance
reasons, we recommend that you set the threshold to 100.
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 .
If you And you do the following... This happens... Note the following...
choose
this lead
ing hierar
chy ...
Position Change the higher-level posi The supervisor of all employees assigned to the -
hierarchy tion in the position organiza changed position is changed. This means that
tion chart, in the MDF UI (go the system determines the next available super
to the Admin Center and visor from the changed position hierarchy and
choose Manage Positions), or the incumbents of the changed position will re
when importing positions. port to this supervisor. If there isn’t a supervi
sor, the incumbents will no longer report to any
supervisor.
Position Change the supervisor in the The position hierarchy is not changed – this -
hierarchy employee’s job information means that the position hierarchy is now differ
(by selecting Change Job and ent from the reporting line hierarchy.
Compensation Info on the
Update Employee Records
screen) but this change
doesn’t lead to a new posi
tion
line hierar
● The higher-level position of the changed
chy
employee’s position is changed. The new
higher-level position will be the new super
visor’s position.
If the new supervisor doesn’t have a posi
tion, the employee’s position won’t have
any higher-level position (anymore). If the
supervisor is changed to No Manager, the
employee’s position won’t have any higher-
level position (anymore) either.
● If the employee’s position is not a shared
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 supervi
sor’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.
Position Change the position in the Effects on the user interface: When the admin *1 Direct reports of the
hierarchy employee’s job information selects a position, the Supervisor field is filled changed employee means
(by selecting Change Job and automatically with the next available supervisor those incumbents in posi
Compensation Info on the in the position hierarchy. tions below the changed em
Update Employee Records ployee’s position who ac
The direct reports *1 of the changed employee
screen). tually report to this changed
will report to the employee's previous supervi
employee (this means, the
sor *2 irrespective of whether the previous posi
changed employee is main
tion was a shared position or not. If there isn’t
tained in the Supervisor field
any supervisor in the position hierarchy, the in
of the their job information
cumbents won’t report to any supervisor (any
records).
more).
*2 The employee’s previous
All incumbents of the lower-level positions of
supervisor is not necessarily
the changed employee's newly assigned posi
the actual supervisor who is
tion will report to the changed employee - pro
maintained in the Supervisor
vided that this position doesn’t have any incum
field of the employee’s job in
bents yet. *3 If the position already has other in
formation record. It’s the pre
cumbents, only those incumbents of lower-level
vious supervisor according to
positions who don't report to any of these in
the position hierarchy, but
cumbents will report to the changed employee.
ideally the position hierarchy
and the reporting line hierar
chy are in sync. If the hierar
chies aren’t in sync (that is,
the supervisor maintained in
the Supervisor field is not the
incumbent of the higher-level
position of the employee’s
previous position), the sys
tem determines the supervi
sor based on the position hi
erarchy.
● To no manager
● To another incumbent
on the position (if the
position has other in
cumbents)
Position Hire a new employee and as Effects on the user interface: -
line hierar
● When the administrator selects a supervi
chy
sor, the Incumbent of Parent Position field is
filled 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 assignment changed The system always searches for a position be *5 Direct reports of the
hierarchy in position reclassification low the current higher-level position. changed employee means
because the previous posi those incumbents in posi
The direct reports of the changed employee *5
tion was a shared position. tions below the changed em
will report to the employee's previous supervi
An existing position was ployee’s position who ac
sor. *6 If there isn’t any supervisor in the posi
found. tually report to this changed
tion hierarchy, the incumbents won’t report to
employee (this means, the
any supervisor (anymore).
changed employee is main
All incumbents of the lower-level positions of tained in the Supervisor field
the changed employee’s newly assigned posi of the their job information
tion will report to the changed employee - pro records).
vided that the position that was found doesn’t
*6 The employee’s previous
have any incumbents yet.
supervisor is not necessarily
*7 If the position already has other incumbents, the actual supervisor who is
only those incumbents of lower-level positions maintained in the Supervisor
who don't report to any of these incumbents will field of the employee’s job in
report to the changed employee. formation record. It’s the pre
vious supervisor according to
the position hierarchy, but
ideally the position hierarchy
and the reporting line hierar
chy are in sync. If the hierar
chies aren’t in sync (that is,
the supervisor maintained in
the Supervisor field is not the
incumbent of the higher-level
position of the employee’s
previous position), the sys
tem determines the supervi
sor based on the position hi
erarchy.
● To no manager
● To another incumbent
on the position (if the
position has other in
cumbents)
Reporting The system always searches for the positoin be *8 For each lower-level posi
line hierar low the current higher-level position. tion of the previous position,
chy the system checks if all in
The lower-level positions whose incumbents re
cumbents assigned to this
port to the changed employee will be transfer
lower-level position report to
red to the position that was found.*8
the changed employee. Only
in this case will the lower-
level position become the
lower-level position of the
changed employee’s newly
assigned position.
Position Position assignment changed The system always creates the position below *9 Direct reports of the
hierarchy in position reclassification the current higher-level position. changed employee means
because the previous posi those incumbents in posi
The direct reports of the changed employee *9
tion was a shared position. A tions below the changed em
will report to the employee's previous supervi
new position was created. ployee’s position who ac
sor. *10 If there isn’t any supervisor in the posi
tually report to this changed
tion hierarchy, the incumbents won’t report to
employee (this means, the
any supervisor (anymore). *11
changed employee is main
tained in the Supervisor field
of their job information re
cords).
● To no manager
● To another incumbent
on the position, provide
that the position has
other incumbents.
Reporting The system always creates the position below *12 For each lower-level posi
line hierar the current higher-level position. tion of the previous position,
chy the system checks if all in
The lower-level positions whose incumbents re
cumbents assigned to this
port to the changed employee will be transfer
lower-level position report to
red to the newly created position. *12
the changed employee. Only
in this case will the lower-
level position become the
lower-level position of the
changed employee’s newly
assigned position.
Position Position assignment changed The system always searches for a position be *13 Direct reports of the
hierarchy in position transfer. An exist low the supervisor's position. changed employee means
ing position was found. those incumbents in posi
The direct reports of the changed employee *13
tions below the changed em
will report to the employee's previous supervi
ployee’s position who ac
sor *14 irrespective of whether the previous po
tually report to this changed
sition was a shared position or not. If there isn’t
employee (this means, the
any supervisor in the position hierarchy, the in
changed employee is main
cumbents won’t report to any supervisor (any
tained in the Supervisor field
more). *15
of their job information re
All incumbents of the lower-level positions of cords).
the changed employee's newly assigned posi
*14 The employee’s previous
tion will report to the changed employee - pro
supervisor is not necessarily
vided that the position that was found doesn’t
the actual supervisor who is
have any incumbents yet.
maintained in the Supervisor
If the position already has other incumbents, field of the employee’s job in
only those incumbents of the lower-level posi formation record. It’s the pre
tions who don't report to any of those incum vious supervisor according to
bents will report to the changed employee. the position hierarchy, but
ideally the position hierarchy
and the reporting line hierar
chy are in sync. If the hierar
chies aren’t in sync (that is,
the supervisor maintained in
the Supervisor field is not the
incumbent of the higher-level
position of the employee’s
previous position), the sys
tem determines the supervi
sor based on the position hi
erarchy.
● To no manager
● To another incumbent
on the position, provide
that the position has
other incumbents.
Reporting The system always searches for a position be *16 For each lower-level posi
line hierar low the supervisor’s position. tion of the previous position,
chy the system checks if all in
If the employee’s previous position was not a
cumbents assigned to this
shared position, all lower-level positions will be
lower-level position report to
transferred to the position that was found.
the changed employee. Only
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 position that changed employee’s newly
was found. *16 assigned position.
Position Position assignment changed The system always creates the position below *17 Direct reports of the
hierarchy in position transfer. A new the supervisor's position. changed employee means
position was created. those incumbents in posi
Direct reports of the changed employee *17 will
tions below the changed em
report to the employee's previous supervisor
ployee’s position, who ac
*18 irrespective of whether the previous posi
tually report to this changed
tion was a shared position or not. If there isn’t
employee (this means, the
any supervisor in the position hierarchy, the in
changed employee is main
cumbents won’t report to any supervisor (any
tained in the Supervisor field
more). *19
of their job information re
cords).
● To no manager
● To another incumbent
on the position, provide
that the position has
other incumbents.
Reporting The system always creates the position below *20 For each lower-level po
line hierar the supervisor’s position. sition of the previous posi
chy 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
lower-level position report to
transferred to the newly created position.
the changed employee. Only
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.
None Change the position in the Neither the Supervisor field nor the Position -
None Change the supervisor in the Neither the Incumbent of Parent Position field -
employee's job information nor the Position field is filled automatically when
a supervisor is selected
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 Execute Position Processes During Job Information Import
[page 89] documentation for more information..
To specify which common fields between the Position object and the jobInfo employment object are
synchronized when changes are made in the Position object, you need to define a rule.
Context
This rule is triggered for backend synchronization whenever a position with incumbents is changed from the
position organization chart and 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 for the technicalParameters column for
those position records that are to trigger a synchronization to the jobInfo object.
● The synchronization is carried out on the effective start date of the corresponding position record.
● When defining the position generic object, the technicalParameters field should still have visibility “Not
visible”.
● For position imports, no workflow is triggered for JobInfo due to the synchronization of Position to
JobInfo.
● Synchronization only takes place if the position is changed in the position org chart using Manage Data
or is imported via csv. It does not take place from API.
● 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 Optimistic Locking [page 55]
Procedure
Note
○ The rule should only be triggered if a position is assigned to the job info (IF-Condition in the rule).
○ The supervisor is set automatically based on the leading hierarchy and is never set by the sync
rule. Take a look at the documentation for more on this. [page 20]
○ If you don't use Youcalc or business rules for event reason derivation, you need to enter the event
reason that should be used for updating the incumbents job info records after position change. You
do this in Position Management Settings, using the field Event Reason for Synchronization
Incumbents after Position Change.
○ If you want to make use of the company in the Position to Jobinfo synchronization rule, set Use
Company Filter for Positions in MSS Job Information and History to "No".
4. To tell the system which rule to 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.
Restriction
You can only make this selection if the rule for synchronizing position to job info does not include
ELSE or ELSEIF statements.
○ Automatic
If you choose this, synchronization takes place in the background.
If you want to use this rule also for UI propagation, add the rule as onChange rule to the hrisfield Position
in the Succession Data Model. The onChange rule looks like this:
This means that the common fields between jobInfo 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 on the Update Employee Records
screen.
○ The HR admin changes the position assignment of an employee through the history.
These values can be overwritten.
The onChange rules in Job Info are not triggered in Import or when synchronizing data from Position to
JobInfo.
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.
Related 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 type documentation for details.
You can 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.
● The manager changes the job info on the Update Employee Records screen. Note that the sync is not
carried out when changes are made from 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.
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:
This rule is triggered whenever the system is to treat an action performed on Update
Employee Records screen as a position reclassification or position transfer.
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
You should keep objects in the business rule in sync with the hierarchy structure of these pay scale objects:
Note
If you want, you can swap the order in which Pay Scale Area and Pay Scale Type appear in the
business rule.
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.
Related Information
Context
Note that this rule is not triggered when an employee’s history is changed.
1. Go to the Admin Center. In the Company Processes & Cycles portlet, select Company Settings
Configure Business Rules .
2. Select Create New Rule and the Synchronize Incumbent's Changes to Position scenario.
3. Set up the rule as you require.
Note
Note
The rule should only be triggered if a position is assigned to the job info.
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.
4. To tell the system which rule to trigger when common fields between jobInfo and Position must be
synchronized, go to the Admin Center. In the Company Processes & Cycles portlet, select Employee Files
Position Management Settings .
5. Assign the rule that you’ve just created to Rule for Synchronizing Position after Job Information Change.
Note
If youCalc hasn’t been enabled in Provisioning, 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.
Remember
As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact
your Implementation Partner. If you are no longer working with an Implementation Partner, contact
SAP Cloud Support.
Context
To use the implicit-position-action field, which controls which followup activities [page 43] are required if job
information is changed with this event reason, 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
As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact your
Implementation Partner. If you are no longer working with an Implementation Partner, contact SAP
Cloud 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>
Procedure
1. Download the Employee Central Master Picklists from the Employee Central product page on Help Portal
under Configuration.
For more information about picklists, see the chapter Importing Picklists in the EC Master Handbook.
Procedure
1. Go to Admin Center. In the Company Processes & Cycles portlet, select Employee Files 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. Click Insert New Record.
4. In the popup window, enter the date when you want the changes to take effect and click 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 you’ve defined (and which can be selected manually or are derived from
YouCalc), a position reclassification or position transfer takes place when a manager makes changes on
the Update Employee Records screen.
A manager makes changes on the Update Employee Records Position reclassification or position transfer
screen.
Job info changes are made (new job, new department, and Position reclassification
so on).
The system reacts differently depending on whether more than one employee may be assigned to the position
(shared position):
If only one employee may be assigned at a time If more than one employee may be assigned (shared posi
tion)
The system changes the assigned position based on the de The system does not change the position. By default, the
fined rule. system first searches for an existing position with status To
Be Hired below the higher-level position of the position to
which the employee is assigned. If it doesn’t find a position,
it creates a new position below this higher-level position and
assigns the employee to this new position. This does not af
fect direct reports and lower-level positions.
Note
If a position was selected manually while the jobInfo was changed, position reclassification doesn't take
place. Only the jobInfo is saved.
No matter if only one employee or more employees may be assigned to the position, the system reacts in the
same way.
By default, the system first searches for an existing 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.
Note
If another position was selected manually while the jobInfo was changed, position transfer doesn't take
place. Only the jobInfo is saved.
Procedure
a. Go to the Admin Center. In the Company Processes & Cycles portlet, select Employee Files
Position Management Settings and 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. In the Company Processes & Cycles portlet, select Employee Files
Position Management Settings and go to the Synchronization tab.
b. In the Search for Position in Position Transfer field, select No.
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
2.4.3.2.6.1 Scenarios
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
higher-level position and assigns the employee to this posi
tion.
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:
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:
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:
When you create a new position from the position organization chart, you can define which fields are copied
from the current position to the new position.
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 rule is saved.
Procedure
1. To define which fields are copied from the current position to the new 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.
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.
1. To define whether the To Be Hired status is updated, go to the Admin Center and choose Position
Management Settings.
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. Remember that 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.
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.
● Company
● Location
● Job Classification
● Position
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.
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.
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:
With the rules in place, you need to enter them in the Succession Data Model so that they can be triggered from
there.
Procedure
2. Then go to the hrisfields Position, JobCode (for the Job Classification), Location, and Company, and
maintain the propagation rule as onChange rule there, like this:
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.
Related Information
Context
The system calculates the value for this field by using a formula:
FTE = standard weekly hours in Job Info/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.
Procedure
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 will be applied, but the second user will receive an error message and will have to refresh the
screen and submit their changes again once the first user is finished.
This restriction is called optimistic locking, and ensures that no conflicting changes can be made at the same
time. During the mass import of positions, the whole batch will be rolled back if there's an optimistic lock
exception on any of the records.
For details of how to implement optimistic locking, read the Implementing Optimistic Locking section of the
Implementing the Metadata Framework (MDF) documentation.
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.
● 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 General Permissions [page 8].
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 in order 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 will be
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
thousand direct positions will be displayed. No matrix positions will be displayed at all.
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 59]), but here’s everything you can
potentially see and do:
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).
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.
Incumbent Details View all the people that are currently assigned to the posi
tion, and as of when. 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.
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.
Note
The options available under Show Menu depend on your permissions and the Position Management
settings at your company.
To see more detailed information about a position, click the quickcard icon beside 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:
Related Information
The position organization chart is 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 there.
The position organization chart is 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 there and job requisitions.
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, see the topics under Related Links at the end of this topic. In
addition, users need the Access Position Organization chart permission.
You can determine whether you want to enable date selection in the position organization chart. Take a look at
the General Permissions [page 8] chapter for details of what to do.
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/02015, the assigned company is shown with name “SAP SE”.
If you enable the V12 Position Organization Chart, you determine which fields should be displayed directly on
the position tile. To do this, go to the Admin Center and choose Company Settings Org Chart
Configuration , then open the Position Organization Chart tab.
There are checkboxes at the top for enabling the V12 Position Organization Chart and for determining whether
the incumbent photos appear in the chart.
● 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
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
There are two URL parameters you can use to see all the info for a particular position in the position
organization chart.
● 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.
You can use position types to modify standard system behavior for one or more positions.
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.
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.
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.
● 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.
● 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 is the same 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.
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.
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".
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.
If you assign 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. 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.
If you assign 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 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.
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.
● 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.
● 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.
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.
● Regular positions
This is a default position type. You can't add this yourself.
Regular positions would be occupied normally by one employee, or by up to two or three employees in
exceptional cases, such as job sharing or transition periods.
Note
If you assign Mass position or Shared position on the parent position level, the system will assign a
supervisor for all incumbents in the corresponding child positions.
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 108] documentation for details.
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. The permission only appears if you are using
the v12 Position Org Chart:
Once the permission is activated, the Copy Position option appears in the list you can use on tiles in the v12
Position Org 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 Org Chart [page 56] documentation for full information on
permissions for the v12 chart.
When you click 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 org chart, you can define that a configured workflow is triggered. To
this end, there is a field on the UI Customizung tab in Position Management Settings called Respect workflow at
copy position in position org 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 org
chart.
If you set this to No, copied positions are created without any workflow being triggered.
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 Mass Change Run object is RBP-secured by default. This means that only permitted users can make
such changes.
Prerequisites
● As stated above, the Mass Change Run object is RBP-secured by default. You can grant access to it by
going to the Admin Center and choosing Set User Permissions Manage Permission Roles from the
Manage Employees portlet.
You can find the permission under Miscellaneous Permissions.
● You allow 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 cannot 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.
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:
● 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 will 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 rule scenario Update Rule for Mass Change Run can be selected. Only SET
statements are supported in the THEN condition.
● Execution Mode
You can select Run or Simulate. When you choose Simulate, the mass changes are not saved, but you
can see the result in the log. When you choose Run, the mass changes are executed and saved, and you
can see the result in the log.
● 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.
Note
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 will process 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 the Execution Status or the job directly by going to the Admin Center and choosing
Monitor Job.
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.
The result is that the mass change run is much quicker than before, and you're significantly less like 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:
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.
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 will return 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 will update this existing matrix relationship and set the related positions to
Expert Developer.
The SET statement on a composite object will create a new record if no record specified by the Select-
Statement in the SET-Condition was found. So, it is important to restrict this in the IF condition as shown in
the screenshot above.
Related Information
A shared position is a position 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 (shared
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”.
Procedure
If you want to set positions by default as shared positions, you can use onInit rule on the position object,
which sets the multipleIncumbentsAllowed field to True.
If a position is subject to position control, the FTE values of all incumbents assigned to the position may not be
higher than the FTE value assigned to the position.
Context
The positionControlled field has been added to the Position generic object. If you want to use the field, proceed
as follows:
Procedure
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.
The term "right to return" describes a situation where an employee on global assignment or leave of absence
can return to their original position.
It might happen that an employee in your business has to leave his or her 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 if the employee should be unassigned from their current position and, if yes,
if they have a right to return to the position once their global assignment or leave of absence is over.
Note
To make use of this feature, you need to have installed some other EC features:
● Global Assignments
Install this if you want to handle the right to return in connection with global assignments.
● 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.
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 is no automatic
check to ensure the position won't be overstaffed by people or FTE. As such, you should check this
manually.
Before you can use the right to return, you need to make some settings in Position Management.
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.
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. The right to return is then automatically created and filled
with the relevant information, as shown for Oden Wa in this example. This rule is only used if the
employee is unassigned from the position based on the first rule.
○ 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 (LoA) or global
assignment (GA), and the start/end date of the LoA or GA is changed afterwards, 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. Go to the rule maintenance screen. You can do this either by going to the Admin Center and choosing
Configure Business Rules, or by clicking the "+" icon next to the Right to Return rule in the Position
Management settings.
b. On the selection screen, enter a rule name, rule ID, start date and, if you want, a description.
c. The rule shown is used to decide whether an employee is unassigned from a position because of a
global assignment. In this configuration, all employees who work for the company SAP and go on
global assignment are unassigned from the positions they are leaving.
4. Now go to Position Management Settings and make the appropriate entries under Right To Return. For
each scenario, 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. It will be created automatically if needed in the
leave of absence process or global assignment process.
You can synchronize position matrix relationships with the employee's job relations when you assign an
employee to a position.
You do this by selecting Change Job and Compensation Info on the Update Employee Records screen or when
you hire an employee. When you do this:
● The system updates existing job relations if the employee's newly assigned position has a position matrix
relationship of the same relation type and the related position has at least one incumbent. This means that
the incumbent of the related position will become the manager for the job relation.
● The system makes no changes to existing job relations if the newly assigned position either has no position
matrix relationship of the same relation type or there is no incumbent for that related position.
● Where related positions have at least one incumbent, job relations 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.
Remember
You need to set the association positionMatrixRelationship 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 EC picklist
for job relationship types.
Job Relations are synced when the position matrix relationships of a position are changed, or if an employee is
assigned to a position that has position matrix relationships and/or is referenced by position matrix
relationships of other positions.
By default the sync is always executed. You can switch it off globally in position management settings or for
specific positions by using position types. Take a look at the Synchronize position matrix relationships to job
relationships of incumbents? section of the Position Types [page 64] documentation for details.
● Scenario: The position assignment is changed using the MSS UI or a position assignment is added using
the MSS UI or New Hire UI.
○ Outcome: Position matrix relationships of the employee's newly assigned position are synchronized
with the Job Relations of the employee. Existing Job Relations are preserved if the Job Relation has no
corresponding position matrix relationship on the position side or if the related position of the
corresponding position matrix relationship doesn't have any incumbents.
● Scenario: The position assignment is removed from the employee (without assigning the employee to a
new position) via MSS UI.
○ Outcome: No changes occur to the employee's Job Relations.
Note
The Synchronization tab in Position Management Settings contains Matrix Relationship Synchronization
field. 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.
You should particularly note that, if position types are activated, the settings there override the settings
from the Matrix Relationship Synchronization field.
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.
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 (see the Position-Related Permissions
[page 9] chapter).
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.
Let’s assume the position hierarchy shown below is maintained in the system.
If you set up the position target criteria as shown in the screenshot above (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 those found child positions.
In the example above, the user E1 would only have access 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 criteria the restrictions are concatenated with
an AND.
For example, in the setting below, the user will see the positions based on the matrix type and job title =
Developer.
If you are modifying job information records using file import or API, you might need to trigger positionspecific
processes for the modified records.
By default the process to adapt the non-leading hierarchy and reclassify/transfer is not executed, but the to-
be-hired status change on the position is executed by default (if the automatic change is configured). All the
processes are executed asynchronously after the job information records have been successfully imported, so
there might be a short delay until the processes have finished.
The employees configured to receive the email notification about the job information import will also receive an
email about the positionspecific follow-up processes and their status. If the position processes are processed
successfully, the system sends a success email notification.
Caution
The position processes executed during job info import are time consuming and are, therefore, executed
asynchronously. We do not recommend that you to use these processes for initial data setup because the
volume of data to be processed is so great that it could lead to a time out. If you want to do a mass import
of job info, you should switch off this process. To do this, go to the Admin Center and choose Position
Management Settings. Then open the Import tab and set the following to No:
Tip
If you want to import a high amount of user data in an initial set-up in an as short a time as possible, we
recommend that you verify the following in the import files:
Once all this is done, you should first upload the positions, then perform the jobinfo import.
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 Hierarchy Adaptation During Job Import, set Adapt The Non-
Leading Hierarchy to Yes.
If the position hierarchy is leading, the reporting line is automatically adapted during the job info import:
● If the employee's position assignment is changed, the supervisor is automatically derived based on the
position hierarchy. If the employee's position assignment is removed, the supervisor assignment is
removed too. Note that the employee’s supervisor assignment is also removed if the system can't find a
suitable supervisor.
● 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 supervisor, or to the other position incumbent (if there is one), or to no
supervisor - 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 during the job info import:
● If the employee’s supervisor assignment is changed, the position is derived automatically, based on the
reporting line. If the employee’s supervisor 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 will be triggered in a similar way as is the case when the
supervisor assignment of an employee is changed via the MSS UI: The child positions of the employee's
previously assigned position are transferred to his or her 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.
● The imported job information records, whose supervisor/position will be automatically adapted, are
changed as a correction with the defaulted supervisor/position.
● For direct reports, which will be transferred to a new supervisor, a new job information record will be
inserted with the new supervisor.
● For child positions, which will be transferred to a new parent position, a new position record will be
inserted with the new parent position.
● If the system will default the supervisor/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.
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 the Automatic Update Of "To Be Hired" Field [page 49] documentation 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 During Job History Import to No.
You can opt to have positions reclassified and transferred based on the selected event reason during 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 During Job Information Import to Yes.
No reclassification is executed if the imported job info records have already been changed because of a
hierarchy adaptation.
Error Handling
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, select object type
Import Queue Monitor and select the code you received by email.
The object itself has information about the status and the email address to which the error was sent stored at
root level.
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:
You can review the error message items one by one and check whether if you can correct the error manually. If
so, you can manually initiate the re-processing 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 mail will be
sent. If there are still errors, the monitor is updated with the new error information and another error mail is
sent.
Note
By default, the system sends a result mail for the follow-up processing in cases of both success and error. If
you want to receive the result mail only if there is an error, you can enable this by going to the Admin Center
and choosing Company System and Logo Settings Send result mail for Job Information import follow-up
processing only if an error occurred .
Note
After a job information import is completed, an ImportQueueMonitor object is created that contains the
failed records with detailed error messages. By checking these details and setting the Action field to Import
Resend, you can trigger the process again once the issues are resolved. 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.
There are three configuration options for the event reason to be used for the adaptation of the supervisor when
job history records are being imported.
The event reason can either be a fixed one, or it can be derived using event reason derivation, or it can be the
one from the original import record. There's some setup work to do before all these options are available.
1. If you want to have the event reason derivation option to be available, you need to switch on Enable youCalc
rules engine for HRIS for your company in Provisioning.
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
As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact
your Implementation Partner. If you are no longer working with an Implementation Partner, contact
SAP Cloud Support.
2. Now go to Position Management Settings by going to the Admin Center and choosing Position
Management Settings.
On the Import tab, you find the Hierarchy Adaptation During Job Information Import section. You can define
whether the non-leading hierarchy is adapted during the job information import. You can select an event
reason for the supervisor change and you can define whether the derived event reason is ignored.
Note
The Ignore Event Reason Derivation option does not appear if you don't activate event derivation as
described above.
Prerequisites
● The Option to Move Position to New Supervisor on Job Info Change permission must be set in Permission
Settings.
● Users making this change in the Job Info must have the View Current permission for the Position object.
Otherwise, the Move Position button does not appear in the Job Info.
Effect
● If an employee gets a new supervisor, users with the relevant permission will be asked to decide whether
the employee's position should also be moved to the new supervisor.
○ If the user decides yes, the position is transferred along with the employee. All lower-level positions of
the position will to be moved as well, including their incumbents. If the position to be moved is a mass
position or shared position, all incumbents will be moved at the same time.
○ If the user decides no, then the employee is moved but the position is not.
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 info.
Prerequisites
● Pay Range is a transient, invisible field on the Position. "transient" means that the content of the field is not
saved to the database, but is calculated onthefly.
Here's how you can change the visibility:
1. Go to the Admin Center and choose Company Settings Configure Object Definitions .
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.
You can use a rule to define how the pay range is calculated. There is a rule function called Get Pay Range By
Position(). Take a look at the rule function documentation [page 98] for details.
You can also set attributes of the pay range to custom transient field. Before you enhance the rule, add the
custom field to the object definition of the Position.
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 to bring this about:
When you want to trigger the calculation of the pay range during edit of the Position, 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.
You can define a rule that derives the pay range attributes for a specific date, such as today. There is a new 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 98] documentation for details.
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.
● The pay range is only calculated in Manage Data, Manage Positions, or the Position Quickcard in the
Position Org 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 of the Position
Organization Chart.
● The pay range field is not filled when Positions are exported.
● You can't use the pay range to derive dynamic groups.
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.
This rule function returns the code of the matrix position that is assigned by the specified type.
Use this rule function to determine the available manager closest in the hierarchy to the current position.
Use this rule function to determine how many positions are child positions to the current position.
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 org chart.
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 org chart.
Pay Range
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.
Take a look at the EC handbook for details of how the determination works.
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.
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.
● 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 line 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.
Use the check tool to find potential problems and errors in your configuration before you call support about an
issue.
Prerequisites
Assign Access Check Tool and Allow Configuration Export to your role in Role-Based Permissions (RBP).
Procedure
1. Go to Admin Center.
2. In the tools search field, type Check Tool.
3. In Application, select the application you want to check.
Tip
For example, to run checks for Time Off, select Time Off.
You see the checks for the application you selected. The description for each check describes the situation
you hope to find in running the check. For example, in running the check Accrual lookup by seniority is
consistent, you hope to find that the lookup is indeed consistent.
4. Click the check the box at top left in the table to run all checks.
5. If you want to run only some checks, select them individually.
Tip
To understand what a check does, right click the Check ID. The system then displays some information
on the check.
6. Click Run Checks to check your applications for the checks you selected.
Evaluate the results and resolve the issues. If you encounter an error you cannot resolve, contact Support by
creating a ticket.
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 support. The support engineer, therefore, can
identify the issue more quickly.
● A list of issues in your configuration or data and the severity of each issue.
● A solution or recommendation to address the issue.
After you run checks in the check tool, it returns the results of the check so that you can resolve issues that it
found.
To see the results of the checks, look in the Results column. If you run the checks multiple times to see how you
are resolving issues, look in the Previous Result column to compare the current results to previous results.
Result Action
No issues found If the tool cannot find issues, you see a green check mark the Result.
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.
Related Information
When the check tool reports a serious issue, you might need to contact Support. You can create a Support
ticket from within the check tool.
Prerequisites
Run the check tool. You can find the check tool by going to Admin Center Check Tool . You create the
ticket from the results page of the tool.
Procedure
1. On the results page, look in the Result column for the errors you want to report on.
You usually contact Support for high severity issues not low severity issues.
2. Click the error in the result to open the Detailed Result.
Note
If you cannot click the error, expand the list of checks from the Description column, and then click the
error from the Result column.
The Check Tool includes a Quick Fix feature that you can use to immediately correct issues found during a
check run.
Procedure
1. Run checks as described in Using the Check Tool for one or more components. The tool generates check
results, some of which might be warnings or errors.
2. Select the result of one of the checks where issues were identified. If the check includes a quick fix, you see
the four-step process at the top of the resulting window. You are in step 1, called Found Issues.
3. Choose Step 2 to proceed to Select Correction.
4. The resulting window shows one or more corrections for the issue. Select the one you want and choose
Step 3 to proceed to Final Approval.
5. In the Final Approval step, you can opt to change your mind and not carry out the fix. If you want to
proceed, choose Step 4.
6. The system confirms that the fix is now running. Choose Close to complete the procedure. You can verify
that the fix has run correctly after a short time by running the check again.
There are some situations in which the hierarchies are not in sync.
Context
For example, if you assign employee E0 to position A today and position A has position B with incumbent E1 as
higher-level position, the system derives E1 as the new supervisor for employee E0. If position A already has a
new higher-level 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 will set the correct supervisor based on the position
hierarchy.
1. Go To Provisioning and schedule the “BizX Daily Rules Processing Batch” job with daily recurrence. Note
also the Modified date since options in the Job Parameters section. If you select the Specify a date: option,
the system uses today's date as the start date from which defective records are corrected for hierarchy
adaptation purposes, even if you enter a different date in the option.
Remember
As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact your
Implementation Partner. If you are no longer working with an Implementation Partner, contact SAP
Cloud Support.
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 this field will only be editable if
you have scheduled the job as mentioned in step 1. Once you have set the flag to Yes and have saved, the
hierarchies are checked for each job run date and are adapted if not in sync.
Note
The report is designed to adapt the hierarchy on a daily basis, notto 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 one week before it gets out of sync, set the value to 7.
4. You can download the result of the “BizX Daily Rules Processing Batch” job from the Admin Center by
choosing Monitor Job.
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 “BizX Daily Rules
Processing Batch” job, this is shown with an icon next to the effective date in the employee’s job
information history page.
The visualization shown in the example is only available in the PP3 version of the employee's job
information history.
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.
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:
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 just as described above. Settings entered in this
way always override any settings entered in Position Management Settings.
Take a look at the Position Types [page 64] documentation for full information on how to use them.
In the org chart, click the name of the employee and choose Take Action Terminate . On this screen, 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
If the position hierarchy is the leading hierarchy, you can opt-in to transfer directs according to position
hierarchy. This can either be set 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:
Despite appearances, the settings do not do the same. Everyone to upper manager is purely a user-based
decision, independent of the position hierarchy, whereas Everyone according to position hierarchy selects the
incumbent of the next available position based on the position hierarchy.
Note
● 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 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
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
Management Settings.
Employee Central Position Management can be used together with Recruitment Management and Succession
Management.
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 138] documentation.
Here's an illustration of how all this works when integration has been set up.
To use integration between EC Position Management and RCM, you need to have a system where both these
modules are enabled and configured. We will now look at what you need to do to set up the integration.
Procedure
1. You need to 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.
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. 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
○ positionNumber
You don't need to map these fields using a rule because the system fills them automatically.
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".
To map fields of type Foundation Object or Generic Object, you do as shown here:
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:
To map fields of type PicklistOption, the Field Value must be the optionID of the picklist, you do this as
shown here:
For more information, see Mapping Job Requisition Picklist Values in OData Integration [page 122].
5. With your rules now created, you need to register them. To do this, go to Admin Center Position
Management Settings , then go to the Integration tab and enter the settings as shown below.
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 RBP “Create Requisition in
Position Organization Chart” and/or "View Requisition on Position Organization Chart". To do this, go to the
Remember
As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact your
Implementation Partner. If you are no longer working with an Implementation Partner, contact SAP
Cloud 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.
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 RBP and the corresponding position does
not 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, and you can create a job requisition from the
Position Organization Chart.
Note
When you create a requisition through the Position Organization Chart, the default recruiting team is not
added.
If you have the Select Job Requisition Template in Position Organization Chart RBP, 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
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, then the default language of the requisition will be
originator’s. If the switch is disabled, it will be the default language of the Job Requisition Template.
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.
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.
● 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.
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.
3. In Rule for Mapping Fields Between Position and Job Requisition, make this entry.
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, take a
look at the Succession: Implementation and Administration guide.
Changing Integration with Recruiting from SF API Basis to New Basis [page 138]
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.
New Data Model for Right to Return and Data Protection and Privacy [page 139]
It is always important to be compliant with your local data protection and privacy laws, so we strongly
recommend that you migrate to the new data model.
A table listing the most important fields in the Position object and explaining their purpose.
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 16] 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.
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 64] docu
mentation for more information on this feature.
multipleIncumbentsAllowed This attribute controls whether the system allows the as
signment of more than one employee to this position at any
point in time. In EC Position Management, we recommend
that you set this attribute to True.
Note
Under certain conditions, it is possible to replicate
shared positions - meaning positions with multiple in
cumbents - from Employee Central (EC) to ERP. Take a
look at the Replicating Organizational Data from Em
ployee Central to SAP ERP (Integration Guide) for infor
mation 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.
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 14] doc
umentation for more information on this feature.
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
and position and can be included in the synchronization be
tween position and employee.
employeeClass This is the standard field for the employee class on job infor
mation and position and can be included in the synchroniza
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
and position and can be included in the synchronization be
tween position and employee.
businessUnit This is the standard field for the business unit on job infor
mation and position and can be included in the synchroniza
tion between position and employee.
division This is the standard field for the division on job information
and position and can be included in the synchronization be
tween position and employee.
department This is the standard field for the department on job informa
tion and position and can be included in the synchronization
between position and employee.
location This is the standard field for the location on job information
and position and can be included in the synchronization be
tween position and employee.
costCenter This is the standard field for the cost center on job informa
tion and position and can be included in the synchronization
between position and employee.
createdBy This field holds the user who created the position.
createdDate This field holds the date when this position was created.
lastModifiedBy This field holds the user who last modified the position.
lastModifiedDate This field holds the date when this position was last modi
fied.
payRange This is a transient field, showing the pay range for a position.
Take a look at the Showing Pay Range on Position [page 94]
documentation for more information on this feature
User Interface
Function Available?
Applying the leading Hierarchy (hierarchy adaptation) Yes. Configurable. Default: Yes; overruling via Position Type
possible.
Synchronization from Position matrix relation to Job rela Yes. Configurable. Default: No.
tionship
Setting "to be hired" flag after target FTE change of Position Yes. Configurable. Default: No
Function Available?
Applying the leading Hierarchy (hierarchy adaptation) Yes. Configurable. Default: Yes; overruling via Position Type
possible.
Synchronization from Position matrix relation to Job rela Yes. Configurable. Default: No.
tionship
Setting "to be hired" flag after target FTE change of Position Yes. Configurable. Default: No
Function Available?
Applying the leading Hierarchy (hierarchy adaptation) Yes. Configurable. Default: Yes; overruling via Position Type
possible.
Synchronization from Position to Job Information (pos2jo Yes Configurable: always, never, popup.
bInfo)
Synchronization from Position matrix relation to Job rela Yes. Configurable. Default: No.
tionship
Setting "to be hired" flag after target FTE change of Position Yes. Configurable. Default: No
Function Available?
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 via
bInfo) 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 with b1511. Configurable. Default:No
Setting "to be hired" flag after target FTE change of Position N/A
Function Available?
Synchronization from Position to Job Information (pos2jo Job info fields are propagated on change of the position via
bInfo) rule.
Position Reclassification No
Position Transfer No
Setting "to be hired" flag after target FTE change of Position N/A
Note
The Jobinfo History UI is a kind of correction and expert admin tool. This means that the position validation
feature doesn't work when you make changes using the Job Info History UI. The "Current FTE vs. Target
FTE" check and the "Multiple Incumbents Allowed" checks are only performed when you insert a job info
record using MSS or the New Hire UI.
Function Available?
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 to Job Information (pos2jo Job info fields are propagated on change of the position via
bInfo) rule.
Synchronization from Position matrix relationship to Job re According to Position Management Settings when assigning
employee to a new position.
lationship
Position Reclassification Yes (event reason with Follow-Up Activity in Position Position
Reclassification)
Setting "to be hired" flag after Position Assignment/Unas Yes. Configurable. Default: No.
signment
Setting "to be hired" flag after target FTE change of Position N/A
Function Available?
Applying the leading Hierarchy (hierarchy adaptation) Yes (direct report section always available)
Synchronization from Position to Job Information (pos2jo Job info fields are propagated on change of the position via
bInfo) rule.
Synchronization from Position matrix relationship to Job re Yes. Configurable. Default: No.
lationship
Position Reclassification Yes (event reason with Follow-Up Activity in Position Position
Reclassification)
Setting "to be hired" flag after Position Assignment/Unas Yes. Configurable. Default: No.
signment
Setting "to be hired" flag after target FTE change of Position N/A
Function Available?
Applying the leading Hierarchy (hierarchy adaptation) Only the position hierarchy can be applied.
Synchronization from Position to Job Information (pos2jo Job info fields are propagated on change of the position via
bInfo) rule.
lationship
Setting "to be hired" flag after Position Assignment/Unas Yes. Configurable. Default: No
signment
Setting "to be hired" flag after target FTE change of Position N/A
Function Available?
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 matrix relationship to Job re Matrix relationship changes are not synchronized to job rela
tionship when reassigning the user to the original position
lationship
Setting "to be hired" flag after Position Assignment/Unas Yes, if "to be hired" adaptation has been set up in the Posi
signment tion Management settings.
Setting "to be hired" flag after target FTE change of Position N/A
Setting "to be hired" flag after Delete or End Global Assign Yes, if "to be hired" adaptation has been set up in the Posi
ment tion Management settings.
Function Available?
Applying the leading Hierarchy (hierarchy adaptation) Yes. Configurable. Default: Yes.
Synchronization from Position to Job Information (pos2jo Import: Yes. Configurable. Default: No. technicalParameters
bInfo) = SYNC
Synchronization from Position matrix relationship to Job re Yes. Configurable. Default: No.
lationship
Setting "to be hired" flag after target FTE change of Position Yes. Configurable. Default: No
Function Available?
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.
Synchronization from Position matrix relationship to Job re Yes. Configurable. Default: No.
lationship
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
Function Available?
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.
Synchronization from Position matrix relationship to Job re Yes. Configurable. Default: No.
lationship
Setting "to be hired" flag after Position Assignment/Unas Yes. Configurable. Default: No.
signment
Setting "to be hired" flag after target FTE change of Position N/A
Function Available?
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.
Setting "to be hired" flag after Position Assignment/Unas Yes. Configurable. Default: No.
signment
Setting "to be hired" flag after target FTE change of Position N/A
Function Available?
Setting "to be hired" flag after Position Assignment/Unas Yes. Configurable. Default: No.
signment
Setting "to be hired" flag after target FTE change of Position N/A
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.
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 cannot enable this integration again once you have disabled it.
Note
Remember
As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact
your Implementation Partner. If you are no longer working with an Implementation Partner, contact
SAP Cloud Support.
2. Change the rule registered in the Rule for Deriving Job Requisition Template ID 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 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).
It is always important to be compliant with your local data protection and privacy laws, so we strongly
recommend that you migrate to the new data model.
From the Q1 2018 release, there is a new data model available for Right to Return. Migrating to this new data
model is optional, but please note that it is a prerequisite for using data protection and privacy functions in
Position Management.
To migrate, go to the Upgrade Center and from the Important Upgrades section, select Position Management -
Migrate Data Model for Right to Return.
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.
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.
Gender-Related Language
We try not to use genderspecific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.
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.