PSA: How to View Variables in Lists

Bradford Shelle
Kilo Guru

After having to play around with variables quite a bit in a recent project, I thought I'd share how to display variables on a list of Requested Items / Catalog Tasks. This applies to lists and related lists, as reports have their own method of displaying variables. Important note: This was performed on Fuji. Your experience may differ on older versions of ServiceNow.

Step 1 Identify the variables you'd like to display on your list, then copy the sys_id for each variable. This is as simple as heading to the Catalog Item, and jumping into the variable(s) in question. We'll need the sys_id to add the column into the list.

Step 2 Head over to System UI -> Lists

Step 3 Identify the list you'd like to display the variable(s) on. We're looking for one of two things here. Either the name of the view of the list you'd like to include the variable(s) on (I highly recommend creating a new view instead of using the Default view for this, as most likely the variables will apply to certain catalog items instead of every single one), or for a related list look at the Parent and Relationship columns for the table and name of the tab for the related list. Head into the list when you've found it.

find_real_file.png

Step 4 Create a new List Element(s) from the related list at, using "variables.sys_id" (no quotes) in the actual Element field on the List Element form. Create a new List Element for each variable you wish to add.

find_real_file.png

Step 5 Head over to the list where variables were just added. They won't show up immediately, so don't panic. Edit the list layout, and move around the variables to the spots you'd like them in the list (even if the position is already how you'd like it, move a variable one position up/down, then move it back and save). At this point, the variables should be visible!

Hope this helps at least one person out there. Take care!

27 REPLIES 27

Matt Hernandez
Tera Guru

Hi Bradford,



Through working with HI support, I found that the ability to view variables in lists DOES still exist, but it toggles on/off with a property, and in our case it was turned off because it causes another problem.



The property in question ('glide.ui.list.optimize') is apparently controlling several mutually-exclusive (but desirable..) things. We proved that ('glide.ui.list.optimize' == true) could ENABLE display of catalog variables but we had to set THE SAME property to FALSE in order to facilitate dot-walking in reports on the time card table, with a column such as, 'Task.Parent.Account# [Project]'. So we verified that setting the property 'true' breaks the dot-walking in reports, and setting it 'false' breaks the display of catalog variables in reports and lists.



Faced with this conflict, the HI Support team strongly recommended that we set the property back to TRUE, to fix the catalog variable issue, and then reopened our old ticket (for dot-walking) which had previously been resolved by telling us to set the property FALSE. I guess they're trying to see if they can help us find another solution for the do-walking issue.



So there is hope for displaying catalog variables, but with trade-offs.


Has there been any update for the issue for facilitating dot-walking in reports when the glide.ui.list.optimize is set to true?


Actually maybe. I am evaluating a statement from HI about how these properties really just control ACL evaluations. There was a comment in one of my tickets from two months ago that I missed, and just re-read it today. Now I have to experiment with ACLs and see if I can make the problem go away. The problem may just be ACLs and was in disguise because I didn't understand what "optimize list" was really doing. Apparently (I'm told, not yet proven) that it bypasses the ACL evaluations for columns that are not being displayed. This means that toggling the property 'false' triggers more ACL evaluations for columns that are NOT displayed. So this gives the opportunity for the report user to be denied access to columns he can see, by ACLs for columns he can't see. The "optimize" property is apparently a switch that turns on/off this functionality.



So I've got ACL testing to do, when I get a chance.


Thanks for the update.
Are you aware of any current HI Problem tickets specifically for the topic of dot-walking in reports in which HI has provided recommendations?
FYI, HI provided us a recommendation to put a READ ACL (with no conditions) on the table for which the dot-walk is being performed. In one case (for cmdb-ci), this appeared to have worked; however, in another case where we have the existence of a dot-walk for a reference field that has another dot-walk, we are seeing some different behavior.   Doing some testing, we found at least 1 "work-around" -- after adding another dot-walk from the same table to the report/list, the value for the non-displaying one is displayed... We are not sure of the reason, though.


The only PRB I'm aware of on this is the one that got attached to our original incident, when it was being handled by a different admin of ours. PRB581123 is closed, from way back in 2013, actually specifies that ACLs are the cause of dot-walk failure reporting. It says,



"The missing fields are missing because there are ACL rules that applied to these fields and return false which means that current user can't see these fields but still can see the records and the other fields. Turn on the ACL debug and run the report with the missing fields. Scroll down and the debug lines in red indicate that the rule failed. There are failing rules for each missing field. That is the expected behavior."



Since that original incident about dot-walking, our issue got confused because we had another report-related incident for catalog variables which went missing when the "optimize lists" property change was made to solve the dot-walking. Conversations with HI folks are sometimes not clear, and we never actually realized that they were linking us into a problem about ACLs, for which we never should have needed to change a system property. We had parallel incidents going, and started going in circles because the property toggles us back and forth in a tradeoff between two functionalities of which we need both! We should have been troubleshooting the ACL issue all along. So now that's our next step. I still haven't gotten time to mess with that yet.