choice creates conflict Skip to main content
https://support.okta.com/help/answers?id=906f0000000i03wias&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fanswers
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Seth BaileySeth Bailey 

choice creates conflict

user was syncd to AD, the sync was removed so that the Okta username could be edited.  Once the AD account was re-imported Okta knows the correct account to assign it to.  However there is an error "This choice creates conflict.  with no logging as to what conflict or where.  Choosing instead to create a new user results in the same error, as does the an existing account I specify choice.

where can I view what the conflict is that Okta is hung up on?
Ransom MoatsRansom Moats (Okta, Inc.)
Hey Seth,

I can take a shot at the question; Can you elaberoate on the full scanario? How was the sync removed and re-added?
 
Jonny FordJonny Ford
We're seeing the same issue in our AD mastered environment, ever since the 2016.10 update. 
Disabling method: User moved out of okta synced OU, then at a later date moved back into an okta synced OU. 
Ransom MoatsRansom Moats (Okta, Inc.)
Can you try the following?

Once you move the user out of a Synced OU, try running an import, move the user back into a Synced OU, run a new import. Based on what your describing Okta is treating the user as a new acount which is why you see those conflicts (IE matching firstname,lastname, email addresss etc.)

Also, depending on the specifics of your IT process/business process there might be better way to handle AD account disabling so you wouldn't need to move users in and out of OUs to deactive the accounts in Okta. Support can definately help you , just open a new support case and include a link to this post. :)



 
Seth BaileySeth Bailey
Thanks for the help all, I ended up adding a case and support worked with me to resolve.

Turns out there is no logging and no way to know what was creating the conflict.  We ended up changing the current Okta account to XX-<account name>  and then running a full import.  the user was picked up and a new AD tied okta account was created with the proper name.  previously the AD account was an incorrect spelling which is why I had unhooked it from AD to edit the name.