S
ervice catalog variables can be a challenge to deal with on standard forms when they are displayed in a variable editor. I’ve written before about different ways that you can solve one of these challenges…making the variables read only, so that they can’t be modified after the initial submission through the service catalog interface. Another common problem I’ve seen is that you can end up with a lot of variables that end up empty in the variable editor on your request item or task because they were optional or hidden on the front-end catalog form. If the variables are empty and you aren’t going to have users interact with them on the standard forms then there isn’t much use in having these variables show up at all in the variable editor.
Until now there really hasn’t been a good way to deal with this issue because of the challenges of dealing with so many different variable types in client-side JavaScript. A couple of days ago one of my colleagues, Jacob Kimball, suggested to me that we might be able to overcome this issue by using a ‘display’ business rule to collect the blank variable information at the server and then pass those variable names to the client. So, you can thank Jacob Kimball for the brilliance of this solution. I’m just spreading the love. 🙂
As explained above, the key to making this work is a ‘display’ business rule. The business rule runs before the display of any record in the table (tasks in this case) and queries the ‘sc_item_option_mtom’ and ‘question_answer’ tables to collect any variable names for empty variables. Then it passes this information in the ‘g_scratchpad’ object to the client to hide the variables on the form.
Here is how you could set up the business rule. The script is designed to hide any empty variables for any task records whether they are generated from a record producer or as a catalog item.
Name: Hide Empty Variables
Table: Task
When: display
Condition: !RP.isPopup()
Script:
g_scratchpad.emptyVars = '';
//Check to see if a variable pool exists
var count = 0;
for(vars in current.variable_pool){
count++;
break;
}
//If a variable pool exists then collect empty variable names
if(count > 0){
var emptyVars = [];
var table = current.getTableName();
//Query for the empty variables for this record
//Catalog item and task variables pull from 'sc_item_option_mtom' table
if(table == 'sc_req_item' || table == 'sc_task'){
var itemVars = new GlideRecord('sc_item_option_mtom');
if(table == 'sc_req_item'){
itemVars.addQuery('request_item', current.sys_id);
}
if(table == 'sc_task'){
itemVars.addQuery('request_item', current.request_item.sys_id);
}
itemVars.addNullQuery('sc_item_option.value');
//Exclude Label and Container variables
itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 11);
itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 19);
itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 20);
itemVars.query();
while(itemVars.next()){
//Add variable names to the emptyVars array
emptyVars.push(itemVars.sc_item_option.item_option_new.name.toString());
}
}
else{
//All other variables pulled from 'question_answer' table
var producerVars = new GlideRecord('question_answer');
producerVars.addQuery('table_sys_id', current.sys_id);
producerVars.addNullQuery('value');
//Exclude Label and Container variables
producerVars.addQuery('question.type', '!=', 11);
producerVars.addQuery('question.type', '!=', 19);
producerVars.addQuery('question.type', '!=', 20);
producerVars.query();
while(producerVars.next()){
//Add variable names to the emptyVars array
emptyVars.push(producerVars.question.name.toString());
}
}
//Store the result in the scratchpad
g_scratchpad.emptyVars = emptyVars.join();
}
Once you’ve got the empty variable names collected all you have to do is set up a client script to grab the ‘g_scratchpad’ variable, split out any empty variable names, and hide each one. The client script is pretty simple since the heavy lifting is being done in the business rule. Just make sure that you check the ‘Inherited’ checkbox if you decide to set this up on the task table!
Name: Hide Empty Variables
Type: OnLoad
Table: Task
Inherited: True
Script:
//Hide all empty variables using the scratchpad object passed from 'Hide Empty Variables' business rule
if(g_scratchpad.emptyVars != ''){
var emptyVars = g_scratchpad.emptyVars.split(',');
for(i = 0; i < emptyVars.length; i++){
g_form.setDisplay('variables.' + emptyVars[i], false);
}
}
}
Brilliant !
Thanks a lot Mark !
That is Very Cool. Just recently learned about ‘Display’ Business Rules. This functionality should be a user configurable property setting in Service Now.
Thank You for the Contribution.
One thing to watch out for are any fields that are still marked as mandatory, if the fields get hidden by the client script, the record may not be able to be modified.
Love this functionality. My users certainly enjoy it.
I would love to be able to extend this sort of functionality to email notifications. Specifically approval requests. Currently all variables show up in those notifications. It would be nice to not include those that are empty.
This is certainly possible, but it depends on how you are including those variable values in your email. You would have to add or modify a mail script for that notification to check each variable as it gets added to the notification and make sure that it has a value.
We are using the Summary of Requested Items mail script from the wiki.
http://wiki.service-now.com/index.php?title=Scripting_for_Email_Notifications#Summary_of_Requested_Items
This is what we use in our email template which may help with not passing empty variables
template.print("<i>" + gs.getProperty("glide.servlet.uri") + "</i>: \n");
var desc = current.sysapproval.short_description;
var number = current.sysapproval.number;
template.print("\n");
template.print("Request Item " + number + ":" + desc + " \n");
for (key in current.sysapproval.variables) {
var v = current.sysapproval.variables[key];
if(v.getGlideObject().getQuestion().getLabel() != '') {
if(v.getDisplayValue() != 'false'){
if(v.getDisplayValue() != ''){
if (v != "" && v != null && typeof(v) != "undefined") {
template.space(4);
template.print('' + v.getGlideObject().getQuestion().getLabel() + ": " + v.getDisplayValue() + " \n");
}
}
}
}
}
template.print("\n");
Awesome! Great example. For the benefit of others, the ‘if(v.getDisplayValue…’ lines in the middle of the script are the part that filters out the empty variables. Thanks for sharing!
Hi Mark, thanks for sharing this. How to hide those
1. What are 11, 19, 20 meaning in > producerVars.addQuery(‘question.type’, ‘!=’, 19)?
2. How to hide variables that already set to visible = false but has pre-defined value such as ‘No’, ‘None’, ‘1’. They are still appearing although the visibility has been set to false during the form-filling process.
appreciate your help on this!
Thanks. Those numbers correspond to specific variable types (labels and containers) that we don’t want included in the query because they should not be hidden.
Regarding hiding variables with a matching default value, you can modify the script to do this, but I think it will be difficult to determine which items to really hide. You may have some cases where an un-changed default value might actually be useful information. Any ‘visible = false’ setting that you’ve performed in the catalog or variable setup won’t transfer well to the back-end forms…which is why the script is necessary.
If you want to try hiding variables whose default values have not been changed, then you can modify the script like this…
…For the ‘itemVars’ while loop…
if(itemVars.sc_item_option.item_option_new.default_value != itemVars.sc_item_option.value){
//Add variable names to the emptyVars array
emptyVars.push(itemVars.sc_item_option.item_option_new.name.toString());
}
…And within the ‘producerVars’ while loop…
//Exclude any variables whose value matches their default value
if(producerVars.question.default_value != producerVars.value){
//Add variable names to the emptyVars array
emptyVars.push(producerVars.question.name.toString());
}
I’ve modified this a bit to hide variables, labels, containers and UI pages that are not set to Global. However, it doesn’t seem to work with containers that are set to be “two columns wide”. Works find for one column layouts. I’ve confirmed that it’s not the business rule. Seems to be something with the setDisplay function. Here’s the modified version of the script, if anyone is interested:
g_scratchpad.emptyVars = '';
//Check to see if a variable pool exists
var count = 0;
for(vars in current.variable_pool){
count++;
break;
}
//If a variable pool exists then collect empty variable names
if(count > 0){
var emptyVars = new Array();
var table = current.getTableName();
//Query for the empty variables for this record
//Catalog item and task variables pull from 'sc_item_option_mtom' table
if(table == 'sc_req_item' || table == 'sc_task'){
var itemVars = new GlideRecord('sc_item_option_mtom');
itemVars.addQuery('request_item', (table == 'sc_req_item' ? current.sys_id : current.request_item.sys_id));
var q1 = itemVars.addNullQuery('sc_item_option.value');
//Include variables not defined as global
q1.addOrCondition('sc_item_option.item_option_new.global', 'false');
itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 11);
itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 15);
itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 19);
itemVars.addQuery('sc_item_option.item_option_new.type', '!=', 20);
itemVars.query();
while(itemVars.next()){
//Add variable names to the emptyVars array
emptyVars.push(itemVars.sc_item_option.item_option_new.name.toString());
}
//This is for checkboxes
itemVars = new GlideRecord('sc_item_option_mtom');
itemVars.addQuery('request_item', (table == 'sc_req_item' ? current.sys_id : current.request_item.sys_id));
itemVars.addQuery('sc_item_option.item_option_new.type', 7);
itemVars.addQuery('sc_item_option.value', 'false');
itemVars.query();
while(itemVars.next()){
//Add variable names to the emptyVars array
emptyVars.push(itemVars.sc_item_option.item_option_new.name.toString());
}
//This is for labels, containers and UI pages
itemVars = new GlideRecord('sc_item_option_mtom');
itemVars.addQuery('request_item', (table == 'sc_req_item' ? current.sys_id : current.request_item.sys_id));
itemVars.addQuery('sc_item_option.item_option_new.type','IN','11,15,19,20');
itemVars.addQuery('sc_item_option.item_option_new.global', 'false');
itemVars.query();
while(itemVars.next()){
//Add variable names to the emptyVars array
emptyVars.push(itemVars.sc_item_option.item_option_new.name.toString());
}
}else{
//All other variables pulled from 'question_answer' table
var producerVars = new GlideRecord('question_answer');
producerVars.addQuery('table_sys_id', current.sys_id);
producerVars.addNullQuery('value');
//Exclude Label and Container variables
producerVars.addQuery('question.type', '!=', 11);
producerVars.addQuery('question.type', '!=', 19);
producerVars.addQuery('question.type', '!=', 20);
producerVars.query();
while(producerVars.next()){
//Add variable names to the emptyVars array
emptyVars.push(producerVars.question.name.toString());
}
}
//Store the result in the scratchpad
g_scratchpad.emptyVars = emptyVars.join();
}
Thanks Josh!
Thanks so much, this saved me so much time! My only remaining issue is hiding the variable set title if all variables are hidden. Any chance someone has already figured this out?
Disregard my inquiry – I was able to fix the issue by shifting my title from the Variable Set to a Container Start, and then marking the container start as not global. This allows the entire variable set to disappear on the form.
Mark,
I have a need to edit some variables at certain stages of the workflow once the item is created.
I am trying to modify this script to allow enabling and disabling mandatory for the variables based on another flag set on the sc_task record. I modified the push line to check for mandatory attribute but the reference doesn’t hold up. Any advice?
if(itemVars.sc_item_option.sc_cat_item_option.mandatory=='true') {
mandatoryVars.push(itemVars.sc_item_option.item_option_new.name.toString());
}
Hey Paul,
I think the problem is in your ‘if’ statement. If you walk through that reference, you’ll notice that ‘sc_cat_item_option’ is empty. I think if you replace that with ‘item_option_new’ then it will work better.
Thanks Mark,
I found that just about the same time I saw your post. My next question… How can I make this work for Record Producers?
It appears that sc_item_option_mtom only works for sc_req_item. Can you point me in the right direction?
That’s handled in the ‘else’ statement in the business rule script above. Record producer variables are stored in the ‘question_answer’ table.
Has anyone had any issues with this with the Aspen Hotfixes? We applied the Hotfixes on QA to 04_25_2012_1204 last week and ever since we applied the patch I can no longer run the BR – It hangs all browsers and says due to long running script that the page won’t load. Is there a fix for this?
I haven’t seen or heard of this issue. The only thing I can suggest would be to confirm which part of the business rule is causing the problem by taking pieces out and replacing them with ‘gs.log’ entries until you identify the issue. If you’re going to K12 I could take a look at it in person.
Hey Mark
It doesn’t look like this script works anymore on Berlin. I’ve recreated it on demo14.service-now.com and it is not hiding the empty vars. Ex: https://demo14.service-now.com/nav_to.do?uri=incident.do?sys_id=9235bd7f99503000a7511bee4209777d
It looks as if
g_form.setDisplay(“variables.â€, false);
doesn’t work anymore as referenced on this wiki article:
http://wiki.servicenow.com/index.php?title=Client_Script_Access_to_Variable_Fields_on_Task_Records
That is bizarre i set it up on demo site 15 with the same results on what our code is. I have it not hiding on a certain kind of request cause i have a team updating one of the variables but i took that out and i get the same on that demo site it doesn’t hide the variables. I tried it on several requests on both of our sites and it works fine so there must be something else blocking it from working for whatever reason that doesn’t happen on ours… bizarre i’ll be interested in seeing what Mark says..
g_form.setDisplay(‘variables.caller_id’, false); works fine there. The problem is that ‘g_scratchpad’ isn’t available to the client as it should be. I can log the value from the business rule so I know it’s being set correctly there. It’s not being set up properly at the client though. You’ll need to get ServiceNow support to help you with this. A little tip though, don’t mention the SNGuru solution. Just set up a generic example using the scratchpad. As soon as you mention SNGuru they’ll try to tell you it’s unsupported…even though the issue has nothing to do with SNGuru :).
Let me know what you find.
I see what you mean about the scratchpad on the demo site. Whats even stranger is that on our dev instance, which is on a previous release of Berlin, I can get the scratchpad vars to display. It’s when I call something like: “g_form.setDisplay(‘variables.description’, false)” the whole client script fails. Even when specifically naming the field.
I’ll see if I can recreate the second problem I’m having and submit one for that too.
Confirmed: Berlin Hot Fix 4 fixes the problem.
Awesome! Thanks for closing the loop on this.
That’s really wierd because I had Berlin added to both our QA and DEV sites and i just checked it after I saw this and it’s working on our environments. I couldn’t get it to work with a previous aspen patch so i had it removed awhile back but it looks ok now.
I rebuilt the test cases on demo18 and everything seems to work fine. Then I tried your code and it worked fine as well: https://demo18.service-now.com/nav_to.do?uri=incident.do?sys_id=b8140a84e8e03000720caf93a2c7887a
The demo instances are so sketchy.
So I just need to figure out how to upgrade my instance. 🙂
Thanks
I noticed that this issue is related to a bug in the js_includes.jsx file so I made some changes to the onLoad client script and it appears to work.
function onLoad() {
//Hide all empty variables using the scratchpad object passed from ‘Hide Empty Variables’ business rule
if(g_scratchpad.emptyVars != ”){
var emptyVars = g_scratchpad.emptyVars.split(‘,’);
var scriptCode = ”;
for(i = 0; i < emptyVars.length; i++){
// Store empty variables as string of commands
scriptCode += "g_form.setDisplay(\"variables." + emptyVars[i] + "\", false);";
}
// Only run eval() function once to avoid recursive loop
eval(scriptCode );
}
}
Mark,
Is there a way to achieve the same inspection results of the variables without the use of the eval() function?
Thanks!
I’m not aware of a way. The use of ‘eval’ shouldn’t be a concern in this case though since it’s limited in its scope and the information being included in the eval statement is all controlled from the back-end.
Hmm…I tried to create the BR, and when I use the syntax checker, I get these errors.
WARNING at line 6: Bad for in variable ‘vars’.
WARNING at line 13: Use the array literal notation [].
Just wondering if anyone else has seen this?
Cheers, Mark
I got the same warnings when checking the syntax on the BR. Additionally, when checking syntax on the CS, I received this warning:
WARNING at line 6: eval is evil.
Those errors are a case of the syntax editor being a bit more aggressive than it has to be. It’s not anything that you need to worry about in this case. If there’s somebody that can write code that avoids the use of ‘eval’ to solve this problem, I’d love to post it. I hate that message though. ‘eval’ is no more evil than any other method. It depends completely on how you use it to solve the problem at hand.
Why is eval being used? This works just as well:
Ugh. You’re right, it’s not needed at all. The reason it’s there is because the original version of this script had to hide the variables via DOM manipulation. I replaced that with ‘setDisplay’ but didn’t rip out the other unnecessary piece. I’ve updated the code above. Thanks for the assist!
Hi Mark,
Your above solution works brilliantly, if we don’t have check boxes and Containers.
Is there any way in the same solution we can handle the check boxes and two column wide Container.
Thanks,
NJ
No way to handle the container, but you can hide checkboxes. Check out the comment from Josh B. above.
Has anyone else seen this clear the variables that are NOT empty out after assigned to is changed on the sc_req_item_task?
We are noticing this in the latest version of Calgary. Also, anyone work in a regulated environment where hiding fields on a form, even if empty dynamically would be considered a violation?
I’ll provide an update when I figure it out and if nobody has already posted it.
Thank you,
Bryan
The issue was a dom reference in the make variables read only client script. We had to take Calgary Patch 3 to resolve this issue. It worked perfectly again after that. The alternative would have been to remove the dom reference and replace it with glide.
Cheers!
Bryan
Hi Mark,
Would you say this solution is still needed with the changes to UI Policies in Calgary? I have a client that has a lot of client scripts that they use to show/hide variables on that backend and I have been considering implementing this solution to deal with their empty variables more efficiently. However, they are currently on Berlin but are going to upgrade (skipping Calgary) to Berlin and was wondering if I should still be considering this or just use the new UI Policies for dealing with this. Thanks, -e
I think any time you can use the out-of-box behavior you should. Having said that, there is still a fairly major issue with using the catalog UI policies and client scripts. They don’t allow you to implement one single script to fix the issue. You have to address it for each item or variable set and continue to update and modify for each variable you add. This solution may still be preferable if you’re looking to do something across the board in the instance.
Thanks for the quick reply Mark…!!! -e
Hi Mark,
Does this solution also effect the way the Approval Summarizer (variable_summary_approval.xml) displays variables for an item?
If not, do you have any suggestions on how to extend this to include setting empty variables to not display on the Summarizer? I have a client that has tones of variables on their items and re-architecting their use of Variables would be a major over-haul.
It doesn’t have any effect on the approval summarizer as far as I know because client scripts don’t run there. Unfortunately I don’t know of a simple solution for that.
Thanks Mark,,, arrrgh 🙂 BTW, why do you use the condition: !RP.isPopup() in this Display BR ?
Hi Erik/Mark,
I’m trying to do the exact same thing for an approval record.
Did you find a solution Mark?
Thanks in advance
Anthony
I haven’t found a way to do this for an approval record. Not sure if it’s possible there actually.
Erik, It’s been a while since I implemented that but I know that you can run into errors trying to run client scripts in popups. Because it wouldn’t work in the popup anyway, we might as well cut down on the processing in that scenario.
Mark, cool thanks so much… I googled it and only got two results, yours and another post and still was not 100% sure what the purpose was for… so now I got it… Thanks, -e
These scripts are still incredibly helpful even though we now have the option to run UI Policies on Catalog Item/Request Item/Catalog Task. I use these scripts when I have a complicated Record Producer with multiple UI policies to hide the unneeded variables on the Incident/Change/Project forms.
Thanks for the feedback. I agree that they still can be incredibly useful in the right situation.
Any way to make this work on macros and Macros with labels? We use a number of ui_macros inserted as variables, and the client script seems to not be able to set those to hidden, even from the ui javascript executor. I can confirm they are being passed in the scratch pad
I have tried the setDisplay option as well as getControl(‘element name’).hide() (in firefox) or getControl(‘element name’).style.display = ‘hidden’ in IE.
Those don’t have the same HTML/ID structure so they can’t be hidden predictably with a script like this. You’ll just need to wrap all of your macro variables in their own wrapper that you can predict and hide in a separate script.
Ok, any idea how to do that? I have tried encapsulating the macros inside containers and then editing the Hide Script to allow containers to be hidden with no success.
It looks like the macro has a name and id something like #container_1c5e30ba2b3bc980b379a59419da15eb, but setting that via setdisplay also doesn’t work. The id matches the sysID of the macro variable itself, so I could find it with a client script, but I can’t figure out what command will hide it once I have that id.
I think the best you could do would be to wrap your UI macro code in a specific div with a specific ID each time. Then you could predictably target that in a client script. I don’t have specific code for that though because it will depend on how your UI macros are constructed.
Hi Mark,
This is working perfectly to hide the empty variables in the Request, but it is not hiding the empty variables from any Catalog Task (sc_task) spawned off from the Request. Is there something that I’m missing?
TIA,
Quan
Should work the same way on sc_task as long as you have the same scripts in place for that table.
I have been racking my brain on trying to get it to work on the sc_task table. I know your script works for others, so it must be something within my implementation of sc_task. We do have view rules on that table, but with Global selected on the scirpt, shouldn’t it run across all views? Do you know of any gotchas with your script and view rules?
Another thing is that someone suggested merging the business rule script into the client script in request and sc_task tables. I know this would mean a performance hit on the client vs running the major work server-side. What is your opinion?
Thanks again, Mark!
Is there anyway to get this working on the mobile app (or something like it that will work there)? Having a heck of a time trying to hide variables on the new mobile app, or even make them read-only.
Hi, I appreciate this is an old script now – but it does still seem to work.
The only issue I have is that it only seems to be working for admin users. Non-admins can still see all the empty variables.
Thanks Harry. Yes, this script should still work just fine. If it’s not working for non-admin users I’d guess it’s probably a client script conflict of some sort. You might check your browser error console to see if there’s anything there that would point you in the right direction. Often times there’s another script or form element that’s causing the issue.
Hi Mark,
I tries setDisplay for my variable editor being used on HR Case i.e, default variable editable formatter created for HR Case. We are using Istanbul Patch 3 . It is not working for me….. I get the value with g_form.getValue(‘variables.city2’) and setVisible is working for the variables. But i want to use setDisplay which is not working at all. Please suggest
SetDisplay should work on forms for variables. Your problem isn’t with the script here, it’s that ServiceNow’s API is broken in your instance for some reason. You’ll need to contact SN support for a solution on that.
Thanks for your response Mark
It worked from Global Application :). Variables belong to global application so script is accessing on global then it worked.
Hello Mark,
Thanks for the script, it works pretty well on backend. But I have an issue, when I show the form in the Service Portal. The client script is not working. As I saw in the docs, variables.name notation is not supported in Service Portal. Also when I try to simply log in client script g_form.getValue(varName) or g_form.getValue(‘variables.’ + varName), both values are empty. It seems like client script doesn’t see variables. Did you make your solution work in Service Portal? Thanks a lot
This is just for standard forms. I don’t have anything for service portal like this currently.
Just implemented this script into our test environment and works quite well (Helsinki Patch 11) expect for check boxes, empty check boxes still remain?
Hi Ashley,
Unchecked check box variables actually have a value of false. They are only ’empty’ from a visual standpoint. Because they have a value, even unchecked check boxes will appear when using this solution. You could exclude all check box variables from the list by modifying the two queries in the code to account for variables with a value of false. Adding a lines like
and
to the appropriate queries in the code might work.
I sourced my Business Rule from a different blog but took some inspiration from your idea to hide ‘false’ checkboxes (type = 7) Here is the script of my BR:
hideEmptyFields();
function hideEmptyFields() {
var emptyVars = [];
var v;
/* Put all variable values and labels from the variable pool into an array */
for (var i in current.variables) {
v = current.variables[i];
/* Only include empty variables, and exclude Label and Container variables */
if (v == ” && v.getGlideObject().getQuestion().type != 11 && v.getGlideObject().getQuestion().type != 19 && v.getGlideObject().getQuestion().type != 20 || (v.getGlideObject().getQuestion().type == 7 && v.getGlideObject().getValue() == ‘false’)) {
emptyVars.push(v.getGlideObject().getQuestion().getName());
}
}
/* Join the variable values together into a string */
g_scratchpad.emptyVars = emptyVars.join(‘,’);
// gs.log(‘BR – RITM Variables for ‘ + current.number + ‘: ‘ + g_scratchpad.emptyVars);
}
Hi,
In addition to empty variables, is it also possible to hide specific variables? – In a record producer, I have created several read-only single line texts variables, these texts contain instructions to redirect users to contact somebody else depending on what they have selected in the questions, but these will not make any value to the ticket handler, so I would like to hide these specific variables from the variable editor.
Thanks!
Hi Albert,
You can’t do this using this script. Instead, you can create a UI Policy and make the variables not visible and apply it only to the target record.
This part of the code can cause a slow query:
var producerVars = new GlideRecord(‘question_answer’);
producerVars.addQuery(‘table_sys_id’, current.sys_id);
There is an index on questions_answer ( table_name, table_sys_id, order ) that is not used because table_name is not being used, but it is available, and can be used to speed up this business rule:
var producerVars = new GlideRecord(‘question_answer’);
producerVars.addQuery(‘table_name’, current.sys_class_name); // ADD THIS LINE TO USE EXISTING INDEX
producerVars.addQuery(‘table_sys_id’, current.sys_id);