IDP - EC - Position Management - Design Considerations and Recommendations
IDP - EC - Position Management - Design Considerations and Recommendations
PUBLIC
SAP SuccessFactors Employee Central Position Management :
Design Considerations and Recommendations
Implementation Design Principle
Document Details
Name Objective Audience
SAP SuccessFactors SAP SuccessFactors Customers: IT
Employee Central This document addresses challenges faced during and HR professionals;
Position Management- the implementation of position management and
Design Consideration proposes recommended position management SAP SuccessFactors Implementation
and Recommendations settings, sample rules and configurations to aid in Partners: Consultants, solution
the design of the system as it relates to Position architects and project managers
Management.
Change Log
Version Date Description
1.0 November 2020 Initial version
Supported Releases
Product Release - From Release-Valid
till
SAP SuccessFactors Employee Central 2005
Contribution
Role Name Organization
Author / Owner/Reviewer SAP SuccessFactors Product Management SAP SE
Author Paul Nolan SAP
Author Nathan Wilkinson SAP
Reviewer Mary McHale-Roe SAP
Reviewer Benjamin Knowles SAP
The recommendations in this document are based on the functionality available up to SAP SuccessFactors release
mentioned above. Future functionality can impact the recommendations provided by this document. We strive to keep
these recommendations up-to-date, however, in case you find that recent new functionality has not yet been considered
in the latest version of this document, please reach out to your Customer Success Manager / Partner Delivery Manager or
send an email to [email protected].
Implementation Design Principles (IDPs) for SuccessFactors solutions are delivered by SAP for helping customers and
partners on how to choose the most appropriate strategy and solution architecture for SuccessFactors implementations.
IDPs are compiled taking into consideration the experience of many implementation projects and addressing frequent
business requirements as well as real-life implementation challenges. They are continuously reviewed and updated as
product functionality evolves. In addition, the reader is advised to read and familiarize with essential and additional product-
related documentation which includes Implementation Guides, SAP Notes, SAP Knowledge Base Articles, and additional
assets as referenced in this document, see chapter 7.
www.sap.com/contactsap
The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.
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. See www.sap.com/copyright for additional trademark information and notices.
TABLE OF CONTENTS
1 TERMINOLOGY .................................................................................................................................................... 4
2 ABSTRACT ........................................................................................................................................................... 4
3 INTRODUCTION................................................................................................................................................... 4
4 BUSINESS REQUIREMENT .................................................................................................................................... 4
4.1 FUNCTIONAL REQUIREMENTS ..................................................................................................................................... 5
5 DETAILED SOLUTION ........................................................................................................................................... 5
5.1 POSITION MANAGEMENT VALUE PROPOSITION .............................................................................................................. 5
5.2 IS YOUR ORGANIZATION READY FOR POSITION MANAGEMENT? ........................................................................................ 5
5.3 ELEMENTS AND SETTINGS .......................................................................................................................................... 7
5.4 POSITION MANAGEMENT CROSS-MODULE TOUCHPOINTS ............................................................................................. 29
5.4.1 Integration with Recruitment.................................................................................................................... 30
5.4.2 Integration with Job Profile Builder .......................................................................................................... 34
5.4.3 Integration with Succession Planning ....................................................................................................... 35
5.5 POSITION MANAGEMENT ROLE-BASED PERMISSIONS SETTINGS...................................................................................... 36
5.6 POSITIONS: PLANNING FOR THE YEAR AHEAD.............................................................................................................. 41
5.7 POSITIONS: BUSINESS AS USUAL ............................................................................................................................... 41
5.7.1 The Ad Hoc Need for A New Position ........................................................................................................ 41
5.7.2 Transfer – Internal Recruitment ................................................................................................................ 42
5.7.3 Transfer – Non-Internal Recruitment ........................................................................................................ 43
5.7.4 Changing Position Attributes .................................................................................................................... 43
6 ASSUMPTIONS AND EXCLUSIONS ......................................................................................................................43
6.1 RESTRICTING ADD LOWER POSITION/PEER POSITION.................................................................................................... 43
7 REFERENCES .......................................................................................................................................................44
3
1 TERMINOLOGY
Abbreviation Description
EC Employee Central
SAP Enterprise Resource Planning often referred in the document pertains to SAP
ERP
HCM on premise system
MDF Meta Data Framework
UI User Interface
NA Not Applicable
2 ABSTRACT
Position Management is an important aspect of SuccessFactors Employee Central Solution. Its primary
purpose is to facilitate workforce planning and subsequent control of workforce against that plan. It also has
the main benefit of facilitating greatly increased data entry by defaulting many fields into the employees’
records when they are attached to a position.
There are many permutations for configuring Position Management and it can be confusing to decide on the
appropriate configuration for an organization.
This document addresses challenges faced during the implementation of position management and proposes
recommended position management settings, sample rules and configurations to aid in the design of the
system as it relates to Position Management.
The document doesn’t cover data migration and reporting aspects of position management in detail.
3 INTRODUCTION
Position Management facilitates organization management and helps to streamline other integrated areas
like Job Information, Recruitment, Succession Planning etc. Hence it is necessary to ensure that the
configuration of Position Management is as per recommendation so that the solution works as designed.
In below sections, we clarify various aspects of Position Management and provide recommended solutions to
aid its implementation.
4 BUSINESS REQUIREMENT
Position Management is a leading practice. It is important to understand various aspects of configuring Position
Management and their impacts.
Guidance and clarifications may be needed during its configuration so that the benefit of its integration with
other areas like Recruitment/Job Information/Succession Planning etc. is available.
4
4.1 Functional Requirements
Every customer is unique and may have unique reasons to implement or not to implement position
management along with Employee Central Solution. A customer may have queries around following areas:
• Value proposition for implementing Position Management
• Organizational readiness to implement Position Management
• Benefits of integrating Position with Employee Central/Recruitment/Succession Planning etc.
5 DETAILED SOLUTION
Position is a placeholder for which Organizational, Job and Pay attributes can be maintained. It is
assigned to employees. Any employee hired or transferred into a position inherits the position attributes.
Positions can be linked together to create Position Organization Chart/Position Hierarchy. SAP
SuccessFactors recommends Position hierarchy to be set as leading hierarchy. Leading hierarchy
reduces the effort involved in keeping the position hierarchy and employee hierarchy in-sync. Changes
made to the position hierarchy are automatically made to the reporting hierarchy. Recommendations in
this document are based on the fact that the position hierarchy is the leading hierarchy.
With position management in place, every position in the organization is created based on business
planning/business requirement. Employees are assigned to available positions. Vacant positions exist
without employee assignment. This means recruiters will always know the current staffing levels, the
exact number of vacancies at any time so they can hire the right number of people. This in turn helps to
track hiring, job offers, budget utilization etc. which thus simplifies recruitment, streamlines the
succession planning process, and more.
With effective-dated positions, analysis of any gaps in the staffing levels becomes easier. This ensures
that the company is always adequately staffed at all times. Position management pushes you to evaluate
the value of each position in the company that represents a real business need. This way, a uniquely
identified position must be created instead of a general job code that can be assigned to multiple
employees. This also means that each position must be vetted and budgeted for before it can be created.
With position management, it becomes easier to manage a dynamic workforce. It can aid succession
planning by allowing you to build a position roadmap to fill key positions, as well as record the essential
skills needed to be successful on each position. This helps employers guide new employees into
developing the skills they need to excel in their role.
With position management, it also becomes much simpler to manage the movement of your employees
within the company. Regardless of whether employees have more than one position or not, position
management has a range of far-reaching benefits that are worth evaluating for a company’s success.
Listed below are a set of pointers to determine if your company is ready for position Management:
5
Consideration Without Position
With Position Management
Area Management
a) Suitable for organizations having
People Planning as part of long- a) Position is not used for people
term business goals. planning
People Planning vs b) Position Organization Chart is b) Suitable for organization
Replacement Planning the base for people planning and having Replacement
depicts true state of organization Planning approach
at any point in time
6
Consideration Without Position
With Position Management
Area Management
a) Recruitment Integration-
Vacant or understaffed
positions/new positions based
on business goals become
source for recruitment
An organization implementing complete integrated SuccessFactors suite draws full benefit of the
solution by implementing Position Management. However, in scenarios where customer has other
third-party solutions to address needs in areas like recruitment, succession planning etc. or is
implementing Employee Central Solution without Position Management, pointers provided in the
above table can be reviewed to arrive at a decision.
7
Other important fields in Position object are:
• Position Controlled – Position Control helps to control FTE capacity of position. 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. This feature is used for budget control. Leading practice
recommendation is to enable this field.
• Multiple Incumbent Allowed - This attribute controls whether the system allows the assignment of
more than one employee to this position at any point in time. Leading practice recommendation is
that the field should be enabled but set to “No”. This is because of following reasons:
1. If multiple incumbents are allowed on a position and this position is a managing position (parent
position) the supervisor of the employees assigned to lower level positions is derived by the
system. This could contradict to the business process.
2. If multiple incumbents are assigned to a position and a Job Information is changed for one of
the employees, this often leads to the creation of a new position for this incumbent without
running a workflow approval process for position creation.
3. Downstream systems may not be able to deal with multiple incumbent scenarios involving
position reclassification/position transfer and hence impact of setting this field value to “yes”
should be considered.
• Criticality and Change Reason- These fields are relevant for Succession Management only and should
only be set to visible if Succession Management is used as per leading practice.
Workflow - You can use workflows to validate Position object changes. Assign your rule to the event
onSave of the position object definition.
To trigger workflow for field level changes from Manage Position->Insert New Record, for a position,
create a business rule using:
Use “Original record” values to compare with new values to trigger the workflow.
A sample rule for supervisor change is shown below:
8
Job Relationships: Position can also be associated with other positions based on relationship like
Matrix Manager, HR Manager etc. Following matrix relationships are available for a position. Setting
these relationships will automatically update them for the incumbent of the position.
You can enhance this list with custom picklist values. Customized relationship types also sync back to
the incumbent of the position. This requires updating picklists for relationship type associated with both
Position Object as well as the one assigned to jobRelationsInfo HRIS element. It is important that
external code for custom relationship is same in both picklists – PositionMatricRelationshipType and
jobRelType.
9
Position org chart of the employee displays matrix positions linked with the position.
Customized relationship type appears in workflow but only when you select ‘Position Relationship’ as
approver type.
Please note that custom relationships are not available under any other approver type e.g. Role etc.
10
Assigning an employee to a position will make this
employee the supervisor for employees on positions
below this position.
a) Leading Hierarchy: Leading practice is to have Position Hierarchy set as leading hierarchy. Main value
proposition for using Position Management is to plan and control headcount and vacancies. Position
Hierarchy as a baseline is the only way to ensure this.
If you choose to set Reporting Hierarchy as the leading hierarchy then this arguably negates the main
value proposition for using Position Management and causes maintenance overhead with no additional
benefit. In addition, product direction is to assume Position Hierarchy is leading. So, to depart from this
practice could cause future issues. Any future enhancement in Position Management will be based on
position hierarchy as the leading hierarchy.
c) Default The Supervisor Or The Position In Hire, MSS Job Information And History: Options are Yes
and No. If Position Hierarchy is the leading hierarchy, then it is recommended to set this value to “Yes”.
This allows for automated data maintenance and also, ensures consistency and alignment.
If you select “No”, this will allow Position Hierarchy and Reporting Hierarchy to diverge, confusing users.
d) Threshold for Running Adoption of Reporting Line and Job Relationships as a Job: You need to
enter a number in this field. Once the number of incumbents of either child positions or matrix positions
hits this number, the updates to the hierarchy or job relationships will be carried out as a scheduled job. If
the number falls below the number, then the update will happen immediately. Please note that if the
number is 0, then it will never be triggered as a job. Also, this setting is only relevant if the position hierarchy
is the leading hierarchy.
If you do not enter a number in this setting. performance issues may occur for high volume movements.
It is recommended to set this field to 100 to mitigates potential performance issues in moving many direct
reports and job relationship records in an online transaction.
e) Automated Daily Hierarchy Adaptation- Use Automated Hierarchy Adaptation: This field is editable only
if the job “BizX Daily Rules Processing Batch “is scheduled with daily recurrence.
It is recommended to set the value for this field to “No“. This should only be used if the client wants to
ensure there is 100% alignment between Position and People Hierarchy. In addition, this feature should
11
NOT be used where multiple incumbents are allowed since the Job will set the Job Information supervisor
based on the incumbents of the higher-level position and the system has no way of determining which of
the multiple incumbent to assign. Also, there may be valid reasons why a small % of people could have
reporting and position misalignment. Using this setting will reset the data for valid exceptions. This could
confuse users.
Enabling the field value to “Yes“ ensures that position and reporting hierarchy are always in sync.The daily
recurring background job checks for each employee, who is assigned to a position, if his/her assigned
supervisor still matches the position hierarchy. In case reporting line and position hierarchy are not in sync,
the system will update the employee’s supervisor assignment accordingly.
Once this job is enabled:
• Any changes that are made with effective date TODAY, these changes will be synced automatically in the
system and not carried out by the job.
• Any changes that are made with a future effective date will be carried out by the job that runs on that
effective date.
• Any changes that are made with a past effective date, will be synced in the next run time of the Job. These
records created by the sync will have the effective date of the job run date and NOT the effective date of
the past dated change. If past dated transactions occur regularly in your organization, and you wish the
dates of the position change and the job info changes to be in sync, we recommend to not use this feature.
f) Automated Daily Hierarchy Adaptation- offset in Days: Not applicable because we recommend that
hierarchy adaptation should not be used. If you choose hierarchy adaptation, the number entered here
specifies the number of days before any future dated position changes will be synced with the incumbent
of the position.
Position Organization Chart - 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 navigate to “Org Chart Configuration” to make
selections of fields and sections that you would like to be displayed.
Although, you can also access position details using Manage Data, it is recommended to use either
Manage Position/Position Org Chart->Edit Position to make any changes. If you use manage data
transaction, then the Position to Job Info sync rule is not called and as a consequence data is out of
sync.
3. Data Propagation – Data propagation for job related fields is possible during Position creation and
during Position Change. This is achieved through business rule assigned to the Job Code field in
Position Object. When Job code is updated on a position, other related fields like Job Level, Pay grade
etc. as per the rule also get updated.
12
Rule for data propagation from Job Classification to Position
Similarly, data propagation is also possible for Job and Organization related fields when position is assigned
to an employee either at the time of Hiring or during Position Change action/event. This minimizes data
entry, increases accuracy and gives HR more consistency and control.
onChange rule assignment on Position field in Business Configuration is shown below on Job Information
base object:
13
Rule for data propagation from Position to incumbents Job Info
4. Synchronization – Synchronization rules can be defined to update common fields between Position
Generic Object and Job Information Employment Object so that any update on these fields is consistent
between both the objects.
b) Synchronize Position Matrix Relationships to Job Relationships of Incumbents: The options are
Always/Never/Only when Position Assignment of Employee is changed/Only when Matrix
Relationships of the Position are changed.
The recommended setting is “Always” to ensures job relationships are kept in sync if any changes are
made on the position relationships (HRBP only).
c) Rule for Synchronizing Position to Job Information: It is recommended to define rule that syncs all
common fields on Position and Person. This allows for data maintenance, reduced effort benefits via
defaulting. Sample rule is available in following document for reference.
d) Rule for Synchronizing Job Information to Position: Rule can be defined to sync changes to the
following data elements from Job Information of the incumbent to assigned position:
1) Department
2) Cost Center
3) Location
4) Job Code
This allows the manager to amend a key subset of data on employee level which is more intuitive than
maintaining position data and then syncing to the person. The data elements synced to position here
are the elements that are deemed to have higher volatility and are acceptable not to be driven by
14
Position data and which can validly be driven by employee data changes. Sample rule is available in
following document for reference.
e) Search for Position in Position Reclassification: Available options are Yes/No. If you choose Yes,
the system first searches for a position that has status “To Be Hired” before creating a new position in
case of a position reclassification where multiple incumbents are allowed.
If you choose “No” system creates a new position without searching in case of position reclassification
where multiple incumbents are allowed.
These are invisible background changes, which could cause confusion and result in lack of control.
It is recommended to have “Multiple incumbents Allowed” field in Position Object to be set to “No” so
that no new position is created in case of Position Reclassification but the existing one updated.
f) Search for Position in Position Transfer: Available options are Yes/No. If you choose Yes, the system
first searches for a position that has status “To Be Hired” before creating a new position in case of a
position transfer where multiple incumbents are allowed.
If you choose “No” system creates a new position without searching in case of position transfer where
multiple incumbents are allowed. These are invisible background changes, which could cause
confusion and result in lack of control. If the Job to Position sync exists then these changes will also
update the original position based on synchronization rule, which may not be desirable.
It is recommended to have “Multiple incumbents Allowed” field in Position Object to be set to “No” so
that no new position is created in case of Position transfer but the existing one updated.
It is worth noting that we don’t configure the system to make use of position transfer, since in many
cases a position is being created and another is left behind. Position transfer also only makes sense
when you change the supervisor in job information.
g) Stable Headcount Area for Position Control Mode : Available options are fields from the
Position object. It is recommended to have “No Selection” for this field as we are not creating positions
in the background. We are not using this feature in the leading practice configuration. You
could use an organization level for this if you wanted to have the system automatically transfer / create
/ deactivate positions within the organization entity chosen here or maintain a stable total FTE value.
Below we discuss the synchronizing rules assigned in “Position Management Settings” under the
Synchronization tab:
While creating rules for synchronization, rule scenario must be selected from Position Management
section in "Business Rules”
15
“Synchronize Position Changes to Incumbents"
Define a rule to specify which common fields between the Position object and the Job Information
employment object are synchronized when changes are made in the Position object.
Recommendation: Please note that if you are using Object association, the field order is essential.
The order in which the fields are mapped, should depend on the structure of your object Associations
e.g., If Business unit is higher than Division object in Hierarchy, then the Business Unit set condition
must precede Division set condition.
The below example is incorrect as the object association Structure is not respected.
This will lead to Position to Job Information Sync Rule not working correctly and, in some cases, not at
all:
16
Correct rule is:
Another consideration while writing the rule is regarding entities that can be used in the rule and those
which shouldn’t be used in the rule. Common fields that can be used in sync rule are org and job fields.
Following Job Information fields must not be part of the rule for Position To Job Information
synchronization as this could lead to serious data inconsistencies:
If you want to trigger a synchronization when you're importing positions, add the "technicalParameters"
column to your position import file. Enter "SYNC" as the value for the "technicalParameters" column to
those position record that are to trigger a synchronization to the Job Information object. The
synchronization is carried out on the effective start date of the corresponding position record.
The sync from position to Job Information is currently only supported on position imports via CSV. The
Position to Job Information Sync is not triggered on Position Imports from OData/API.
If any changes are required in Position attributes, the recommended practice is to update affected
position using Manage Positions or Edit position from Org Chart, if the Position hierarchy has been
set up as leading hierarchy.
However, in situations where managers need to make position attribute changes for limited position
fields frequently, like location and cost center, then the same can be done from incumbent’s Job
Information which will sync to position based on sync rule. Managers will need to have field level edit
access to these limited position fields.
17
Define a rule to specify which common fields are synchronized to the position object when changes are
made in the Job Information Employment Object. Note that this only applies to changes that the system
regards as a position reclassification or position transfer. Event reasons with follow up activity
maintained as Position Reclassification/Position transfer are checked for this identification. Please do
not change the external codes for predefined value for Position Transfer and Position Reclassification
in the picklist positionActionType as this will impact position follow up activities.
Position transfer is associated with change in supervisor activity while Job Information changes e.g.,
new job, new department etc. are associated with Position Reclassification.
When defining the rule, there are some things you need to bear in mind as also mentioned in
implementation guide:
• Only the fields configured in the rule are used to search for a matching position for position
reclassification and position transfer.
• If the system doesn't find a matching position during position reclassification and position
transfer, it creates a new position implicitly (without a workflow process) in the background
and values are automatically assigned to the fields configured in the rule. This means that
if, for example, the costCenter field is not defined in the rule, the value for the costCenter
field from the Job Information object will not be assigned to the new position. Instead they
will be copied over from the position being copied.
• If an existing position is updated for position reclassification only the fields configured in the
rule are updated.
• If Employee status is not queried in the sync rule, changes to position attributes will be
synced back to Position from inactive employee record. Hence, If condition in the rule can
be enhanced to include a check on Employee Status.
As per best practice, managers should not have access to terminated employee records
and if Admin needs to make any changes to Position Attributes, the same should be done
on Position and not on Job Information record of terminated employee.
18
The system behaves differently in case of Position Reclassification based on whether one or more than
one incumbent is allowed to the position (Shared Position).
Shared Position Illustration: The position 90200104 is shared between two employees. If cost
center changes are done for Christa Gollwitzer, system creates a new position for her
19
Please note following:
The system behaves in the same way in case of Position transfer irrespective of whether one or more
than one incumbent is assigned to the position. 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.
If direct reports were assigned to the transferred employee, You can use option available under Position
Type to determine whether and how the incumbents of the lower-level positions are transferred. The
possible options are:
20
• To manager on next higher-level position – Incumbents reporting to the leaving employee are
transferred to the next available incumbent on a position in the position hierarchy above the
leaving employee's position.
• To next manager on leaving position if available – Incumbents reporting to the leaving employee
are transferred to another incumbent of the leaving employee's position if available. If none are
available, the incumbents are transferred to the next available incumbent on a position in the
position hierarchy above the leaving employee’s position.
• To no manager – Incumbents that are reporting to the leaving employee will be changed to report
to "No Manager".
If another position was selected manually while the Job Information was changed, position transfer
doesn't take place. Only the Job Information is saved.
For further details on Position Reclassification/Position transfer please refer to the implementation guide.
General tab in Position Management Settings has options to regulate general behavior in Position
Management.
a) Position Types- Position Types allow for different behavior in certain aspects:
1) You can opt to trigger a workflow on Job Information if position changes have been synchronized to
incumbents.
2) You can specify to whom direct reports should report if their current manager leaves his or her
position.
3) You can specify whether the reporting line should be adapted after the position hierarchy has been
changed.
21
4) You can determine whether and how job relationships for this employee are adapted.
5) You can set up and manage transition periods for more than one position.
6) You can configure different Sync Rules.
Values available for this field are Yes/No. Recommended setting is “No” which means not to use
Position Types.
You might want to depart from leading practice if you have a significant portion of the population that is
required to work in a significantly different way. The business rationale for this different way of working
should justify the increased complexity of Position Types.
If using Position Types, settings maintained for fields under Position Type override the settings
maintained under Position Management settings.
Please pay attention to field “Synchronize position matrix relationships to job relationships of
incumbents?” .This field is by default “Not Visible” on UI.It is recommended to change visibility settings
for this field to “Editable” and maintain desired value else synchronization of relationships from
Position to incumbent will not happen if Position Types are being used.
b) Is the Position External Code Auto Generated?: Available values for this field are Yes and No.
• If YES, the external code will be generated via rule which has to be added to the Object Position as
ValidateRule or SaveRule.
• If NO, the external code will be generated based on the name of copied position and added UUID.
It is recommended to set this field to “Yes” as automatic generation of position code ensures
consistency and aids data entry. Leading practice is to always include a number sequence as any code-
based sequence will be outdated if attributes of the position are changed.
When a new position is saved, the External Code for the new positions will be determined based on:
• The Flag "Is the Position External Code Auto Generated?" in the Position Management Settings
• Sequence maintained in “Manage Data”
• Business Rule for generating the external code.
c) Set 'To Be Hired' Status if Incumbent is Unassigned from a Position: Available options for this field
are Always/Never/Only if Current FTE Value is below Planned Value.
22
Leading practice is to set the value for this field as “Only if Current FTE Value is below Planned Value”.
This ensures maximum control and transparency. Other values do not add any value.
d) Reset 'To Be Hired' Status if Incumbent is Assigned to a Position: Available options for this
field are Always/Never/Only if Planned FTE Value is Reached. It is a leading practice to set the value
of this field to “Only if Planned FTE Value is reached”. This ensures maximum control and transparency.
Setting this field to Never will lead to inconsistency in data and reporting. While setting this field to
“Always” does not have any intrinsic benefit.
e) Set or Reset 'To Be Hired' Status if Position 'FTE' is Changed: Available options are Yes/No. It is
recommended to set the field value to “Yes”. This ensures maximum control and transparency. While
setting this field to “No” does not allow consistency in reporting and how 'vacant' positions are identified.
f) Set or Reset 'To Be Hired' Status if an Incumbent's 'FTE' is Changed: Available options are Yes/No.
It is recommended to set the field value to “Yes”. This ensures maximum control and transparency.
While setting this field to “No” does not allow consistency in reporting and how 'vacant' positions are
identified.
Vacant Positions: Field id "vacant" in Position Object corresponds to on screen field "To Be Hired" on
Position. “To Be Hired” field can be set to Yes to indicate a vacant position. This position then becomes
available in Position Org Chart for creating requisition for hiring.
It is important to maintain FTE in Job Information for employees and Position Control should be set to
“Yes” in Position for these settings to work.
Transition Period: This functionality allows for temporary overstaffing of positions during Termination
or Leaves.
If you would like to make use of this functionality, Transition Period setting needs to be maintained as
part of “Position Management Settings”. If you set the value “No” for this field, then the system will not
allow overstaffing during a handover period.
It is worth considering any impact on On-Premise HCM ERP system/downstream systems arising due
to implicit changes that get triggered, like additional position creation in the background etc., due to
Position Reclassification/Position Transfer. There are pros and cons associated with using Transition
Period settings as detailed below:
23
Downstream systems impact arising due
to Position Reclassification/Position
Transfer needs to be evaluated including
workflows to determine which
supervisor/manager must approve
(new/old).
Note that this is a global setting. If more granularity is needed Transition Period of a particular Position
Type should be defined under Manage Data.
“Position Type Transition Period” object needs to be associated with “Position Type object” and visibility
should be set to “Editable”.
24
25
For occupied positions to show up in Job Information UI/Hire UI, it is recommended to manually change
the setting of the field “To Be Hired” to “Yes”.
6. Right to Return – This feature allows you to unassign and reassign an employee to a position, when
on Leave of Absence or Global Assignment.
As per new data model for Right to Return, rules need to be maintained under Tab “Right to Return”
in Position Management Settings to unassign from position and to Create Right to Return for both
LOA and Global Assignment. This allows for backfilling of position and tagging of contractual obligations.
Otherwise system will not allow backfilling of position.
Event Reason for unassigned Position: The event reason you select here is used for unassigning the
home employee from the position in the Global Assignment period.
Event Reason for assign Position: The event reason you select here is used for assigning the home
employee again to the position after the Global Assignment period.
It is important for customers to migrate to new data model for “Right To Return” to meet certain legal
requirements for data protection and privacy. This can be done via upgrade center. Any upcoming
developments for Position Management will be based on the new data model only
If you are using right to return for LOA, then, for each time type, you can create a take rule that will
automatically set the ‘Actual Return Date’ = ‘Expected Return Date’. As a result, the employee will be
reassigned back to their position without the need to update the original time record.
26
• If you unassign an employee during leave of absence (LOA) and if you update Job Information during
the LOA, the employee will not have a position and hence the data cannot be synced back to
the position as the field is empty.
• You cannot make position field mandatory.
• Right to Return is not supported in ERP.
The deletion of cost center in IT0001 happens due to PA-PD integration whenever Position relationship
is delimited in HRP1001. In such a PA-PD integrated system, for an LoA in EC, you have two options:
7. UI Customizing: You can use the options on this tab to determine how UI behaves.
a) Rule for Defining Copy-Relevant Position Fields : It is recommended to select a rule in this field that
should copy Organization fields, Standard Hours and Job Relationships (HRBP Only).This allows ease
of data entry for certain elements that typically do not change when a new position is created. It is
important to note that this rule is also used when creating peer and lower-level positions.
Not setting this would mean that all fields on the positions would need to be entered individually.
b) Respect Workflow at Copy Position in Position Organizational Chart: Recommended setting for
this field is “No” as Central Admin will be doing this, and the general principle is that workflow is not
required if admin initiates a transaction. Selecting “Yes” for this field will trigger the workflow saved on
Position Object when they are copied using Position Org Chart.
c) Use Company Filter for Positions in MSS Job Information and History: Options available for the
field are Yes/No. It is recommended to set this field value to ‘Yes’. This restricts available positions to
the user’s Legal Entity, which aligns with the design principle that managers only are responsible for
positions in their own teams. Will take precedence over any RBP restriction. Also, this has the benefit
of increasing usability, refining the position listing to just the manager’s target population. Selecting ‘No’
would allow a much wider list of positions if not restricted by RBP. This might give the user access to
information that they do not need.
d) Allow Selection Only of Positions That Have Status 'To Be Hired' in MSS Job Information and
Hire: Options available for the field are Yes/No. It is recommended to set this field to ‘Yes’ so that
system presents only a smaller list of applicable positions to the user.
Setting this field to ‘No’ causes system to present to the user positions that are also staffed, resulting
in annoying error messages when the user tries to assign a person to the position.
e) Display 'Incumbent of Parent Position' in Hire, MSS Job Information and History: Available options
are Yes/No. It is recommended to set this field to ‘No’ as it is not needed to filter position based on
parent incumbent since this information mostly would come through from onboarding and filtering is
done by central admin who do not necessarily need this information for filtering purposes.
f) Show 'Deactivate Position' option in Employee Termination Screen: Available options are Yes/No.
Recommended setting for this field is ‘No’ as this detail should not be presented to the user within the
27
context of self-termination or to the manager. Increased control means that this should be maintained
by central admin as a follow-up process.
If set to ‘Yes’ this could allow a lesser amount of redundant positions but could have position closed or
left open inappropriately.
8. Import: You can use the options on this tab under Position Management Settings, to configure how the
system behaves in import scenarios. It is recommended to set following field values to “No” during initial
load to avoid performance impact. Business is expected to validate initial load thoroughly. Post initial
load, value for these options can be updated to “Yes”.
a) Adapt Reporting Hierarchy During Position Import : Available options are Yes/No. It is
recommended to set this field to No during initial load and after initial load update this setting to Yes,
the assumption being this would typically only be used in bulk scenarios and align between position
hierarchy and reporting hierarchy.
Note - this only applies to positions in the import file.
Setting this field to No would allow divergence between reporting and position hierarchy which is not a
desired result.
b) Validate Position Assignment During Job Information Import: Available options are Yes/No. It is
recommended to set this field to No during initial load and after initial load update this setting to Yes,
The assumption being this would typically only be used in bulk scenarios and align between position
hierarchy and reporting hierarchy.
Note - this only applies to positions in the import file. If set to No, this would allow divergence
between reporting and position hierarchy as a result. This is not a desired result.
c) Adapt The Position 'To Be Hired' Status During Job Information Import: Available options are
Yes/No. It is recommended to set this field to No during initial load and after initial load update this
setting to Yes to avoid data inconsistencies. Note that this option is only relevant if you have specified
that the To Be Hired status of a position has to be adapted if an employee is assigned to a position, if
the employee's assignment is removed and/or if the incumbent's FTE is changed.
e) Execute Reclassification or Transfer During Job Information Import- Event Reason For Position
Assignment Change: It is recommended to set an event reason in this field. The event reason you
select here is used when the position assignment is changed during the import of Job History data
because of a position reclassification on a mass position or a position transfer. If you don't select an
event reason here or the imported record is a hire or termination record, the event reason from the Job
Information import file will be reused.
f) Execute Reclassification or Transfer During Job Information Import- Ignore Event Reason
Derivation: Available options are Yes/No. Choose Yes if you don't want to use Event Reason
Derivation to determine the event reason when the position assignment is changed during the import
of Job History data. In this case, the event reason configured in the “Event Reason For Position
Assignment Change” field above is used. If nothing is configured, the event reason from the Job
Information import file is reused.
Note that this option is only relevant if you enter Yes in the Execute Reclassification or
Transfer field.
It is recommended to set this field to ‘Yes’ to align with online changes approach and to ensure
consistency.
g) Adapt Hierarchy During Job Information Import- Adapt Hierarchy: Available options are Yes/No. It
is recommended to set this field to No during initial load and after initial load update this setting to Yes
to ensure data consistency.
h) Adapt Hierarchy During Job Information Import- Event Reason For Supervisor/Position
Assignment Change: It is recommended to set an event reason in this field. The event reason you
select here is used when the supervisor assignment (if the position hierarchy is leading) or the position
assignment (if the reporting hierarchy is leading) is changed during the import of Job History data. If
28
you don't select an event reason here or the imported record is a hire or termination record, the event
reason from the Job Information import file will be reused.
Note that this option is only relevant if you enter Yes in the Adapt Hierarchy field.
i) Adapt Hierarchy During Job Information Import- Ignore Event Reason Derivation: Available
options are Yes/No. Choose Yes if you don't want to use Event Reason Derivation to determine the
event reason when the hierarchy is adapted during the import of Job History data. In this case, the
event reason configured in the “Event Reason For Supervisor/Position Assignment Change” field above
is used. If nothing is configured, the event reason from the Job Information import file is reused. Note
that this option is only relevant if you enter Yes in the Adapt Hierarchy field.
It is recommended to select Yes here as it aligns with online changes approach and ensures
consistency.
9. Integration: You can use the option on this tab under Position Management Settings, to configure the
integration with Recruiting Management.
a) Raise events when a position is created or updated - Raise Events: Available options are Yes/No.
It is recommended to set the field value to Yes to raise an event whenever a position is created or
updated in the system. By raising events, you enable applications like Recruiting Management to
perform specific actions. For example, an update to the job requisition.
b) Recruiting Management- Use Recruiting Management Integration: Available options are Yes/No. It
is recommended to set this field to Yes to switch on integration between SuccessFactors Recruiting
Management solution and Position Management. If you are not using SuccessFactors Recruitment
Management solution, then the value needs to be set to No.
c) Recruiting Management- Rule for Deriving Job Requisition Template ID: Set the rule for deriving
Job Requisition Template. Different Job Requisition Templates can be configured for different positions
based on foundation objects e.g. Legal entity. The rule set in this field can automatically derive the
template relevant for position for which Job requisition is being created.
d) Recruiting Management- Field Mapping Rule to Create Job Requisition from Position: Set the rule
to pass values from Position to Job Requisition during creation of Job Requisition.
Further details regarding cross module integration with Position Management are discussed in section
below.
Position object helps to set up integration with other SuccessFactors solutions like Recruitment, Succession
Planning, Job profile builder.
29
5.4.1 Integration with Recruitment
You can create requisition for vacant/understaffed positions from Position Organization Chart.
Once the Job Requisition is successfully created, Requisition details are available on Position.
Integration settings need to be maintained in “Position Management Settings “so that requisition can be
created for vacant position. These have been mentioned in previous section.
Sample rule for Deriving Job Requisition Template ID and Position to Requisition field mapping are
available in implementation guide. Ensure these rules are created from highlighted scenarios under
“Position Management” using Configure Business Rules. There are some rule functions which can be
used in this mapping. Details of these can be found in implementation guide.
Some points to note with respect to mapping fields between Position and Job Requisition using a
business rule are:
1. The external code for fields to be mapped from Job Requisition template, can be picked from OData
API Data Dictionary.
30
If you do not see the external code available in OData API Data Dictionary for some fields recently
changed, it is recommended to execute OData API Metadata Refresh from the instance.
2. Do not forget to include following block in the rule if you are not mapping all the required fields between
position and Requisition Template else system will through error during “Create Requisition “execution.
3. If you need to map picklist values from Position to RCM, then this will require some extra steps as
described below:
a) Create a new custom object for the custom RCM field for which you need to pass the values.
31
b) This object needs to contain externalCode and OptionId fields. OptionId to be used is the legacy picklist
value of mdf picklist used for the position field being mapped.
c) Navigate to Manage Data and maintain external code and optionID for each picklist value. It is important
to ensure that OptionId is same in EC and RCM for values being mapped.
32
d) Use lookup in the rule to pass the value to Requisition Template
Assign both the rules in Position Management Settings under “Integration “section.
Navigate to “Org Chart->Position Org Chart and search for a vacant position. Click on “Create Job
Requisition“.
If during requisition creation a future date is selected, the system creates a Position Requisition
Processing Request that will automatically be converted to a Job Requisition on the selected creation
date.
Once Job Requisition is created, Position details also show Job Requisition details in Position Org Chart.
33
5.4.2 Integration with Job Profile Builder
A Job profile contains all the elements that can define a job or a position in your company.
Positions can be mapped to Job Codes. You can create a position-based job profile.
Diagram below shows how Position is linked with Job Code which in turn is linked to Job Role, Job Family
and Job Profile.
34
These job profiles can be used and are visible within the different areas of the system, such as in Recruiting,
Career Development, Succession, and Employee Profile.
SAP SuccessFactors Succession Planning helps HR professionals identify and develop the talent
needed to improve organizational strength and achieve today’s business goals, while providing visibility
and planning for future growth.
Succession plans can be created either based on Position or based on Role. Prerequisite for Position
based succession planning are:
35
• Succession Plan is retained if the incumbent leaves the position
• Allows for creating succession plans also for vacant positions
• Job profiles in Succession are accessible only through positions
• No standard tiles and dashboards are available for role/role-person based succession method.
Those are supported only for MDF Position Based Nomination method
• Reporting functionality in succession planning requires position association.
• RBP can be applied for restricted view of position details for Succession Planners.
Note: Managing integrations during a phased roll out is quite challenging. From deployment perspective
following is recommended:
• Big Bang Employee Central deployment with Position Management enabled is the preferred option.
• For customers opting for phased roll out, Side by side deployment model with mini master for the
entire population during the first roll out of Employee Central with Position Management enabled is
a recommended approach.
• If for some reason above two options aren’t possible then organization and position data must be
created for senior management/other positions that require succession planning as hybrid
population is not supported. Position Management should be enabled.
Manager
Manager is primarily responsible for ensuring that their employees are in the correct position at the
correct time, whether that be a new position or an existing position. It is generally the manager’s
responsibility to ensure that the organizational, contractual, and non-personal data recorded against the
employee is complete and correct.
To perform these tasks:
1. We recommend that the direct manager has access to view a restricted set of data for all employees in
the general employee/manager org chart.
2. We recommend that the direct manager has access to edit and transact on employee’s in their direct
hierarchy only on a subset of data.
3. We recommend that the direct manager has access only to the filled positions and vacancies within their
direct organization in the position org chart only. They should not be able to access positions outside
their direct hierarchy.
4. If you would like to limit the data completed by the manager, you can do this using role-based
permissions (RBP). However, the manager will need to complete all mandatory fields.
5. It is assumed any changes to position data will flow from the person and managers will not be making
position changes.
With this access, the manager has the specific responsibility for
Manager’s Manager
Manager’s Manager is the incumbent of the position to whom the line manager initiating the request
reports. Their role is to approve new positions created by their direct lower-level managers. Because
they are a manager’s manager, they are also granted access via the Manager RBP role. We discussed
the details of this access above.
HR Administrator / Org Design Expert is a central resource responsible for maintaining organization
design.
36
HR Business Partner
The HR Business Partner (HRBP), it is proposed, should not have an active role in the following process
other than being informed that a new position has been created. It is also anticipated that there will be
offline discussions supporting the subsequent system-enabled processes.
Recruiter
The Recruiter is informed that a position has been created. They are then responsible for deciding on
when recruitment activity should start. At the appropriate time, they are also responsible for initiating the
Job Requisition Process. Doing this triggers recruitment activity.
Here’s an overview of the suggested leading practice RBP settings for the key roles in the Position
Management Processes.
37
Manage Position Employee Manager HR Admin Recruiter
Access Position
Organization Chart X X X X
Allow Date
Selection for
X X X X
Position
Organization Chart
Mass Copy of
Position in Position X
Organization Chart
Option to move
Position to New
X X
Supervisor on Job
Info Change
View Job
Requisition in
X X X X
Position
Organization Chart
Create Requisition
from Position X X X
Organization Chart
Select Job
Requisition
Template in X X X
Position
Organization Chart
Create Position
from Position X X X
Organization Chart
Manage Position
Management X
Settings
Manage Requisition
in Position
Organization Chart) X X
Only need with
recruitment)
Target Groups None See all ALL
Based on
positions
the area
below
they have
higher-
permissi
level
on
position
38
Please note that, if an employee has multiple roles, then the permissions are cumulative.
Therefore, you may restrict permissions with one role, but grant wider permissions with another.
Magalie De Bruyne is a Supervisor with Permission Roles – Employee Self Service and Manager Self
Service.
With her current permissions she has access to view Position Org Chart, Add Lower Level Position, Add
Peer Position and View Job requisition as shown below. You can check user permission using “View
User Permission”.
If her role is extended to include HR permissions, her access will have permissions from her Supervisor
Role as well as from HR Business Partner role giving her additional access to Create Requisition, Mass
Copy of Positions, Access Position Management settings etc. as shown below. “View User Permission”
shows additional access for Magalie De Bruyne.
39
It is recommended to use “View User Permissions” to check which role is providing which access to
employee, if there are issues with access and adjust the role permissions accordingly.
Permission Roles based on Relationships such as Higher-Level Position and Matrix Relationships also
respect effective dating. For the Permissions to be respected on the target position, there must be a
record existing on or after the effective date the incumbent is assigned to the target position. The target
granting for position is based on start-date of records.
For example: Nancy Jackson is a Matrix Manger with Permission Roles to all Matrix Report Positions.
Her Position is listed as the Matrix Manager for a Position with Incumbent Emelda Akers. When Nancy
searches for Emelda’s Position she is unable to see.
If we look at the below example, we can see Emelda became the incumbent of her position on 1 Oct
2011 however her position has only one record effective as of 01/01/1900. As this permission is
granted based on a relationship, the effective dating logic of the start date is being used by the system.
As Emelda’s Position has no record on or after the effective start date she was assigned to the
Position. The permission logic will not recognize the relationship between Nancy and Emelda’s
position based on the current effective dating.
For Nancy to see Emelda’s position a record must be created on Emelda’s position on or after 1 Oct
2011.
40
5.6 Positions: Planning for The Year Ahead
Each year, there is a process whereby an organization needs to decide on its proposed business plan
for the upcoming year. This can take several forms including, but not limited to:
Here are the specific actions that this annual process might affect:
• Allowing an organization-specific ‘model’ to be developed, refined, and approved with an SAP or third-
party software specifically designed for this purpose.
• Allowing existing positions to be deactivated or moved, and new positions to be added via a spreadsheet
upload or the Position Object Mass Change feature into Employee Central so they are available for use
in the upcoming year. It is assumed that, prior to such an upload, creation of the position is subject to
an internal approval by the business.
Once the annual cycle is complete, then ‘life in the organization’ happens. In relation to the approved
position that are active in the system because of the annual planning cycle, these happenings include
the following:
1. There is a need for a position that was not foreseen in the annual review cycle.
2. Employees need to be moved from one position to another as the result of applying for an internal job.
3. Employees need to be moved from one position to another as the result of not applying for a job.
4. The attributes of a position need to be amended because the nature of that position has changed, for
example the grade needs to change because the incumbent is promoted. Be careful while re-using the
positions when you have successors. If an employee is in the position as a ‘HR Manager’ and has 2
successors and if we promote ‘with in’ the position to HR Director, then the 2 successors will now be
successors to the HR Director role not the HR Manager role.
5. People leave, and their positions need to be filled.
6. People leave, and their positions are no longer required and are being removed.
7. There is a reorganization that means that position attributes might be renamed or changed in some
other way.
Any or all these things can happen in any part of the organization on any day. But how should the main
actors within an organization interact with the system to perform these tasks? There are many ways of
setting up Position Management to accomplish these tasks. We have provided recommendations
covering various aspects of Position Management Configurations in above sections of this document
that you can consider to set up the system to this end.
41
• Their own position as lower-level position.
• One of the positions that already exist directly below their position, via add peer position.
Many of the attributes of the existing position will be automatically taken and defaulted into the new
position. The information copied is typically the organization information. The assumption here is that
the new lower-level position will contain the same organizational information. The manager, therefore,
typically only needs a few additional pieces of information, including but potentially not limited to:
• Job Classification Information, which in turn typically will facilitate the defaulting of further attributes like
Pay Grade.
• Location Information, which in turn typically will facilitate the defaulting of Pay Range Information.
It is not expected that Employee Categorization data will be maintained on the position because this
data is largely determined by the recruitment process.
Once the manager has filled in this information, it needs to be approved before it is considered active.
The recommended approval route is as follows:
1. Next Higher-Level Position incumbent, this is the incumbent of the Position to whom the Line Manager
who initiated the request reports.
2. HR Administrator / Org Design Expert is a central resource responsible for maintaining organization
design.
Once both roles have given their approval, the position is considered active and will be visible in the
position org chart on the effective date that the position is recorded as becoming active. We recommend
that the recruiter is notified on final approval of the position, so they have visibility of the fact that it has
been approved, though they do not have approval rights on the position. There is a follow-up activity
once the position has been approved whereby a Job Requisition needs to be created for the new
position, so recruitment activity can start. We recommend that the recruiter who is informed about the
position creation should be responsible for creating the job requisition. We also recommend that the
recruiter goes into the Position Org Chart and selects the position for which they want to create a job
requisition. This means that the manager does not need to return to the Position Org Chart to initiate
the job requisition after creating the new position. Another reason why recruiters should create a
requisition is the need for additional information to which the recruiter should have access in order to
create the requisition successfully. We also recommend that the HRBP is cc’d on the position creation
process, so they are informed once the position is approved. This is for information purposes only. The
requisition also requires an approval process and we recommend that the manager should have
approval responsibility for the requisition so that they can see that the recruitment process has started.
At the end of the recruitment process, the prospective hire is recorded in a ‘Ready to Hire’ status within
the Recruitment module. They can then be accessed in the ‘Manage Pending Hires’ screen by Central
Administrative resources who are then responsible for moving them into their new position. This
transaction is usually relatively seamless with most of the data fields required to create an Employee
Central record, including Position, being mapped directly into EC from the Recruitment module or
Onboarding.
It is important to understand that the managers do not have a direct role in this transfer process in that
they do not perform the transfer process themselves. This is done by central admin. The losing and
receiving managers would be involved in supporting the workflow approval process for the related job
requisition and could be involved in the final transaction approval dependent upon the nature of the
change, for example, if the change is determined as a promotion.
This internal hire process is the recommended approach for any change of position from within a
manager’s hierarchy to a position not in their hierarchy. In fact, in line with recommended practice,
42
managers will not have access to positions that are not in their hierarchy, so they will not be able to
move their employee to a position not in their hierarchy.
In such a situation, the recommended approach is to allow the manager to directly change the position
for their employee to a new vacant position within their organization. They would do this by, for example,
accessing the employee and using the ‘Take Action’ button on the People Profile, then choosing a new
position for that employee. The nature of this transfer is usually less formal in scope and scale and
involves moving people within the manager’s organization. Note that you CANNOT in the same
transaction change fields related to this position. If so, the changes will apply to the incumbent, but will
not be made to the position.
• When a reorganization occurs, and multiple positions need to have their attributes changed. This is
typically managed by a mass import of new Position Information and the subsequent syncing of this
information from Position to Person on the appropriate organization restructure effective date.
This can happen in one of two ways, depending on the nature of the data being changed:
• If an organization deems that the data being changed needs to be subject to increased control and to
be closely managed, then the data should be changed on the Position.
Due to the increased control required for such changes, we recommend that the changes are made by
Central Admin. The changes made here should, as a matter of course, be synced to the employee.
Recommended data to be amended in this way is data that typically does not change very often. This is
typically restricted to higher level organization elements, and Job Code information which in turn will
update other attributes like Pay Grade & Location to resolve the Pay Range.
• For some data recorded on the position, such as Department, Location, and Cost Center, which are
subject to a higher volatility in terms of the number of changes, there is less stringent need for control,
For these changes we recommend giving the manager access to maintaining them directly on the
employee and have these elements synced back to the position.
This has the benefit of reducing the amount of time Central Admin must get involved in updating the
position directly. It also means that managers do not have to worry about making position and person
changes in different places in the system, which causes confusion.
It is not possible as standard to permission the options on the Position Org Chart of "Add Lower Level
Position" and "Add Peer Position" separately. They both appear as standard. Leading practice is
typically to give managers the responsibility for creating positions below themselves and have that go
through the appropriate approval. We do not recommend that the manager should have the ability to
43
create a peer position as this is technically outside their own organization. This can be an issue
because the option to create a peer position will always be present if the Manager role is
permissioned to be able to add any position. The below rule, triggered onSave on Position submission,
will raise an error message if the manager is identified as not being the incumbent of the higher-level
position or if the person adding the position is in certain central admin functions.
7 REFERENCES
44