Scheduled Job for LDAP User Import

KristyS · ‎07-10-2017

I have a scheduled job that pulls in my AD users to create and update users in ServiceNow. We have a requirement where users can request a name change through HR that would update the new name in ServiceNow. My current process is creating a secondary user record since the secondary record is different.

I assume that I would need to update my scheduled job to look for the existing record and update. My concern is what will happen or how will i update any current open tickets where the "caller" "requester_for" or "opened_by" fields has the existing user name. Will this make these records orphaned? How can I update these records with the new user name if I'm

How are other handling updating user records due to name changes?

Chuck Tomasi · ‎07-10-2017

Hi Kristy,

Since the reference fields for caller, requested for, etc. are pointing to a specific record in the sys_user table, the best idea is to update that record when you get the new information from LDAP. This is usually done with a coalesce field on the import that tells ServiceNow whether to update or insert records. In most cases, an employee ID or email address is used as a unique identifier from AD (or other LDAP source). If a name change is done, the same coalesce value is used and the old record gets the new name. No secondary record, no cross referencing issue, no data updates to potentially dozens or hundreds of existing records.

View solution in original post

Chuck Tomasi · ‎07-11-2017

For best performance, the coalesced fields should be indexed yes. For that reason, I usually wait until I get the transform map and mapped fields all settled out before I run the index. Too many indices on a table can actually have worse performance.

jhauptmann · ‎07-10-2017

Kristy,

One way to avoid creating duplicate records is to utilize the objectGUID attribute.

The objectGUID is a unique identifier for that user record in Active Directory as a sys_id is unique in SN. It will never change. You'll need to add a u_objectGUID field to the sys_users table. (This method is also useful for the sys_user_groups table in case those group names ever need to be updated.)

Add the objectGUID attribute to your import and map it to the u_objectGUID field you have created in the sys_users table and use that value to coalesce on in the transform map. This way the sAMAccountName and User ID values can be updated without having to create a new user record.

NOTE: The sAMAccountName will remain the query field and will be mapped to the UserID. The objectGUID is only used as a unique identifier for the coalesce in the transform map.