- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-17-2019 08:32 AM
We are experiencing some really odd behavior where the value of a checkbox (from a Variable Set) from a Catalog Item that is being filled out in the Service Portal is not being reflected properly on the RITM that is submitted, even though the underlying table show the correct value! I think this is best explained with an example.
So, we have a checkbox that toggles between two different fields (they have the same label, but different names; class_id and class_id2). If the checkbox is not selected, the class_id field is displayed and made mandatory (and this is a reference field). If the checkbox is selected, the class_id2 field is displayed and made mandatory (and this is a free-from field).
So, I am checking the box and entering in a free-form value, like this:
After submitting it, if I go into ServiceNow, and look up the value of what was submitted in the "Options" table, it shows that the check box is selected:
Now, if I bring up the RITM for this submission, and look in the Variable section, it incorrectly shows the check box as being unchecked, and therefore shows class_id (the reference field), like this:
If I manually check the check box on this form, I see my correct value (the free-form field):
The question is, why is it not showing the correct value for the checkbox when I bring up the RITM? Has anyone ever seen anything like this?
I do have a bunch of Catalog Client Scripts and Catalog UI Policies on the Variable Set being used that are supposed to be reflected back on the Requested Item, but the form shows properly when I submit it on the Service Portal, so I don't understand why it would look/behave any differently on the RITM.
Thanks
Solved! Go to Solution.
- Labels:
-
Scripting and Coding

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-17-2019 10:59 AM
This sounds like you could have some sort of onLoad client script or something that is removing that check from the checkbox and perhaps setting it to false, which is turn causes the chain of events to occur like you've mentioned. This is even more so plausible given that as soon as you check the box, the manual text entry -- exactly what you submitted it as...appears...meaning data is being retained.
I'd recommend looking at possibly an onLoad or something causing this field to be cleared.
To further test this...you could just turn off all UI Policies or Client Script and just have all fields exposed, run a test and see if the box remains checked this time, if so...start to turn things back on and see where the issue is.
Please mark reply as Helpful/Correct, if applicable. Thanks!
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-17-2019 12:16 PM
OK, I try what you suggested (I had over 30 different UI Policies and Scripts), and have goot news and bad news. The good news is that I have seemed to locate the offending code. It is a Catalog UI Policy in the same Variable Set that is having issues (so that seems to make sense).
But the bad news is that particular Policy isn't even touching that manual_class_id checkbox variable. So I don't understand why it would be affecting it.
Here is what it looks like:
As a double-check, I went back and deactivated every single Catalog UI Policy and Catalog Client Script in this Variable Set, and just activate that one, and the error shows up (I thought it might be interacting with other ones in the same Variable Set, but that disproved that theory).
Any idea of why that would affect why the check is not showing up in the manual_class_id box on the RITM?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-17-2019 01:02 PM
So, just for the heck of it, I tried deleting that particular Catalog UI Policy, and then rebuilding it. Lo and behold, that seemed to fix it! I don't know if the record was corrupt or what. I created it the EXACT same way.
The only thing to note was that the original Policy was created on Jakarta, and we have since converted to London (where they added the "Clear the variable value" option on the Policy Actions, though I did not use that setting).
Thanks for helping me identify the problem record!