SuccessFactors Spoke rehire employees data

vishalgrover
Tera Contributor

‎06-10-2025 02:14 AM

SuccessFactors Spoke
 

We are using HRSD Integration with SuccessFactors for integration with SuccessFactors to populate HR Profiles in ServiceNow. This updates the users correctly but any users that is a rehired in Successfactors doesn't have a field called "logon_user_id". This field is mapped in ServiceNow to populate the integration_user_id. since this field is blank in the data coming from SuccessFactors for rehires, this doesn't update the rehires correctly in ServiceNow.

ServiceNow is not supporting us on this case by saying that the integration is working based on the data coming from SuccessFactor and if we need any support we have to use their professional services and pay for the support.

I thought I will add the below code in the script but that has "protection policy" applied.

// For Re-hire Employees the logon_user_id attribute will not be present in the XML Payload so, extracting the user_id based on the employment information.
            var integration_userid = xmlDoc.getNodeText('/sfobject/person/logon_user_id');
            if (integration_userid == '' || integration_userid == null || integration_userid == undefined) {
                integration_userid = this.getUserIDForReHire(xmlDoc);
                this.outputJSON.integration_user_id = integration_userid;
            } else {
                this.outputJSON.integration_user_id = xmlDoc.getNodeText('/sfobject/person/logon_user_id');
            }
Wanted to check if anyone else have come across this challenge as this "logon_user_id" field is SuccessFactors restriction that other companies would be facing.

Any help would be appreciated.

Thanks
0 Helpfuls
  • 320 Views
1 REPLY 1

Wessel van Enk
Tera Guru
Tera Guru

‎06-10-2025 11:19 PM

Hi @vishalgrover ,

I had a similar scenario during an implementation a few years back. At the time we used the Employee number as unique identifier to match the user, but with re-hire, they might get a new employee number, so that didn't always work. We then did another check on inactive profiles with the provided information from SF (birthdate, firstname, lastname etc.) and then update the record if we found a user. 

Still it's not 100% safe, but if there are more people with the same startdate, birthdate, firstname and lastname it get's tricky anyways. 

0 Helpfuls