Skip to Content
Technical Articles

How to identify a manager based on position hierarchy

INTRODUCTION

In this blog post, you can learn how we can identify a manager based on the Position hierarchy instead of the direct report’s structure.

Sometimes the managers can have all positions below them as vacant and from a standard system point of view, they are not considered a manager as they do not have direct reports.

Some customers require to be able to assign specific permissions to their managers, for example, the permission to create a new job requisition for vacant positions, and in the case above, it would not be possible since they are not considered as managers. So how to identify these cases to consider them a manager?

To achieve this requirement of assigning permissions to a manager that has no direct reports, only vacant positions, the following solution is proposed.

 

PROPOSED SOLUTION

Step 1. Create a custom field in Employee Profile (Data Model XML) to identify if the employee is a manager with a picklist ‘yes’ or ‘no’:

EP_CustomField

Image from SAP SuccessFactors Demo: Employee Profile Custom Field

Step 2. Create a custom field in Job Information to control if the employee’s position is a manager position or not and map it to the EP custom field, using HRIS Sync Mappings (see screenshot below):

Image from SAP SuccessFactors Demo: Job Information Custom Field and mapping

Step 3. Create a Business Rule as per the following to control if the employee’s position has any child position (does not matter if the child positions are vacant or has incumbent). This rule will populate the Job information custom field = “Yes”, or “No” as appropriate.

Image from SAP SuccessFactors Demo: Job Information Business Rule

The recommendation is to add this rule in the configuration as onChange in the Position field and onSave in the Job Information because in case there is any update in the position it could trigger an update once any change is performed in the Job Information.

Once all the above steps are completed, you can use the custom Employee Profile field as criteria in the granted population permission group, to assign the necessary permissions to all managers.

 

CONCLUSION

This blog post described how we can identify a manager based on the position structure, instead of the direct report’s structure.

Please bear in mind that It is a simple and effective solution already implemented for a customer where the requirement was to assign the job requisition creation permissions to all managers, for all positions, not only their child positions, so this is why there is no need to identify any specific target population, but all.

For additional business scenarios on how to apply SuccessFactors Business Rules, I
would definitely recommend checking out the Employee Central: Optimizing Business Rules for Select Business Scenarios IDP (Implementation Design Principle).

Looking forward to your comments and questions.

 

8 Comments
You must be Logged on to comment or reply to a post.
  • Hi Karen,

    This is quite a helpful blog on how to handle job requisition creation permission for managers with no direct reports but only vacant positions under them.

    Cheers, Smitha

     

  • Hi Karen,

    How do you handle the update of the position when a subordinate position is added under it?

    Is there a process which runs in integration Center to check and update the flags? And if so, how do you then cause the sync and update of the employee record?

    Thanks,

    Chris

    • Hi Chris, thank you for your question.

      Thinking about this scenario, I would propose a different approach. In summary, would be to create the flag ‘Manager’ in the position object as well and create an Integration Center to map the object flag to the job information flag where the trigger is the Intelligent Service ‘Update to a Position’ event.

      Does this answer your question and make sense for you?

      Best Regards,

      Karen Perez

  • Hi Karen,

    I don’t think that will work.

    The problem is that the update of a superior or subordinate position does not directly trigger the update of the corresponding subordinate or superior position. Which would then trigger the associated update of the linked job information record.

    Until such time as the solution (SAPSF) enables functionality, I think anything we do will have flaws, we just have to be aware that they are there and do our best to acknowledge them and put in work arounds.

    I could build you a Cloud Platform extension that could fix this, but it’s not going to be worth the expense compared to the solution you already documented (despite it not working in all cases).

    What I’m trying to say is that things don’t have to be perfect to be worthwhile, but we should be very careful about claiming anything solves all problems.

    Cheers,

    Chris

     

     

    • Hi Chris,

      Thanks for sharing your thoughts and I do agree, the idea is not solve 100% of the use cases, but at least the one presented.

      I was ‘playing’ in my demo and for you to identify all the positions that are parents of others as you were referring to, including the newly created ones, you can do the following.

      Create a custom object (Lookup) with two fields only (Position Code, Parent Position). This MDF object can be automatically populated via IC as simple as in the example below (Position entity):

      Image%20from%20Demo

      Image from Demo

      After this you have to create an onSave rule in the Position object as per below:

      Image%20from%20Demo

      Image from Demo

       

      In summary, you are updating the ‘flag’ at the position level and this can be propagated to the Job info.

      Does this make sense for you?

      Thank you again for pointing out good cases so it gives all the opportunity to think more and more about solutions.

      Best Regards,

      Karen Perez