
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-10-2017 05:38 AM
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?
Solved! Go to Solution.
- Labels:
-
Scripting and Coding

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-10-2017 05:50 AM
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-10-2017 05:49 AM
If a user record is updated, all updates will cascade down to references to that record.
If you are coalescing on a unique value in the transform map for the LDAP import, name changes should automatically reflect in ServiceNow.
http://wiki.servicenow.com/index.php?title=Using_the_Coalesce_Field#gsc.tab=0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-10-2017 05:49 AM
We have the same problem and while we still correct it manually ( as I suspect you are ), we want to change things so that this doesn't happen in the first place.
The reason for the duplicate is rooted in the transform map for the LDAP import. Ours coalesces on the account name, which is based upon the user's last name. When this changes, the account name changes and hence a second servicenow user is created. I'm planning to switch the coalesce to "employee number" which should be more reliable and dependable. Look at the fields available in your LDAP and see which of them are both:
1. unique to the individual and
2. immutable for the duration of the time that the user is active. In other words, that it will not change.
In the meanwhile, we periodically check for duplicate accounts, which is harder than it sounds. When we find one, I set the account name of the "old, but correct" user record to the new value and delete the new, redundant user record. I usually update the name and email address too, but these will update in the next import cycle. The result is that the user retains their group membership and roles. They also maintain their history of incidents, changes and tasks.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-10-2017 05:50 AM
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-10-2017 06:51 AM
Chuck,
When we changed the coalesce on the transform map, we need to allow the database to be reindexed?
Kristy Stevens