user_name reuse

[cokemachine]

I'm a new ServiceNow admin and have inherited some LDAP integrations whereby population of our sys_user table is basically automated.     New on-boarded users into our company automatically have ServiceNow sys_user records created (on a daily basis).   Likewise, disabled users in Active Directory automatically cause the correlating ServiceNow user record to be set to "active = false".

I know deletion of records is generally discouraged in ServiceNow, but have found myself deleing a few user records on occasion as I see insert errors on the LDAP transform history screen for newly hired persons.

Here's the scenario:

1.   User is in the sys_user table with user_name of 1a63xz3 (for example).

2.   User is disabled in A.D., thereby causing the ServiceNow user profile to go "inactive".

3.   After 6 months or so, cleanup in A.D. causes that user's A.D. account to be deleted.

4.   The same user_name of 1a63xz3 is provisioned to a new on-boarded user in the company.

5.   Our LDAP import is unable to insert this new user because of the user_name duplication/conflict.

6.   I am forced to determine if I should delete the old user to allow the new user to be created.

I'd rather not continue deleting users (Step 6 above) to allow for the creation of the new user.     So far it hasn't been an issue because the old users haven't had any tickets or other important data affiliated with them (we've only been live on ServiceNow for one year), so I could delete them without much recourse.

But I know the day is coming where this scenario will appear and the "old user" has tickets or other important data linkages.

I'm looking for recommendations to allow me to keep the "old users" in the system, but avoid the insert conflict for the "new user".

I've tried renaming the user_name of the old user, such as "1a63xz3-old" but then I started receiving transform errors on that renamed account.

Maybe that's the route for me to go? but there's an additional step I'd need to take to allow my "disabled users" import to not try to re-update those accounts that end with "-old"?

Hoping others have solutions, not involving A.D. cleanup practices or A.D.-induced user_name naming conventions/practices (both outside of my control), to this scenario that would be of assistance...

Thanks!

[cokemachine · Accepted solution]

We were able to figure it out internally.     Because the out-of-the-box behavior of ServiceNow is to have the "unique" checkbox selected on the user_name field, this was causing our system to not insert the new person who had the same ID as an old inactive person.     Because our coalesce is based on guid's coming from other sources, we inactivated the "unique" checkbox on the user_name field to solve our issue.

[Chuck Tomasi]

Way to go Ross! Don't forget to mark your own response as correct so others can find it easily in the future and it gets removed from the Unanswered list.

[Harish27]

Hey,

We are having the exact same situation as what you have described above. Lets consider if we inactivate the unique checkbox and we have the below scenario.

Lets consider there is a user with user id as "abc123" , he left the company and the record is now inactive.

Now a new user joins the company with the same id as "abc123" , as per the setup a new record will be inserted in the system.

So now our user table has two user records with "abc123" as user ids.  Suppose when you lookup with user id in any of the scripts such as business rules, client scripts..etc System would be having dilemma which record to query right or it might apply a default query on created . This would return ambiguous results. 

I want to know how did you handle the above situation.

Thank You!

@Chuck Tomasi 

[James Roehling1]

I'm currently having the same issue. We're coalescing off the ObjectGUID from AD. But on the User table user_name unique is already false. We're currently running Orlando. Just curious if this ever came back up? Our current solution is to modify the UserID and Email and then the scheduled loads will pick it up the next day. Any suggestions?