Symptom
This article explains how HRIS Sync works for Phone Info in EC.
Environment
SAP SuccessFactors Employee Central
Resolution
Hard-Coded Sync FAQ
The synchronization of phoneInfo data to EP works as such:
- Currently there are 5 main fields delivered with the phoneInfo element as detailed in below table: phone-type allows you to define the type of phone number being stored, where the other 4 fields allow you to capture the phone number values separately (country-code, area-code, etc).
- The system will merge the 4 fields ( country-code+ area-code + phone-number+extension) always and sync this single combined value from EC, into field in EP as per hard-coded sync mapping logic.
- The custom sync mapping while the 3 fields country-code, area-code, extension are enabled in instance will not change the 4 fields combined format. Custom sync mapping will only change(override) the target field but it will not change the format.
- The only way to sync only phone-number without area-code, country-code and extension is to disable these fields.
HRIS Element | EC Fields |
phoneInfo |
|
- As per the above table, the system will take data from all 4 strings and merge it into 1 string, and then synchronize that 1 string to a field in EP. For example:
country-code | area-code | phone-number | extension |
+44 | (0)208 | 1234567 | x415 |
- The output to the EP field would be: +44 (0)208 123 4567 x415
How does the system know what Phone Types to map to the different phone fields in EP?
- The synchronization is hard coded based on the pre-delivered picklist "ecPhoneType" assigned to the "phone-type" field in phoneInfo elements configuration.
- What are the hard-coded/standard sync mappings? The system (by default) will map the data using the phone type, as per the below pre-delivered ecPhoneType picklist, we map using the external_code of the picklist value:
Hard-Coded Sync Mappings between EC (based on external_code of ecPhoneType picklist) and EP fields
ecPhoneType Picklist External Code | EP Field |
B | businessPhone |
C | cellPhone |
F | fax |
H | homePhone |
Custom Sync Mappings for phoneInfo (overriding the hard-coded mappings)
- If you want to override the Hard-Coded Sync Mappings with custom mappings, this is possible, but it is advised that if you want to customize one phone mapping you should customize all mappings.
- For example, if you want to just use 1 phoneType in phoneInfo and not all 4 phoneTypes (as shown in above table) to store the phone number, then specify the sync mapping for each of the different phone types you are syncing to EP. This means specifying entity type for each mappings in phoneInfo is mandatory.
- This means, if you are happy to use the Hard-Coded mappings, then do not define any hris-sync-mappings for phoneInfo in the Succession Data Model.
- Else, if you do want to customize, make sure each of the phone-types is mapped where we sync the "phone-number" field from EC to EP, and the system knows which field to map to based on the external_code of the picklist. Please note if this is not done, the hard coded mappings will not be respected and you may see data not synced or unexpected data synced which may expose personal information you do not wish to be mapped.
- Below is example of hard-coded sync mapping. ( Note: this is just a view of how the hard-coded sync mapping exists, if you use below configuration it means custom mapping even though the source and target fields match with the source field as per hard-coded sync mapping logic.)
- Use of custom sync mapping can vary as per business requirement. Some examples: a) you can swap the target fields, business phone to personalPhone; b) you can sync to one phone type to one more custom field, business phone hard-coded mapping to businessPhone and custom mapping to custom01 field as well.
<hris-sync-mappings>
<hris-element-ref refid="phoneInfo">
<hris-mapping entity-type="B" >
<hris-field-ref refid="phone-number"/>
<standard-element-ref refid="businessPhone"/>
</hris-mapping>
<hris-mapping entity-type="C" >
<hris-field-ref refid="phone-number"/>
<standard-element-ref refid="cellPhone"/>
</hris-mapping>
<hris-mapping entity-type="F" >
<hris-field-ref refid="phone-number"/>
<standard-element-ref refid="fax"/>
</hris-mapping>
<hris-mapping entity-type="H" >
<hris-field-ref refid="phone-number"/>
<standard-element-ref refid="homePhone"/>
</hris-mapping>
</hris-element-ref>
You could also map the data to another string field (as the data is sent as a string) for example:
<hris-sync-mappings>
<hris-element-ref refid="phoneInfo">
<hris-mapping entity-type="B" >
<hris-field-ref refid="phone-number"/>
<standard-element-ref refid="custom01"/>
</hris-mapping>
<hris-mapping entity-type="C" >
<hris-field-ref refid="phone-number"/>
<standard-element-ref refid="custom02"/>
</hris-mapping>
<hris-mapping entity-type="F" >
<hris-field-ref refid="phone-number"/>
<standard-element-ref refid="custom03"/>
</hris-mapping>
<hris-mapping entity-type="H" >
<hris-field-ref refid="phone-number"/>
<userinfo-element-ref refid="cust_UserInfoString1"/>
</hris-mapping>
</hris-element-ref>
Important:
- If you implement the above Custom Sync Mappings after having already used the Hard-Coded mappings for a period of time you need to also perform a Full Purge import of Phone Info data to correct the database and ensure the correct data is synchronized to EP.
- The caveat here is, if you were using the Hard-Coded mappings, the fields country-code, area-code, extension, would have been used and would have data in them.
- Although you would have disabled country-code, area-code, extension via SDM or BCUI, the fields still have data in the Database, and they would still be synchronized.
- You need to do the Phone Info Full Purge import to both fix the EC phone data and then to also re-sync all the EC phone numbers to EP.
Special Handling for homeAddress/emailInfo/phoneInfo - "entity-type" Vs "isPrimary"
A validation is used when importing the Succession Data Model: For hris-mapping configuration of nationalIdCard/emailInfo/phoneInfo, "entity-type" is a mandatory attribute.
Sync Logic:
- If there are records for the specific entity types, nationalIdCard/emailInfo/phoneInfo, and the record "isPrimary" flag is "true", the system will sync that record.
- For example: User01 has 3x Business Email records all with an external_code of "B". the system will use "isPrimary" to determine which one of the 3 should be synchronized.
- If there are no records for the specific entity types, nationalIdCard/emailInfo/phoneInfo, where the record "isPrimary" flag is "true", the system will sync the "last record".
- For example: User01 has 3x Business Email records all with an external_code of "B" and all have "isPrimary=false", the system will sync the "last record" (the last record will win).
- In general, isPrimary field is a valid flag for nationalIdCard/emailInfo/phoneInfo elements.
- If (for example) there is a nationalIdCard record with "isPrimary=true" for a specific person, the system will sync the record with "isPrimary=true".
- If there is NO "nationalIdCard" record with "isPrimary=true" for a specific person, the system will sync all the records. The system will sync the "last record" (the last record will win).
See Also
2172427 - HRIS Sync - Data Synchronization From EC to EP - Hard Coded Sync Mappings
Keywords
Phone Info, Phone Information, phoneInfo, HRIS, Sync, Mapping, HRIS Sync, Configuration, Troubleshooting, FAQ, Best Practices, Common Issues , KBA , LOD-SF-EC-HRS , HRIS Sync , LOD-SF-EC-PER-PHN , Phone Info - Config, Rules, RBP, UI , Problem