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':
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):
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.
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.
Permissions Considerations
As the proposed solution depends on Business Rules it is important to remember that business rules run/update fields which the user have view permissions, at least, so please remember to grant the view permission of the new field to the roles which will run process in the system.
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.
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':
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.
Permissions Considerations
As the proposed solution depends on Business Rules it is important to remember that business rules run/update fields which the user have view permissions, at least, so please remember to grant the view permission of the new field to the roles which will run process in the system.
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.
- SAP Managed Tags:
30 Comments
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
