Orefte I I 11 .Conff:
3 alio vltimo elogio , direclam vel fidcicommiftariam:
Overview
Human Resource Information System (HRIS) synchronization is the exchange of data between Employee Central (EC) and other SuccessFactors modules. It is a background quartz job that periodically looks for data that has been changed in EC and updates the legacy user tables with data from EC. The job itself can be configured to run on a schedule. For data updating using UI, the synchronization process is automatically triggered at the end of the update for current and past dated records.
Features
When HRIS sync is triggered?
There are the following ways to trigger HRIS sync:
● Real-time sync integration by UI operation
Most EC UI operations have integrated with HRIS sync such as new hire, MSS job change, personal info change, and so on to real-time sync the specific HRIS data from the UI to user directory tables.
For effective dated objects, only past day’s records / current day’s records will be synced by real-time sync integration. Future day’s records will be synced when the future day becomes current in running HRIS sync job.
● HRIS Sync Job
You can schedule a regular, for example, daily, HRIS sync job in Manage Scheduled Jobs in provision and then the HRIS sync job will run as scheduled.
● EC data import
When HRIS Element (Employee Central data) is imported, it will also trigger HRIS sync job run if there is at least one HRIS Sync Job configuration in Manage Scheduled Jobs and the status is Submitted. Only one HRIS sync job can run at a time. It means if there is one in-progress HRIS sync job, another HRIS sync job won't be triggered before the running HRIS sync completes.
How does an UI operation trigger HRIS sync?
The synch job just looks into the data and compares the data whether there are changes since the last run. Most EC UI operations have integrated with HRIS sync such as new hire, MSS job change, personal info change, etc. to real-time sync the specific HRIS data from the UI to user directory tables. This means, when an operation is done on the UI and there is some change, the change will be instantly synched back to legacy tables as soon as the UI change is committed.
For effective dated objects, only past day’s records or current day’s records will be synced by real-time sync integration. Future day’s records will be synced when the future day becomes current in running HRIS sync job.
How do you trigger HRIS sync by means of HRIS sync job?
You, as HRIS Sync Job User, can schedule a regular (i.e. daily) HRIS sync job in ‘Manage Scheduled Jobs’ in provision and then the HRIS sync job will run as scheduled. HRIS sync job is scheduled from provisioning under Company Settings “Manage Scheduled jobs“. This is done by the provisioning user. The job can be set up to run on a certain schedule, for example nightly, weekly.
How does an EC data import trigger HRIS sync?
When HRIS Element (Employee Central data) is imported, it will also trigger HRIS sync job run if there is at least one HRIS Sync Job configuration in ‘Manage Scheduled Jobs’ and the status is 'Submitted'. Only one HRIS sync job can run at a time. It means if there is one in-progress HRIS sync job, another HRIS sync job won't be triggered before the running HRIS sync completes.
Incremental Sync in HRIS Sync Job
In Employee Central (EC), there are two types of EC data, one type is non-effectively dated EC data such as phone, email, national ID card, social account, employment info. The other type is effective-dated data such as personal info, address, job info, and comp info.
All EC data no matter it's effective-dated data or non-effective dated data are incremental sync when running HRIS sync job. It means when the system runs HRIS sync job, only the records which have changed since last successfully running HRIS sync job and the future records which become current will be synced to user directory tables.
● But you can specify to run HRIS sync from a specific date to achieve full sync for special needs.
● The full-sync may have some negative impact on performance. Just use it for one-time sync to suit special needs.
HRIS Element and Fields Sync Logic
The system supports hard-coded HRIS Sync. It means that the system will sync some HRIS elements and HRIS fields into user directory tables without any configuration based on hard-coded rules such as syncing HRIS field: job-code in HRIS element: jobInfo to standard element: jobCode.
But you have also a flexible configurable framework to sync HRIS fields back to User Directory tables where you can specify HRIS fields to map to standard elements by configuring Succession Data Model.
HRIS Entity HRIS Element Comments
Supported Sync email emailInfo Business email has hard-coded sync
logic; other type of email hasn't hard-coded sync logic.
Yes Partly Full
phone phoneInfo Yes Yes Full
address homeAddress Yes No Incremental
HRIS Entity HRIS Element Comments
address corporateAddress used in location address (HRIS element: corporateAddress itself is in corporate data model.)
1) when employee changes location, the corporateAddress will be synched together with other jobInfo change;
2) when location info is changed, the corporateAddress will be synched when HRIS sync job runs.
Yes Yes incremental
personal personalInfo Name related field will be synched
from personalInfo. Yes Yes incremental
person personInfo Yes Yes incremental
job jobInfo Direct manager change is synched
when the job records are synched. Yes Yes incremental job
relationships jobRelationsInfo Only be available for ECT v2.0
(supported in 1107) No Yes incremental
employee
status jobInfo employee status only be available for
ect v2.0 (supported in 1107) No Yes incremental
comp compInfo hard-coded compInfo sync for ECT v2.0 is outdated now since the salary info is no longer stored in tables in ECT v2
Yes Yes incremental
employment employmentInfo Yes No full
social account imInfo Yes No full
national Id
Card nationalIdCard Yes No full
leave of
Absence leaveOfAbsence Yes No incremental
work eligibility workEligibilityInfo Yes No full
direct deposit directDeposit Yes No full
entities which supports sync with limitations
more entities Below entities theoretically support sync in a generic way, but may the generic way is not suitable and need some special handling to suit the real needs for sync in future if needed:
globalInfo;
support sync the below entity does not support sync:
EmpEmergencyContactInfoEO
No No
Clients don’t need to configure all these fields in Succession Data Model. The system will automatically sync the related HRIS data into user directory tables based on the above mapping.
Configurable sync mapping
The Succession Data Model includes HRIS sync mappings configuration in the end of data model, that is after view-template configuration.
Sample data is as below:
<hris-sync-mappings>
1. Only HRIS fields with visibility other than ”none” will be synced. HRIS fields with
visibility=”none” won’t be synced to user directory tables. The rule is applied to both hard-coded sync logic and configurable sync mapping.
2. <hris-sync-mappings> must be put after <view-template> definition in the Succession Data Model (SDM).
3. 0 or 1 <hris-sync-mappings> can be defined in a Succession Data Model.
4. Under <hris-sync-mappings>, you can define one or more <hris-element-ref>.
5. Under <hris-element-ref>, users can define one or more <hris-mapping>.
6. For each <hris-mapping>, you must define only one <hris-field-ref> and one <standard-element-ref> or one <user-info-record-key>.
Use <standard-element-ref> if the destination field of the sync mapping is a standard-element. Use
<user-info-record-key> to provide arbitrary key names that are stored as key-value-pair in the user directory.
The <user-info-record-key> is used by other modules that need additional information for integration and that get accessed through an application programming interface (API). The <user-info-record-key> that is stored in the user directory is accessible only through API; the key values are not displayed on any user interface.
You can enter any arbitrary string value for the <user-info-record-key> in the Succession Data Model, so it is not a refid. Whatever value you use here will be used as key in the user directory.
7. Entity-type attribute will be used for address, email, phone, and globalInfo to specify the type. For HRIS mapping configuration of address, email, phone, and globalInfo, entity-type is a mandatory attribute.
8. You can use the XML attribute date-format to sync dates from Employee Central to the Employee Profile.
The date-format allows you to also sync only parts of the date. This is relevant when customers want to show only parts of the birthday information without showing the age information, for example. To achieve this, you only sync the day and month fields, but not the year.
Note the following:
● You can only use the following date formats which are case-sensitive:
○ Year in 4 digits: yyyy
○ Month and year: MMM-yyyy
○ Month: MMM
○ Date and month: dd/MMM
● You can only sync from an HRIS field with the data type DATE to a standard-element with the data type STRING.
● The existing hard-coded syncing of an employee's date of birth from Employee Central (HRIS field date-of-birth) to the Employee Profile (standard-element dateOfBirth) is not affected by the date-format syncing. It will still sync the complete date.
9. You can sync data from Employee Central to userinfo-elements in Employee Profile following this syntax:
Userinfo-Element:
You choose this type of syncing when your customer uses more customer-specific fields than the 15 standard-element fields can cover, and wants these to be synced with Employee Central.
10. HRIS-element-ref, HRIS-field-ref, standard-element-ref must have valid refid 11. If HRIS element isn't defined in DM, but used in HRIS-sync-mappings, should fail.
12. If standard element isn't defined in DM, but used in HRIS-sync-mappings, it will fail.
13. Duplicated HRIS-element-ref refid definition will fail.
14. If fields fail to data type validation (such as mapping string to date), the Succession Data Model (SDM) can't be imported successfully (mapping anything to string is acceptable)
15. If corporateAddress has not been defined in corporate data model, but is used in <hris-sync-mappings>, the Succession Data Model fails to validation.
16. Below validation rule has been implemented for <hris-sync-mappings> when the Succession Data Model is imported.
● For a sync-mapping configuration in Succession Data Model, if the standard element field is a pick list and the EC HRIS field is also a pick list, these two pick lists must be the same. Configure the same pick list ID in Succession Data Model, the system will verify it when importing the Succession Data Model.
● For a sync-mapping configuration in the Succession Data Model, if the standard element field is a pick list, the EC HRIS field should be a pick list or a foundation object or a territory (country) object. Otherwise the data model can’t be imported due to validation failure.
Rewrite hard-coded sync mapping
But if you would like to re-write the hard-coded sync mapping, you can define it in the Succession Data Model.
For example, in the hard-coded sync mapping, EC data: jobInfo department to standard element: division. You can configure as follows to achieve this:
<hris-element-ref refid="jobInfo">
Pick list configuration for employee status and job relationship type
There are two pick lists that are very important for sync:
● Job Relationship types: For the HRIS element: jobRelationsInfo, the HRIS field: relationship-type must be defined as a pick list in data model. In order to sync the known relationship types correctly into users legacy tables, the below dedicated external code for widely known relationship types are defined. The sync logic will regard the external code for each known relationship type as fixed value. The system will run the different sync logic (HR manager/matrix manager /custom managers/second manager) based on the external code.
The following is the definition of external code for each known relationship type. It is fixed values in our system.
So if the client needs to support some or all of the known relationship type, they need to define the above external code for the pick list option.
● Relationship types:
External Code Employment Status in EC users_sys_valid flag in Legacy Table HR Manager
Second Manager Matrix Manager Additional Manager Custom Manager
● Employment status: Employment status needs to be defined as a pick list. Default pick list ID is employee-status if clients didn't define it explicitly in corporate data model. You can define the pick list ID for HRIS field
“emplStatus” in HRIS element “eventReason” in corporate data model. The external code of employment status is important to decide the employment status. Below is some mapping between external code and employment status:
External Code Employment Status in EC users_sys_valid flag in Legacy Table
Others than above will be regarded as inactive in legacy tables.
Special handling for fields syncing
● Logic about entity-type isPrimary
The below validation rule is used when importing Succession Data Model: For HRIS-mapping configuration of address, email or phone, entity-type is a mandatory attribute. If there are records with isPrimary=true for the specific entity type of email or phone for a specific person, the system will just sync the record; for example, for business email of user01, record 123: business email is primary, then just record 123 business email not other business email records for user01 will be synced.
If no records exist with isPrimary=true for the specific entity type of email or phone for a specific person, the system will sync all the records of the entity type, the last record will win; for example, for 3 business email records of user01, if none of the three business emails is primary, then the three business email records for user01 will be synched. isPrimary field is valid for email, phone, and nationalIdCard.
If there is EmpNationalIdCardEO record with isPrimary=true for a specific person, the system just sync the record with isPrimary=true.
If there is NO EmpNationalIdCardEO record with isPrimary=true for a specific person, the system just sync all the records. The last record will win.
● Country
If HRIS field is country field, sync country name to user directory tables.
● Phone number
If users configure phone-number in phoneInfo for <HRIS-sync-mappings>, 4 fields countryCode, areaCode, phoneNumber, extension will be merged into one value: (countryCode) areaCode phoneNumber’x’extension and sync to the mapped standard element, for example, (086) 021 21345501x0619.
● Pick list
If the EC HRIS field is a pick list but the standard element field isn’t a pick list, the pick list label will be synced to user directory tables.
If the EC HRIS fields is a pick list and the standard element field is also a pick list, the option ID will be synced to standard element field. (option ID > option ID)
If standard element is a picklist and HRIS field is not a picklist, then synchronization is not supported.
● Foundation objects
If foundation objects are enabled in provision, the FOs will be converted into FOName (FOExternalCode) and synced to user directory tables, for example, engineer dept (eng).
● Others
○ If standard element is gender and HRIS field is null, sync ‘ ’ into standard element: gender.
○ If HRIS field is Gender, convert gender into its legacy value.
○ If HRIS field is MaritalStatus, convert marital status into its legacy value.
○ Otherwise if HRIS field is null, null value will be synced back to user directory tables.
HRIS Full Sync
HRIS full sync can help you to use Employee Central (EC) data to sync to legacy tables which is desired when:
● You updated sync configuration or data model and want the new configuration is applied to all the data including the old data.
● You once used basic import to update data in legacy tables which causes inconsistent data between EC tables and legacy tables and you want to fix the inconsistent data by using EC data to replace the data in legacy tables.
● Other reason caused inconsistent data between EC tables and legacy tables and you want to fix the inconsistent data by using EC data to replace the data in legacy tables.
Before running HRIS full sync, please make sure:
● You really want to use EC data to replace data in legacy tables if any inconsistent data exists.
● The current configuration in data model is correct and the current sync behavior based on the configuration is as desired.
Steps for HRIS full sync to fix data
1. Please go to Provisioning Manage Scheduled Jobs .
2. Select “Create new job” and fill in below info in the “Create New Job” UI Select "HRIS sync" as Job type, for modified date since, please select "Specify a date" and then input a date which is before the system went-alive date such as '1/1/1991', select "Once" as occurrence and click "Create Job" but DON'T submit the job.
It will navigate you back to the Manage Scheduled Jobs list page
3. Make sure there is no in-progress HRIS sync job running in the system by checking Provisioning Monitor Jobs .
4. Go to Provisioning Manage Scheduled Jobs , and select the Run it Now from the drop down list of the defined HRIS sync job to trigger a full sync.
5. Please make sure the HRIS sync job is now running by checking the status in Provisioning Monitor Jobs .
6. After the HRIS sync job runs to complete (it takes time to run to complete depending on the current customer base), please check the data again to see whether any inconsistent data still exists.
If yes, please fire JIRA for further investigation.
A kind reminder: Please don't use basic import to directly update data in legacy tables to avoid inconsistent data between EC tables and legacy tables in future.