Sm-mapping is a configuration in the Candidate Profile template which allows synchronization of data between the Candidate Profile and the Employee Profile. This requires first of all a correct configuration - When creating sm-mapping entries, the Implementation Partner should make sure that the mapped fields have the same field type — for example, text to text and picklist to picklist. Also both fields have to be defined with the same picklist id when sm-mapping picklist fields. The field id itself does not need to match between templates in order to map successfully, unless it concerns a background element.
Typical sm-mapping related issues:
SuccessFactors Recruiting Management - All versions
The sm-mapping is complex in the configuration and the behaviour for sm-mapped fields may differ when updating the profiles in a different way and when using privacy options.
Issue 1: Candidate Profile and Employee Profile are not synchronized
The fields won't map between profiles, if the are not configured correctly. If you are before Go-live please verify with the Implementation partner to review the fields in question, if they are configured correctly. If you are after the go-live you can ask Cloud Product Support to verify, if the configuration allows the synchronization between both profiles.
Issue 2: The candidate search doesn't work for sm-mapped fields
This could be also caused by a misconfiguration. First of all, sm-mapping requires at least read permissions in the database for all users to the sm-mapped fields. If the permissions are not available, the search will return no results regardless of the data stored in the database. Secondly, we need to understand how the Candidate Search works in regards to the Privacy Options (you can verify with the Cloud Product Support, what is your current configuration).
1) Privacy Options are disabled for Internal candidates: The Candidate search will search for the informaion in the Employee Profile and Candidate Profile database
2) Privacy Options are enabled for Internal candidates: The Candidate search will search for information in the Caniddate Profile database only. The data won't be pulled from the Employee Profile database.
How can it come that the data is not available in the Candidate Profile database tables?
In the Candidate Profile page the data is displayed from two difference sources:
1. Data from the CP table
2. Data from the EP table if there is an sm-mapping
Manage Users in Admin Tools
When updating data of employees via Manage Users in Admin Tools there is actually no records creation on the CP table even though sm-mapping
Live Profile import
When a live profile import for background elements in the EP is performed there is actually no records creation on the CP table even if we have the sm-mapping.
Triggers for creating records in the CP table
There are three ways to trigger the physical creation of a background element record in the CP table.
If a field / a background element is edited or created in the CP user interface.
Of course the same element will be visible in the EP user interface if there is a sm-mapping configured.
If a field / a background element is edited or created in the EP user interface, this will create an actual record in the CP table if the sm-mapping is configured.
So in this case the same record is displayed in EP and CP even if there was a modification on the EP.
If an internal candidate profile is inactive then in one of the three conditions we have the trigger of the creation of the candidate profile itself:
- If the My Profile subtab of Career tab is displayed
- If the Careers Tile in the home page is displayed
If a Candidate search is performed and the inactive candidate is found (*)
Together with the creation of the Candidate Profile itself, also the fields with the EP are physically created in the CP table
If a field / background element is edited or created using an import job.
Issue 3: When hiring a candidate through Manage Pending Hires there appears an error message (at the last step of EC-RCM integration)
When hiring a candidate through EC the system will try to syncronize the new Employee Profile with the Candidate Profile based on sm-mapping. If the sm-mapping is not configured correctly, an error message may appear in the last step of hiring a candidate through Manage Pending Hires.
Issue 4: sm-mapped data is not reportable from Recruiting V2 domain
In ad-hoc report only data stored in the CP table are displayed. Therefore in ad-hoc report records that are only available on EP tables are not visible.
Issue 5: A Recruiter cannot edit an sm-mapped field in an internal Candidate Profile
This is most likely caused by missing write permissions in the Succession Data Model. If a field is sm-mapped, the permissions in Candidate Profile are ignored and permissions in Succession Data Model apply. If there is a permission set up in the Candidate Profile allowing Recruiters from a Dynamic Group to edit the Candidate Profiles, a Recruiter will be able to edit a field on an internal Candidate Profile under these circumstances:
a) The permission for the Dynamic Group allows to edit fields for Internal Candidates (please verify the source in the permission block)
b) The Recruiter is set up in the Dynamic Group and the user who created the Dynamic Group is active in the system
c) The Recruiter has write permissions to the relevant field in the Succession Data Model (the Recruiter can edit the field on the Employee Profile of the relevant Internal Candidate)
Error while updating updateCandBackgroundWithSuccession for candidate, sm-mapping, , KBA , LOD-SF-RCM-ADM , Admin Center, RBP, Permissions and Settings , How To