Here’s the good news! In my second article about powerful dictionary configurations, I will showcase a time-saving technique to reuse choice list values across your instance. This saves you time and ensures consistency in your data management. This approach is particularly beneficial for multilingual environements, as you only need to translate the main choice list.

Use case 1: Linking Catalog Variables to existing Choice Options

There is a Choice field on a table, and we need to replicate this field on a Catalog Item or Record Producer form with the same choices.

For example, adding the Incident Category drop-down to the “Create Incident” Record Producer. On the left of the screenshot below is the Incident Category field as displayed in the Service Operations Workspace, and on the right is the Create Incident Record Producer in the Employee Service Center Service Portal.

• To get these values onto the “Create Incident” Record Producer Form, create a new Select Box Variable to hold the values that need to be displayed.

• Next, instead of creating mirror Choice options in the Question Choices Related List, navigate to the “Type Specifications” section on the Variable form. Enter the following values and save the variable:
  • Choice table: Incident [incident]
  • Choice field: Category

• Now when we navigate back to the form in the Service Portal, we can see that there is a new Category field on the form, and it already has Choice values that exactly match the Incident Category selections. Now if you change the available Choices for the Incident Category field, the Variable drop-down values will automatically reflect those changes without have to repeat the configuration on the Variable record.

Use case 2: Reuse Choice List values in another field

Sometimes you need to replicate a choices options across several tables and fields to create consistency as data moves from one record to another, like Asset and CI attributes that exist on both records. –OR– You have several fields on the form with the same set of Choice options. For example, a design decision to use Yes/No Choice fields instead of Checkbox fields.

• First, choose which table and field will drive the other fields options. The example will use Incident Category.
• Navigate to the Dictionary record for the other field(s) that will be driven by the Incident Categories.
• Find the Choice List Specification tab. If you don’t see the Choice table field, you may have to switch to Advanced view.
• Enter the following values and save the Dictionary record:
  • Choice table: Incident [incident]
  • Choice field: Category

That’s it! Now, when you change the main field’s list, all of the other choice lists will reflect the change.

Summary

This article explored two simple ways to reuse choice list values in the ServiceNow platform. If you are a customer that supports multiple language, you’ve exponentially saved yourself some time, because you only have to translate the main field’s Choices and those changes will also be reflected everywhere as well.

By leveraging these techniques, you can streamline your ServiceNow configuration and save valuable time!

The post Be a Choice List “Thief” appeared first on ServiceNow Guru.

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.

//Initialize the scratchpad variable
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!

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(',');
      for(i = 0; i < emptyVars.length; i++){
         g_form.setDisplay('variables.' + emptyVars[i], false);
      }
   }
}

The post Hide Empty Variables on a Standard Form appeared first on ServiceNow Guru.

This onLoad script will place a red mandatory indicator next to the label for a set of checkbox variables. Just paste the script into an ‘onLoad’ catalog client script and set the ‘mandatoryLabelName’ variable below with the Name value of the label variable for your group of checkbox variables. NOTE: This script requires an associated ‘Label’ variable to work with your checkbox variables and will not work in Service Portal. For Service Portal you should simply add a form info message as shown in the script below. See this post for details on how to set up label variables with checkboxes.

function onLoad(){
    try{
        mandatoryLabelName = 'checkbox_variables';
        $('status.' + g_form.getControl(mandatoryLabelName).id).show();
    }catch(e){}
}

This onSubmit script will check a set of checkbox variables to make sure at least some of them are checked. All you have to do is paste the script into an ‘onSubmit’ catalog client script and set the ‘mandatoryVars’ and ‘mandatoryCount’ variable values below with the checkbox variables the script should apply to and the minimum number of checked boxes.

function onSubmit() {
    //Set the mandatory checkbox variable names and total mandatory count here
    var mandatoryVars = 'option1,option2,option3,option4';
    var mandatoryCount = 2;
    
    var passed = forceMandatoryCheckboxes(mandatoryVars, mandatoryCount);
    if (!passed) {
        //Abort the submit
        var message = 'You must select at least ' + mandatoryCount + ' options.';
        g_form.addErrorMessage(message);
        return false;
    }
}

function forceMandatoryCheckboxes(mandatory, count) {
    //Split the mandatory variable names into an array
    mandatory = mandatory.split(',');
    var answer = false;
    var varFound = false;
    var numTrue = 0;
    //Check each variable in the array
    for (var x = 0; x < mandatory.length; x++) {
        //Check to see if variable exists
        if (g_form.hasField(mandatory[x])) {
            varFound = true;
            //Check to see if variable is set to 'true'
            if (g_form.getValue(mandatory[x]) == 'true') {
                numTrue ++;
                //Exit the loop if we have reached required number of 'true'
                if (numTrue >= count) {
                    answer = true;
                    break;
                }
            }
        }
    }
    //If we didn't find any of the variables allow the submit
    if (varFound == false) {
        answer = true;
    }
    //Return true or false
    return answer;
}

The post Make Checkbox Variables Mandatory appeared first on ServiceNow Guru.

There are a couple of things I don’t like about this arrangement. First, the ‘Options’ label just looks bad. I’d really like to change that name to something else. Secondly, just because they follow each other in order doesn’t mean that I want to have all of those checkboxes grouped under a single question when presented on the screen. They might be asking completely different things. Well, it only took me 3 years but I’ve got a solution now that requires nothing more than a little bit of care in the arrangement of a few variables on your catalog item or survey. :)

The secret to this solution is simply to add a ‘Label’ variable immediately before the checkbox variables that you want to group on the form. The label groups any checkbox variables that follow it and it also overrides the generic ‘Options’ label that is shown normally. You can control this grouping by arranging the ‘Order’ values of your variables or questions as shown here…

An ordering as shown above in a catalog item would produce the following result…

If you have multiple groups of checkbox variables that you want to display immediately after one another you would need to set up 2 label variables, each followed by the checkbox variables that should be grouped underneath.

This concept works in exactly the same way with Survey questions.

The post Multiple Checkbox Variables in Service Catalog and Surveys appeared first on ServiceNow Guru.

Re-use choices in a field (Dictionary entry)

Re-use choices in a variable (Variable definition)

The post Re-using Choice List Options in Fields and Variables appeared first on ServiceNow Guru.

A while ago I helped to answer a forum posting for someone who was looking for a way to present catalog variables to an end-user on a Request Item form but restrict the editing of those variables. At the time, I came up with a solution that worked, but that I really wasn’t happy with. I recently came across another forum posting where the poster wanted to do something similar. The difference for the most recent poster was that the variables were to be shown on an Incident form (which had been generated by a record producer). There were some subtle differences in the way variables were presented on the different forms that made my original script unusable for the incident form. So, I’ve had to revisit this topic to come up with a better solution and I’ve decided to compile all of the different options for making variables read only on a regular form. These solutions can be used in a variety of places, but will most often be applied to the Catalog Item, Catalog Task, Incident, or Change Request tables. Enjoy!

Locking down variables by role without a script…

Its probably best to avoid writing any script at all if you can to lock down access to variables. Service-now allows you to add roles to any variable in the system for this purpose. If you want to lock down variables without using a script, the solution can be found here. This solution is very simple but often doesn’t give you the type of flexibility that you need to restrict access to variables. It also requires you to set access to each and every variable in the system individually.

Locking down variables via business rules…

Probably the simplest way of locking down variables on a standard form via script is to create a business rule that checks to see if the variables have changed and then to abort the submission of the task record if they have changed. To do this, you just have to create a ‘before’ business rule on the table you want to restrict the editing of variables. The business rule should have a condition of ‘current.variable_pool.changes()’. You can put whatever you want in the script field but it should include ‘current.setAbortAction(“true”);’. If the user changes variable values and tries to submit the record they would get an alert telling them that they are not allowed to change variables. Here’s a sample…

//Add an information message, abort the submission, and reload the page
gs.addInfoMessage('You are not allowed to change variable values on this record.');
current.setAbortAction(true);
action.setRedirectURL(current);

The other option is to simply not show the variables at all and instead dump them into the work notes or comments fields. Here’s a script I found on the forums that takes all of the variables for a given item and sends them to the work notes field on that same item.

var wn = 'Variables:';
for (key in current.variables) {
var v = current.variables[key];
wn += '\n' + v.getGlideObject().getQuestion().getLabel() + ': ' + v.getDisplayValue();
}
current.work_notes = wn;

Locking down variables via client scripting…

Service-now actually provides a simple way to make a variable on a standard task form read only via client scripting. If you just need to disable one or two variables on a single item then this is probably the best scripting option. The solution is documented here.

More often than not however, if you are disabling variables at all, you are disabling them entirely or disabling them for a certain group of users. For that case, you could use a script like this one to lock down all of the variables on a form. This script looks for the ‘Variables’ label on the variable formatter and disables the variables associated with it. It is designed to work on any task table in Service-now.

function onLoad(){
try{
//Get the 'Variables' section
var ve = $('variable_map').up('table');
//Disable all elements within with a class of 'cat_item_option'
ve.select('.cat_item_option', '.slushselectmtm', '.questionsetreference', '.form-control', '.checkbox').each(function(elmt){
elmt.disabled = true;
});
//Remove any reference or calendar icons
ve.select('img[src*=reference_list.gifx]', 'img[src*=small_calendar.gifx]').each(function(img){
img.hide();
});
//Hide list collector icons
ve.select('img[src*=arrow]').each(function(img){
img.up('table').hide();
});
}
catch(e){}
}

The post Readonly Variables on a Standard Form appeared first on ServiceNow Guru.