Skip to Content
Technical Articles
Author's profile photo Nidhi Mishra

SuccessFactors Employee Central Position Management: Tips and Tricks

SuccessFactors Employee Central Position Management is an important piece not only within Employee Central but also within SuccessFactors suite as it links other SF solutions like Recruitment Management, Succession Planning , Job Profile Builder etc. This makes it important to understand the recommendations around Position Management configuration.

I would like to highlight some points below that hopefully will aid in better understanding of the solution configuration:

  1. Business Rules for Position Management: Position is an MDF object and many of us tend to use “Metadata Framework” category to build rules required for Position Management.

Would like to highlight that there is a Category called “Position Management” under  Configure Business Rules.

This category has following rule scenarios:

If you have to create a rule for one of these scenarios , for e.g., Position Synchronization, Job requisition template derivation, Field mapping required for Position to RCM integration etc., then It is recommended to select appropriate scenario from this list. This pulls the right base objects for creating the rule.

Rules for synchronization/integration etc also need to be updated against correct fields in “Position Management Settings” else system will not execute them.

  1. Shared Position Vs Regular Positions: If your organization has a strict budget control in place then you should be aware of “Multiple Incumbents Allowed” field value on position. It is recommended to set this field value to “No”.

The reason for this setting is that if you also use Job Information to Position sync and if an attribute value is changed in Job Information of the incumbent, which syncs back to position as per the rule specified, then it can lead to creation of new positions in the background, without an approval process, if system doesn’t find a vacant position under the parent position.

  1. Position Reclassification and Manual Supervisor Change: Both changes cannot happen in one step. If you want an attribute change to sync back to position from incumbents Job Information (assuming this attribute is part of the sync rule) then you could first make this change and save the record. You need to return to the Job information and do Supervisor change as a next step.


  1. Transition Period: You can set values for Transition Period under “Position Management Settings”. But if you are using Position Types, you need to set the Transition Period values for each position type via Manage Data-> Position Types.

Global Settings maintained under Position Management Settings are used by the system only when Position Types are not used.

Similarly, 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.

Detailed recommendations for Position Management configurations are available in the recently released Implementation Design Principles document. Do check it out!

SAP SuccessFactors Employee Central Position Management: Design Considerations and Recommendations

The document provides leading practice recommendations while configuring SF EC Position Management and also details risks of taking alternative approach.

For structured guidance and advice on how to address challenging customer requirements please visit customer community.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Vishnu Kant Raman
      Vishnu Kant Raman

      Hello Nidhi, Thank you for sharing the tips and tricks.

      SAP in note says "if the Position is a Mass Position, with 2 users assigned and this Position has Direct Reports (DR),the first Incumbent of the Mass Manager position that is returned by the system will be used as the Manager for the incumbents of the lower level positions."

      Question: Is there any way using an API, can I find the userId of first incumbent returned by the system ?

      Author's profile photo Nidhi Mishra
      Nidhi Mishra
      Blog Post Author

      Hi Vishnu

      I seem to have missed this question.

      It is recommended that the supervisor positions aren't multiple incumbent positions.We have also recommended in the IDP to avoid multiple incumbents on a position as there are complexities whenever there are changes in position attributes/supervisor of a position which has multiple incumbents.


      Author's profile photo Rizwan Khan
      Rizwan Khan

      Hi Ms. Mishra,

      Position and Job are end date in ECP, when researched, it is happening when we change an attribute on either Job or Position in EC (effective dated), it results in that object being end dated in ECP after Job/Position replication. Any idea what we can do to prevent this? thank you in advance.

      Author's profile photo Nidhi Mishra
      Nidhi Mishra
      Blog Post Author

      Hi Rizwan,

      The query is not clear to me. Yes Job and Position are effective dated entities and I understand even in ECP they have the same behaviour. I am not sure of the issue that you are facing.Could you pls provide more details.Thanks,



      Author's profile photo Rizwan Khan
      Rizwan Khan

      Hi Ms. Mishra,

      Here is the example

      1. Position P0001 has Job code J0001, which has EE Class Union, (01/01/1900 - 12/31/9999)
      2. Job Code J0001, effective from 09/01/2022, Employee class is changed to Non-Union
      3. On next Position-Job replication, system ends the Position P0001 on 08/31/2022

      expectation was that system will have two records,

      • one from 01/01/1900 - 08/31/2022 and
      • other from 09/01/2022 - 12/31/9999

      Since the Position in end dated, therefore, on next employee replication, employee is in error.


      I hope this explains, thank you in advance.

      Author's profile photo Nidhi Mishra
      Nidhi Mishra
      Blog Post Author

      Hi Rizwan,

      Looks like BIB settings issue..ideally two position records should have been created- one till 31 Aug and another from 1 sept.

      Can you confirm If both position records are being read during BIB replication from EC? 

      Employee record is in error as the position assignment is no longer valid as per details shared by you.

      Hope you have raised a support ticket for this issue.


      Author's profile photo Rizwan Khan
      Rizwan Khan

      Yes, we have created a help ticket on Friday. Thank you.

      Author's profile photo Sandeep Pajni
      Sandeep Pajni

      Hi Nidhi,


      We are in process of doing implementation for a new customer and stuck in using either 1 FTE for each position being created, even the position share common properties, or should we create a mass position that shares common properties with FTE value more than one.

      For example, if there are operators in an organization branch, can we put them in the same position if we set the position to have multiple FTEs. Or, is it wise to have separate positions like operator1, operator2, etc, so that there are no issues related to salaries or any other issues from jobinfo to position sync?

      In our case, there could be up to 76 guards assigned to a same bank branch, so should we create guard1, guard2.. , guard76 positions with 1 FTE each? Or, do we use a single guard position with 76 FTE?

      Any guidance on the same would be much appreciated.

      Author's profile photo Nidhi Mishra
      Nidhi Mishra
      Blog Post Author

      Hi Sandeep,

      Using same position for multiple incumbents could lead to problem with Position Reclassification when position attributes are updated from incumbent's job Info leading to implicit creation of other positions. It would mean less control on number of positions that get created.

      It's a best practice not to have multiple incumbents in a position. We have also mentioned reasons for the same in the Position Management Implementation Design Principal. Kindly check the IDP for the same.

      Pls consider these aspects before finalizing the design.

      Sharath T N Would you like to add anything more to the response?