In this article we will raise a few points to consider when you map foundational data from SuccessFactors Employee Central to SmartRecruiters.
Below is a standard foundation structure in Employee Central, all the objects are linked to each other and there is a custom level between division and department. This is a fairly common set up.
The job structure has two levels on top of the job code, again a common structure.
SmartRecruiters has three standard fields, Country, Brand and Department. You can not map data to the standard field and we would advise that you use these for recruitment and not to repurpose them with EC data. If you are considering mapping the Department Foundational Object to an organizational field in SmartRecruiters then you will need to rename the field in SmartRecruiters as the Department label is already used. Finally SmartRecruiters 1:1 parent child relationships.
SmartRecruiters has 22 organizational field limits. A common misconception is to think that all the foundation objects in Employee Central have to map to these 22 fields and thus customers are limited. This is an incorrect assumption.
Rather than thinking as them as organizational data fields like we do in Employee Central, think of them as fields that allow you to ‘organize’ logic in SmartRecruiters. For example, if you would like Legal Entity to drive logic in SmartRecruiters then it needs to be an organizational field. However, if Division is not needed for logic then it can be a job field and not an organizational field. You can split out different objects to org and job fields dependent on your business needs.
Furthermore, you must think outside of your Employee Central Foundational Structure. In Employee Central we have field called ‘Employee Class’ and this is typically on the position, and it can be a picklist or an object. If you want Employee Class value to drive logic in SmartRecruiters then it needs to be an organization field not a job field.
As a result you could end up something like this.
