- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-19-2014 10:19 AM
For a little background. On my location table I have a location number that is pulled in from Active directory as well as the location name. I went ahead and created a new field called location name in which I am pulling both the number + name into the new field (business rule: current.u_location_name = current.u_location_code + ' - ' + current.name;)
What I am looking to do is to make it so on my incident/ service requests "location" field will display the location name field instead of just the location number. When i go ahead and change the new field to be the display field= true and change the other to be false it works fine and displays correctly. Though the issue is when AD does a re-sync overnight its creating hundreds of blank records (due to what only i can assume is LDAP being confused and hence adding a blank record for every location number)
I would like to keep 'location' as the field on my incident/ request forms so people have the ability to still search for a location using the magnifying glass/ also have the quick hover display for other location details. (screenshot of the two fields attached)
I was thinking maybe a dictionary override would allow me to display the other fields value instead but am unfamiliar with them and my attempts have not worked thus far.
If anyone can give me some guidance it would be appreciated.
Steve
Solved! Go to Solution.
- Labels:
-
Service Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2014 09:10 AM
Ok,
So, we are using a principle "We won't create/update automatically the locations from the AD" (we could and if we would, the message from Christopher Plunkett will help you)
What we want to do is:
1) I have a "location code" (named Company into my AD and u_company in my source table here in ServiceNow)
2) I want to find the right location from the location table (because I suppose the u_location_code is a reference field to the cmn_location table)
OR, on my cmn_location table, the "display" field isn't the u_location_code anymore but "current.u_location_name":
1) I want to use this "current.u_location_name" as the display name for users
2) I want to use the "current.u_location_code" for my technical import of users (from the AD)
The solution is quite simple, we will "configure" the field map rule
1) On your screenshot, please ckick on "u_company" to open the corresponding "field map"
2) On the right column, you should have a "referenced value field name", by default this field is empty and the transform map will use the display value (something we can't do anymore), so let's fulfill the field with the information we have at our disposal from the AD, the "location code"
==> Little warning, don't forget to use the "database name of the column"
Feel free to tell if you have troubles to understand the difference between the "display" column for user and this "referenced value field name"
http://wiki.servicenow.com/index.php?title=Creating_New_Transform_Maps#Creating_a_Field_Map: Putting that here btw
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2014 06:04 AM
Ok, I forget to tell something
the "referenced value field name" is already on the "referenced table" so we have to put the real name being there. (I hope servicenow will one day replace this string field by a choice with a lookup on the table)
So your "referenced value field name" is "u_location_code" because it's the name of the field of the "location code" on the cmn_location table
If you want, you have the example with the wiki page I gave you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2014 09:11 AM
That worked. Though I noticed that all my location fields are now showing as blank on my past incidents and requests. Is there a way to just get the location field to stay with the current locations that were entered and just update to the new display field? Without having to go into each and every incident/request to do an update to get it to properly show up?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2014 11:09 AM
hmmm,
It's weird because the reference fields take sys_id and not a display field (not like BMC Remedy with the group names for example) so normally you have nothing to do...
Did you deleted the "old" locations? On an incident, could you click on the location reference icon (or make a mouse over)? and tell me if you have a "record not found" or if you have something
Other option, did you update your existing locations?
Test to do:
1) take one incident (and remember the number) with a location "blank" and click on the location ref icon
2) On the location record, click on save (or modify a dummy thing and click on save)
3) Go back to the incident record and check if the location is still blank or not
4) If not, that will mean you didn't update all your locations so the display field isn't calculated.
5) If it's the case, the keywords "script background", "GlideRecord", "setForceUpdate" should help you to make a "forced mass update of your locations" And as usual, you make the tries and if you have issues/questions you feel free to come back here
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-30-2014 04:55 AM
Thanks for your help David! Once I pushed it to prod the locations updated fine. I must have somehow wiped them in dev when troubleshooting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2014 03:08 PM
When LDAP brings in a location to the sys_user reference field it automatically matches on the display field by default. Look at the transform map and change the "reference value field name" to map to the original display value - that way LDAP should update things correctly.