- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-08-2016 11:25 AM
The issue I'm describing is mostly from poor business policy but I won't get into the politics of it. I know it's bad practice.
We have a policy to allow usernames to be changed in AD. They use user ID markers to identify them as consultant or a FTE. When a conversion occurs, they change the user ID. This causes issues in ServiceNow because whenever the username is changed in AD, a new account is created in ServiceNow for the same person. What I'm looking for are for any solutions that would prevent this on the ServiceNow side. I've thought about coalescing on email address as well however that address may change in certain situations (like marriages and divorces). We're currently coalescing on user ID. This also occurs when a username is misspelled.
Any ideas that could prevent this from the SN side other than policy changes?
Solved! Go to Solution.
- Labels:
-
Service Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-07-2016 03:21 PM
I'm answering my own question if anyone else needs a straight forward solution.
It seems that the addition of GUID information via LDAP is the way to go. This is unique to each user regardless of the information displayed in any of the standard fields. Normally this wouldn't be an issue however because of our lack of policy around User ID changes, this is necessary.
As for added enforcement, a business rule was added to prevent the insertion of the same user ID in the case anyone decides to manually add a user account in ServiceNow.
Cleanup of duplicate users was still necessary however from the point you coalesce on the GUID, you won't run into issues with ID changes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-08-2016 11:39 AM
You have to have a particular field as coalesce which will never change. If you want to check first for user id and then for email (eg. Check if user id matches if not then check if the email matches) then you will have to transfer the whole transform map fields in script(which is a very tedious task).
Kind regards,
Sourabh D
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-08-2016 12:03 PM
The email address is an example as the chances of that changing is lower even if the username is changed. But the email address could change as well meaning both could change in one edit. That would cause another account to be created.
I don't think there's any other field that would apply to all employees that wouldn't change. We have employee numbers however not everyone has one.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-08-2016 01:51 PM
Is the change predictable?
IE, is the user name cont12345 and then emp12345?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-08-2016 01:58 PM
It is somewhat predictable, if not predictable. They append -v or -p for non-FTE and then remove them when they are FTE or vice versa. For example, jsmith-v to jsmith.
