Active Directory and Locations

[buckhill2]

Good Afternoon!

I have been successful in setting up Contract Management and Vendors within ServiceNow.   Except now.   I need to enter in all of our real estate leases and ownership documents within Contract Management for all of our 71 locations.   We have locations in Latin America, Caribbean and Domestically.   Our locations are currently populated from Active Directory with each user.   The problem is each user is listed as a general location, e.g. Trinidad & Tobago.   But we have several locations within Trinidad that each have their own lease and a location in Tobago with the same.   I need the locations within ServiceNow broken down farther than what AD has them so I can set-up all of the leases.

Obviously this will be a benefit as we start doing asset management and other items with it.

The Hierarchy I would like is

-DOMESTIC

  -Texas

      -Austin

          -Street Address

-LATAM

  -Columbia

      -Bogota

          -Street Address

etc...

I have set this up manually in our Development instance utilizing Parent record, but in Production I have the Active Directory question as I asked above.   Has anyone else had this type of set-up needed?   Or something similar and how did you do it?   Do we need to change every user in Active Directory or is there a way to do a hybrid solution?   Does someone have a better idea?

Any help is greatly appreciated.

Jeff

[Aaron_Braun]

Do you have any type of location codes that are used internally (ex. Trinidad1, Trinidad2, Trinidad3) to segregate the three offices? If so is that data populating on AD anywhere? You could load all your location information on your Locations (cmn_location) table and use that as your reference point. Then you can setup the custom location codes on the location table and use that as a reference value when you import the user records from AD.

Loose example of that transform item:

AD User Location --> Location Table, Reference: u_custom_location_code

[Brian Dailey1]

Hi Jeff,

You're already going the parent (hierarchy) route, which is what I would've recommended.   As for the updating from AD, you could simply change the script on your transform map (for the LDAP import, or however you are sourcing the AD data) to not overwrite a user's Location value with that from AD if there is already an existing value in that field on the SN profile.

This would allow you to import new users and have it populate their general location, which you would later have to update to a more specific child location, but the import wouldn't wipe out your changes every night.

If you have workflows setup for user management in AD (i.e., user account changes getting pushed out to AD via orchestration, etc.), then you could also use this to populate the new child locations into AD.

Thanks,

-Brian

Edit:   You could also have your import/transform script perform a hierarchy lookup to validate that the Parent location coming in frmo AD really does apply to the child location on the user's record.   In this way, you could at least catch when a user gets moved to a different parent location.   When the parent/child don't match, it could kick-off an update process.

[Deepak Ingale1]

Hi Jeff.

LDAP Integration - Load Locations and Departments along with user records.

I had written one article to load "locations" in parent child hierarchy while loading user details from LDAP.

Hope this helps you to build your logic too.