Technical Articles
On Premise Customers requirements to have EC OM in Sync with Position Hierarchy
INTRODUCTION
Normally, onprem customer requires to have SuccessFactors Employee Central Organization Hierarchy in Sync with Position Hierarchy. This is because their HR process are defined based on the OM hierarchy and also because this hierarchy needs to feed the consumer systems. With the implementation of SuccessFactors Employee Central, the adopted leading hierarchy is the Position, making the OM hierarchy dependent on it.
As know, the successFactors Employee Central is based on the Position as a leader hierarchy and there is currently no standard automation/synchronization between Position and OM.
SOLUTION
Option 1: Manual OM update
A manual update is recommended from SAP where there will be a need to have a scheduled report that drives the OM responsible for checking if there is any difference between Position and OM hierarchy that needs to be adjusted and after this, a massive CVS file can be imported.
Option 2: Custom solution (Details below)
Requirement #1: Change of Cost Center
Detail: Customer requires to have an automatic update of the correspondent Org Unit when its Head of Position Cost Center is changed.
Solution: Intelligent Services Center (ISC) + Integration Center (IC)
An Intelligent Service Flow is created under the Event ‘Update/create Position’ to triggers the attribute update.
In the ISC a new flow with the IC ‘Pos to OM Attribute Sync (ISC) is assigned, without any specific rule, which means that it will be triggered every time that there is a position change (Image below):
Image 1 from Demo
The IC template is filtering only the ‘Managerial Positions’ which means that any other will never be taken into account for this update (Image below):
Image 2 from Demo
The template is using the ‘Position’ as the main entity – where we will look for the data to be updated in the Org Unit and as a destination it is using the entity ‘Department’ (customer’s Org Unit).
The update mapping will consider the Position Cost Center to the Org Unit Cost Center, so in case there is a change, the Position Cost Center will be updated into the Org Unit Cost Center which this position is the head.
Imagine 3 from Demo
Once the Managerial Position Cost Center is changed, it will automatic triggers the ISC event which will create the IC file and update the Org Unit with the same date as the Position change. Below example of how the change will look in each object:
Image 4 from Demo
Requirement #2: New Managerial Position not in line with OM structure
Detail: Customer requires to not allow a managerial position to be created not inline with the Parent Position Org Unit. Example: Org Unit A has the position 123 as the head. Org Unit B is created and a new managerial child position 567 is created under the 123, but once selecting the Org Unit you pick the Org Unit C, instead of B, the system should not allow you, since it is not following what was defined/created in terms of hierarchy for the Org Unit A and its position head.
Solution: A Business Rule can be created to prevent this incorrect assignment by triggering an error message. Additional to that, a custom table is daily updated with Position data, in order to allow the rule to check for the parent position information.
At the Position Object Level, the Business rule is assigned as onChange at the Org Unit Field (standard Department) level.
Image 5 from Demo
LOGIC
Is a managerial Position = true
Position Higher Level Position = true
Higher Level Position Org Unit is the Parent of the selected Org Unit = false
RESULT
Trigger a error message = ‘OM_POSSyncMessage’(below example from the system).
Image 6 from Demo
Requirement #3: Higher Level Position sync to Org Unit hierarchy
Detail: Customer requires to have an automatic update in the OM structure when a managerial position has its position head changed.
Example: Currently the Position Head C has the Position Head A as its parent (following OM structure). In case I change the parent from Position Head A to Position Head B, the OM structure must be changed to be in sync with the Position Hierarchy (below image).
Illustrated Image
Solution: Intelligent Services Center (ISC) + Integration Center (IC)
An Intelligent Service Flow is created under the Event ‘Update Position’ to triggers the attribute update.
In the ISC a new flow with the IC ‘Pos to OM Attribute Sync (ISC) is assigned, without any specific rule, which means that it will be triggered every time that there is a position change (Image below):
Image 7 from Demo
The IC template is filtering only the ‘Managerial Positions’ which means that any other will never be taken into account for this update (Image below):
Image 8 from Demo
The template is using the ‘Position’ as the main entity – where we will look for the data to be updated in the Org Unit and as a destination it is using the entity ‘Department’ (Customer Org Unit).
The update mapping will consider the Parent Position Org to be the new Parent Department of the Org Unit that will be updated.
Image 9 from Demo
Once the Parent Position is changed, it will automatic triggers the ISC event which will create the IC file and update the Org Unit with the same date as the Position change. Below example of how the change will look in each object:
Position 1234 is the Head of Org Unit G and Parent of the Position 60070007, which is head of Org Unit COM.
Image 10 from Demo
Image 11 from Demo
After changing the Parent Position from Position1234 to Position 60070021, which is Head of Org Unit COM-LC, the system will move the OM structure to be in sync with the Position hierarchy:
Image 12 from Demo
Image 13 from Demo
CONCLUSION
This blog post described alternatives on how customer could have EC OM Attributes and structure in sync with the Position attributes and hierarchy by triggering the Intelligent Services Center and running an integration to update the necessary information.
With the solution proposed we aim to avoid having to update the system manually, but of course that this proposal will depend on each customer requirement / specifications.
Looking forward to your comments and questions.
Great Blog Karen Perez!
In the scenarios where you used ISC and IC, you have used filter “Managerial Position?” only. Does this mean that your payload In IC will have all position who is Managerial and all will be updated with same value as they have before except for the one position that you have updated?
Once my object replication from SF to OM kicks in, this will generate a big payload with no data change, only last modified change.
Dear Jim,
No, the IC will be created only for the position that triggered the Intelligent Service, so it will not be a full list of all, but only that one. The filter is an additional because only Managerial Positions are head of units, so it helps as an additional filter.
I hope this helps!
Thank you.
Best Regards,
Karen Perez
Thanks Karen!!! :p
Hello Karen,
Great Blog!! Thank you.
I would like to add one more scenario to the list and a custom solution for it.
Scenario/Requirement:
As represented in below diagram, if the Person X leave the company and new person Z is hired & assignged position P. Then the Person Z should be updated in Org Unit A as Head of Unit.
Solution:
First part is described at SAP Help page -
https://help.sap.com/viewer/45372a91942140518d37370208c8525d/2011/en-US/c7f70b34b5ba4abcb673ab27e0199475.html
Add custom field in Department (org unit) object for "Head of Unit Position". It is one time effort, to fill this field for all existing org units.**
Create an integration in integration center that run every day. Check every employee and
If the employee is still selected after above two filter check, then his org units head needs to be updated.
Below screenshot show, calculated filter for this scenario:
Below screenshot shows the field mapping
Note: This will work only if the employee who is haed of orgunit is also assigned to same org unit. If that is not the case, you might need another custom field in job information object to org unit lead by this employee and use this field in integration center job.
Best Regard,
Amit Taur
This is great, Amit. Always good to see and share more use cases. Thanks for that!
Hi Karen,
Its a great blog altogether. In the scenario 2, you have used the custom MDF, can you post the details of the same. It would help to recreate the scenario.
Thanks,
Vijey
Dear Vijey,
Thank you for reaching out. The custom table is really simple, just store the info of the org data and the rule will look into it to cross check if the selection of the org unit is correct based on that table (below example). To update it daily I have created a IC running every night.
I Hope it helps!
Thank you.
Best Regards,
Karen Perez