Correlate Multiple Accounts from Same HRIS Source to Single Identity Object in IDN

I’m trying to define the lifecycle state for multiple accounts/records with the same employee ID, belonging to the same person, where the records/accounts have different statuses of active and inactive. I’m using the employeenumber as the IDN uid. As such, IDN can only create a single identity in this case. What happens though, is that the different account statuses cause associated target application accounts/links to flip back and forth from active to inactive; based on the scheduled aggregation jobs, and what the connector processes from the source.

I am running into an issue where it appears not all records are being aggregated.


  • ID Profile is configured to use employeeNumber from HRIS (UltiPro/UKG Web Services) as IDN UID
  • Source: UKG Web Services. Account ID is UKGEmployeeID
  • Correlation for UKG Web Services source uses: UKGEmployeeID, employee Number, alternate email, and work email.

I expect that a single ID is created using the employee Number.
I expect that aggregation aggregates all accounts by the UKGEmployeeID
I expect that if there are multiple records/accounts, with the same employee number, but different UKGEmployeeID that these 2 records/accounts are correlated to the same identity

This is not happening and I need assistance to resolve this.

We realized correlation was not functioning as we expected after we turned on inactive life cycle state.

I need assistance to resolving why multiple accounts from the same source belonging to the same person are not correlating to the same identity.

With the above resolved, I can properly determine the life cycle state of the identity

I have a transform that can look at the identity object, determine that there are multiple accounts from the same source, pick the account that is active, and use the active account state to determine the lifecycle.

I’ve never worked specifically with UKG, but believe the concept is the same across various connectors. My understanding is that IDN “stores” the last account record it finds, so if the data isn’t sorted (i.e. like a flat file would be) and the records come back in different order you would see the behavior described. If it’s possible to set some kind of “order by” criteria in the connector or include this as a parameter in the web service connector API call, this is likely the best solution for multiple records.

The BIG question though is understanding why there are multiple records for a single person. Most likely something time based (future termination, promotion, etc.) and excluding these may also resolve the problem.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.