Entities keep reprovisioning for Simple Join Resolution links

Note: the config has been reverted to use Connection-aware Join Resolution in order to meet project deliverables.

Hi Adrian

Is the employeeID for all the duplicates correctly set to the value in HRISID, and is this value reflected back into the AD Users adapter? If so, then this appears to be the behaviour expected of the simple join strategy when an ambiguous join is encountered. It's a known issue with the simple join strategy, stemming from the limitations that led to the creation of the connection-aware join strategy.

If you intend to keep using the simple join strategy, you'll need to remove the duplicate user entities, and ensure that that all user entities have a unique employeeID.

Is the employeeID for all the duplicates correctly set to the value in HRISID, and is this value reflected back into the AD Users adapter?

Yes, the AD employeeID is being (correctly) populated in the new entities from the locker HRISID value.

If so, then this appears to be the behaviour expected of the simple join strategy when an ambiguous join is encountered. It's a known issue with the simple join strategy, stemming from the limitations that led to the creation of the connection-aware join strategy.

If the simple join strategy causes UNIFYBroker to create an additional target entity on every Baseline Sync whenever an ambiguous join criteria is found (i.e. at least two match entities already exist) then I can't see how it would have any sensible use.  A more useful approach would be to not create any additional target entity at all, if two or more matching entities already exist.

Hi Adrian,

It's most likely that the simple join strategy doesn't have any sensible use. It was created for initial rudimentary use cases, which have since been superseded and resulted in the creation of the connection-aware join strategy. 

In fact, for the next version of UNIFYBroker/Plus that is currently underway, we're recommending that the Connection-Aware be used as default and the Simple Join strategy is only around for legacy support. 

I'd recommend for now that you default to using the Connection-Aware strategy. If you have any specific use cases that aren't covered by the connection aware one, or that you feel the simple join strategy services better, please let us know so we can ensure the connection-aware strategy is as suitable as possible.

Thanks Matt.

Here's the sort of problem I'm seeing.  Customer has an existing AD user with employeeID 12345, but a new duplicate HR record is inadvertently created in HR for the same person, with employeeID 5555.  The user wants their old AD account back, so the customer removes the employeeID value from the newly-minted "5555" account in AD and puts it onto the old "12345" account instead.

With Connection-Aware, UNIFYBroker retains the old join and either keeps managing the wrong AD user account, or sometimes (depending on the specifics of the changes to employeeID field values that the customer has made) sees the account with the corrected employeeID as a duplicate and starts erroring out.

With Simple, I was hoping UNIFYBroker wouldn't retain the old joins, and would instead re-evaluate the criteria and join the correct locker and adapater entities.  It's a shame that's not the case.

There are other similar situations, but essentially the core issue is that after the customer remediates incorrect data UNIFYBroker ends up erroring and has to be manually remediated after investigation to try to understand what went wrong.

In an ideal world the connector could use the employeeID as its key and the join would therefore be associated with the employeeID value, but unfortunately this isn't feasible because we need all the AD users loaded into the connector in order to do unique identifier generation, and many of those users are unmanaged and have blank (and therefore duplicate) employeeID values.  After trying many options I've determined that the least problematical path is to use objectGuid as the connector key.

Cheers,
A.