Is your feature request related to a problem? Please describe.
Currently, if an ExternalId mismatches, a fallback branch checks for an email address match, if a match is found the user is updated with the relevant ExternalId.
A better behavior would be:
if an ExternalId mismatches, check for an email address match, if a match is found and the ExternalId is not set/set to nul, then update with the relevant ExternalId. This allows for matching existing locally created users, on first sync via ssosync. This is an important adoption route.
if an ExternalId mismatches, check for an email address match, if a match is found and the ExternalId has been set, then the existing user should be deleted and a new user created. When this situation occurs an Error should be logged.
Important to execute remove before create
Describe alternatives you've considered
Retaining the current behavior, and would be less disruptive but would in situations where and email address is being re-assigned or recycled (itself an anti-pattern), a different user could 'inherit' permission previously granted to the original user of the email address.
Additional context
Add any other context or screenshots about the feature request here.
Is your feature request related to a problem? Please describe.
Currently, if an ExternalId mismatches, a fallback branch checks for an email address match, if a match is found the user is updated with the relevant ExternalId.
A better behavior would be:
if an ExternalId mismatches, check for an email address match, if a match is found and the ExternalId is not set/set to nul, then update with the relevant ExternalId. This allows for matching existing locally created users, on first sync via ssosync. This is an important adoption route.
if an ExternalId mismatches, check for an email address match, if a match is found and the ExternalId has been set, then the existing user should be deleted and a new user created. When this situation occurs an Error should be logged.
Important to execute remove before create
Describe alternatives you've considered
Retaining the current behavior, and would be less disruptive but would in situations where and email address is being re-assigned or recycled (itself an anti-pattern), a different user could 'inherit' permission previously granted to the original user of the email address.
Additional context
Add any other context or screenshots about the feature request here.