Error when contingent worker is hired as permanent employee (SF-AD integration)

[inepre1]

Hello,

We are facing an issue with one of our new hires in the ActiveDirectory-SuccessFactors integration. 

Following message is shown in AD: 

Failure Description

An entry cannot not be provisioned in this target: SuccessFactors. The entry is 12345. The reason the entry cannot be provisioned is internal to that application. An example of why an entry cannot be provisioned is a user with a given public identifier, such as an email address, having previously exercised a regulatory right to be removed from the application.
ReportableIdentifier
emp.emp@company.com

The username of the previous employment was the username AD is trying to update now. emp.emp@company.com

The username of the new employment was a number sequence, like 12345. 

AD tried to update the new employment with the old username which was not possible since the old username was taken. 

From past experience, I have seen that the old username is automatically updated to username_INACT. Why does this not happen in this case? 

Hope someone knows the answer to this. I thought that was standard behavior. 

Thanks!

[ManishJaiswal]

Hi 

When we rehire with new employment the new employee will not be able to use old the user name so there is a workaround advised by SAP where you enable the feature to login with old username even though having new username with new employment during rehire as described in kba 2677136 & SAP Article for this fix

Please review and check if it can resolve issue for your case.

Thanks

Manish

[jackoneill23]

Hi, could it be that when you were seeing the old record's username updated to username_INACT in the past (e.g. if it was in a previous company), that this was something that someone did manually, or you had some kind of custom configuration to do this? 

In our setup, when we have colleagues who go from contingent worker to regular employee, and we want to use the same account details, we need to go into Manage Login Accounts and scramble the username on the contingent worker record (we do employeeID@company.com). That way, AD can send back the username on the new record without it being blocked due to being a duplicate.

[inepre1]

Ok, thanks Jack. That's helpful. I am sure it was not added manually, but it must have been a custom job from integration center or something similar. We will stick to the some process as you are following for now. It's not that often we are facing this issue.