Need to use the Person ID External as the account ID instead of using PersonID in Successfactors Connector

We are using Successfactors Connector, and due to client requirements, the Account ID cannot be the Person ID; it must be the external Person ID, as the latter acts as the primary key for Users (which in our case is where the employees are retrieved from) in SuccessFactors. I know that Sailpoint recommends not changing the Account ID to avoid potential errors, since the connector essentially targets

odata/v2//User?$format=json
&$select=personKeyNav/personId,userId,username,firstName,lastName,status,email,defaultFullName,hireDate
&$expand=personKeyNav
&$filter=personKeyNav/personId eq ‘1111’ and status in ‘t’,‘f’,‘e’,‘d’

and uses the Person ID as a filter, without allowing it to be changed. But what if it’s necessary to use a different attribute to prevent duplicate identities from being generated each time a user is assigned a new Person ID? How can we use the external person ID as the account ID? I think this restriction is too restrictive given common usage and the lack of a way to fully configure the account ID, or at least to configure it using two attributes that identify the employee.

Any ideas on how to solve this problem?

Thanks!

First, can you clarify which connector you are using? I assume it’s the basic one called SuccessFactors, but there are 4 choices that come up when creating an application. This will help with clarity.

As I understand it, the situation that your client is facing is that they create new users (Person IDs) in SuccessFactors for the same individual, and that the Person External ID is the Authoritative ID of the user. The situation you are trying to resolve is that if you have a user Tom with PersonID=123 and PersonExternalID=ABD, and that Tom may have the old PersonID removed and a new PersonID created, so that the data retrieved is now PersonID=987 and PersonExternalID=123. Is that a correct representation of the situation? Does the old ID go away completely, or is it just disabled?

I think in this case, I would look at setting the Correlation Configuration/Rules to use the PersonExternalID and match that to an IdentityAttribute. The default is set for PersonId and PrimaryEmailAddress (As shown below)

You should be able to change the first Correlation to be the Person External ID instead (As shown below) and it will use that when correlating the accounts.

This will not change any of the information displayed or the usage of the PersonID, but it will maintain the correlation of the correct account. It will likely show up under the hood as a newly created account, and the other account will likely show as deleted, since technically they are new accounts in SF, just for the same person. I would test this out to make sure that it works for you.

Otherwise, I am not sure how you would handle that and you may need to engage PS to see what your options are.