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.

To help answer this question, we recently created a really useful admin utility to find all places where a record is referenced. In this article I’ll show you how you can set it up in your instance!

The script to produce the kind of data you need in this case could be run from a variety of places. We chose to make it a simple global UI action so that it would be easy to access and use on any record in the system. The UI action works by first querying the system dictionary for all reference, document_id, and condition fields that reference the table you initiate the action from. It filters out unnecessary system and log tables. Then it iterates through all of the remaining records, performing a table/sys_id query on each table where a match exists. The query results are then output to the browser in an information message.

You can set the UI action up in your instance by creating a new UI action with the following settings. Once set up, you’ll have a ‘Find Record References’ link at the bottom of each form in your system.

//Client-side 'onclick' function
function confirmFindReferences() {
if (confirm('Performing this action will query multiple tables and records and may take a long time to complete. Are you sure you want to continue?') == false) {
return false; //Abort submission
}
//Call the UI Action and skip the 'onclick' function
gsftSubmit(null, g_form.getFormElement(), 'find_references'); //MUST call the 'Action name' set in this UI Action
}//Code that runs without 'onclick'
//Ensure call to server-side function with no browser errors
if (typeof window == 'undefined')
findReferences();//Server-side function
function findReferences() {
var msg = '<b>Matching tables and columns where this record is referenced (if any) are displayed below...</b>
';
var refTable = new TableUtils(current.getTableName()).getTables();
gs.include("j2js");
refTable = j2js(refTable).join();
var refRecordID = current.sys_id;
//Query dictionary table for reference, document_id, and condition fields
var dict = new GlideRecord('sys_dictionary');
dict.addQuery('reference', 'IN', refTable).addOrCondition('internal_type', 'document_id').addOrCondition('internal_type', 'conditions');
//Do not query audit and log fields
dict.addQuery('name', 'DOES NOT CONTAIN', 'var__m_');
dict.addQuery('name', 'DOES NOT CONTAIN', 'ecc_');
dict.addQuery('name', 'DOES NOT CONTAIN', 'ha_');
dict.addQuery('name', 'DOES NOT CONTAIN', 'syslog');
dict.addQuery('name', 'DOES NOT CONTAIN', 'sys_history');
dict.addQuery('name', 'DOES NOT CONTAIN', '_log');
dict.addQuery('name', 'DOES NOT CONTAIN', 'text_search');
dict.addQuery('name', 'DOES NOT CONTAIN', 'ts_');
dict.addQuery('name', 'DOES NOT CONTAIN', 'sys_watermark');
dict.addQuery('name', 'DOES NOT CONTAIN', 'sys_audit');
dict.addQuery('name', 'NOT LIKE', 'v_%');
dict.orderBy('name');
dict.orderBy('element');
dict.query();
while (dict.next()) {
var tblName = dict.name.toString();
// Skip tables used for Table Rotation
var gr = new GlideRecord("sys_table_rotation_schedule");
gr.addQuery("name.name", '!=', tblName);
gr.addQuery("table_name", tblName);
gr.query();
if (!gr.hasNext()) {
var recMessage = ' records found';
var filterOperator = '=';
var refType = dict.internal_type;
if (refType == 'glide_list' || refType == 'conditions') {
filterOperator = 'LIKE';
}

//Query each table for matching records
var rec = new GlideRecord(tblName);
if (refType == 'glide_list' || refType == 'conditions') {
rec.addQuery(dict.element, 'CONTAINS', refRecordID);
} else {
rec.addQuery(dict.element, refRecordID);
}
rec.query();
if (rec.getRowCount() == 1) {
recMessage = ' record found';
}
if (rec.getRowCount() > 0) {
//Display table/column info
msg = msg + '<b>Table: </b><i>' + tblName + '</i>' + ' - <b>Column [Column type]: </b><i>' + dict.element + '</i> [' + dict.internal_type + ']' + ' --- ' + '<span style="color: #136fb0;">' + '<a href="' + dict.name + '_list.do?sysparm_query=' + dict.element + filterOperator + refRecordID + '" target="_blank" rel="noopener">' + rec.getRowCount() + recMessage + '</a></span>.
' + '';
}
}
}

//Query for workflow variable values
tblName = 'sys_variable_value';
var vVal = new GlideRecord(tblName);
vVal.addQuery('value', 'CONTAINS', refRecordID);
vVal.query();
if (vVal.getRowCount() == 1) {
recMessage = ' record found';
}

if (vVal.getRowCount() > 0) {
//Display table/column info
msg = msg + '<b>Table: </b><i>' + tblName + '</i>' + ' - <b>Column [Column type]: </b><i>' + 'value' + '</i> [' + 'string' + ']' + ' --- ' + '<span style="color: #136fb0;">' + '<a href="' + tblName + '_list.do?sysparm_query=' + 'valueLIKE' + refRecordID + '" target="_blank" rel="noopener">' + vVal.getRowCount() + recMessage + '</a></span>' + '.' + '';
}

gs.addInfoMessage(msg);
action.setRedirectURL(current);
}

The post Find all System References to a Specific Record appeared first on ServiceNow Guru.

The first step is to set up your decimal field. You can do this by personalizing the form or list for the table where you need the decimal field. The new field type should be ‘Decimal’ as shown in the screenshot below.

Now for the important part! When a decimal field is created it is set up with a ‘Max length’ value of 15. You can verify this by personalizing the dictionary for your new field. This also means that your decimal field is limited to NO MORE THAN 2 DECIMAL PLACES BY DEFAULT. If you want to extend that, you need to make a couple of adjustments to the dictionary entry for your field.

If you’re not there already, open the dictionary entry for the field by right-clicking the decimal field label and selecting ‘Personalize -> Dictionary’. Once there, you’ll need to adjust both the ‘Max length’ and ‘Attributes’ fields as shown below. The decimal places are a combination of ‘Max length’ and the ‘scale’ attribute. If you want 4 decimal places, you’ll need a ‘Max length’ of 4 plus the default of 15, or 19. Your ‘scale’ attribute would be set to 4, to indicate the number of decimal places. 6 decimal places would require a max length of 21 and a scale attribute of 6, and so on.

The post Controlling decimal field places appeared first on ServiceNow Guru.

While the schema map is useful, it can also be difficult to navigate to unless you know exactly where to look. The only place in the system to access the schema map is from the ‘Tables and Columns’ module and this is only available to users with the admin role. In this post I’ll show you how you can make the schema map for a given table more accessible by creating a global UI action link that allows you to display the table schema map from any form in the system – for any role you want.

Here’s the UI action code. Notice that it’s set on the ‘Global’ table so that it will be available as a link on every form in the system. You’ll also notice that the ‘Condition’ field is set to allow access to only the admin role. You can adjust this as needed to grant access to other users as well. I’ve also added a couple of checks in the script to see if the action is initiated from the dictionary or the label table. In these cases, the popup will pull from the table defined in the dictionary or label entry – rather than the actual ‘sys_dictionary’ or ‘sys_documentation’ tables.

function showSchemaMap(){
//Get the table name
var tableName = g_form.tableName;
if(tableName == 'sys_dictionary' || tableName == 'sys_documentation'){
//Use 'Table' field value for dictionary or labels
tableName = g_form.getValue('name');
}
getTopWindow().popupOpenFocus('schema_map2.do?sysparm_stack=no&sysparm_attributes=table=' + tableName, 'super_schema', 950, 700, '', false, false);
}

The post Show a Table Schema Map from any Form appeared first on ServiceNow Guru.

Some questions about display values that I hear very often are “How do I show information from more than one field for the display value?” or “Can I have different display values on 2 reference fields that reference the same table?”.  The limiting factor when answering these questions is that you’re limited to a single searchable display value per referenced table. What this means is that EVERY reference field that references a particular table needs to use that table’s display value so you cannot mix and match between reference fields.  There are a couple of options that can be used to provide a bit more information to the user in these scenarios however.

The way I typically approach this type of requirement is to create a new calculated field that is a composite of the fields that I want to search on. Then I make that field my display value for that table. A good example of this is the ‘Name’ field on the user table. What you see is the full name of a user. If you look at the dictionary entry for that field however, you’ll see that it is actually a calculated field that pulls together the values from the First name, Last Name, and Middle Name fields.
Once this is done (and I’ve updated all of the records in the table so that my calculation gets stored on each record) I can make this field my display field for the table and change how searches are performed on references to that table. By using a ‘Contains’ type of search instead of the default ‘Starts with’ type of search against the display value for a table I can effectively search on multiple terms in the same field since I’ve included them in the same display value string. This article explains how to set up a ‘Contains’ autocomplete search for a particular table.

Customizing Autocomplete Search Behavior

Another useful option for reference fields is to display additional attributes in the autocomplete drop-down. These attributes aren’t searchable and they won’t show up as the display value when the field gets populated, but they do make it very simple to display more than just the display value in an autocomplete.

Display Additional Reference Field Attributes

The post Multiple Reference Display Values Per Table appeared first on ServiceNow Guru.

String fields typically aren’t anything to get too worked up over, but I’ve discovered a couple of cool tips on dealing with string fields in ServiceNow that might benefit somebody else at some point.

The first tip is to know what the difference is between a single-line text field and a multi-line text field in ServiceNow. It’s obvious when you look at them, but there are some details under the hood that you might not know about. The driver of these differences is the ‘Max Length’ value that you set on the dictionary entry for the string field. Any string field with a max length value less than or equal to 255 will be rendered as a single-line text field. As soon as you hit 256 or more characters for the max length, the field is changed to a multi-line text field.

The second tip is to understand what this does at the database level in a MySQL database. A field with a max length value less than or equal to 255 is designated as a ‘CHAR’ datatype in the database. The DB won’t accept a max length greater than what you specify for these fields.

As soon as your max length is 256 or more however, the field changes to a ‘VARCHAR’ datatype. The maximum length of one of these fields doesn’t have a direct correlation to the max length specified on the dictionary entry. There is a formula for where the max length ends for VARCHAR fields, but it’s typically so large that for all intents and purposes you can put as much information in one of these fields as you need.

The third tip is to understand what happens in the client-side interface for these fields. Any single-line field will be rendered as an ‘INPUT’ HTML element on the form. ‘INPUT’ elements have an attribute included called ‘maxlength’ that you can use to limit the number of characters that can be added to the field. ServiceNow uses the dictionary setting when it renders the HTML for these fields.

With a multi-line text field things work differently. These are rendered as a ‘TEXTAREA’ HTML element on the form. HTML doesn’t include a ‘maxlength’ attribute for these fields so you can input as many characters as you want into one of these fields. The only way to work around this HTML limitation is to set up a client script to limit the number of characters allowed.

Shown below are a couple of ‘onLoad’ client scripts that I’ve used before to force a maximum length for a multi-line text field in ServiceNow. Both are designed to work on the ‘comments’ field on any of the ‘Task’ tables.

The first is an example I came up with just for fun. It displays a counter text box that shows the number of characters left. It also changes the background color of the field at specified intervals. Probably a little bit overkill but it gives you a lot of possibilities. I actually had some sound effects with it at one point!

function onLoad() {
//Create the counter field and line break
var counterBreak=document.createElement('br');
var counter=document.createElement('input');
counter.id='counter';
counter.type='text';
counter.readOnly=true;
counter.size='4';
counter.maxlength='4';
counter.value='500';

//Create a text node to be a label for the counter
var counterLabel = document.createElement('text');
counterLabel.innerHTML=' characters left';

//Use the 'onkeyup' event to check the 'isMaxLength' function
//Get the control
var control = g_form.getControl('comments');
//Add the nodes to the form
var controlParent = control.parentNode;
controlParent.appendChild(counterBreak);
controlParent.appendChild(counter);
controlParent.appendChild(counterLabel);
//Set its onkeyup method
control.onkeyup = isMaxLength;
}

function isMaxLength() {
var mLength=500;
var control = g_form.getControl('comments');
var countControl = gel('counter');
if (control.value.length >= mLength){
//If number of characters exceeds maxLength then trim the value
control.value = control.value.substring(0, mLength);

//Flash the label for the comments field red for 4 seconds and change field background color
g_form.flash('new_call.comments', '#FF0000', -4);
g_form.getControl('comments').style.backgroundColor='red';
}
// otherwise, update 'characters left' counter
else{
//Change the background color of the field depending on characters left
if(control.value.length <= 200){ g_form.getControl('comments').style.backgroundColor=''; } if((control.value.length > 200) && (control.value.length <= 400)){ g_form.getControl('comments').style.backgroundColor='yellow'; } if(control.value.length > 400){
g_form.getControl('comments').style.backgroundColor='orange';
}
}
countControl.value = mLength - control.value.length;
}

Here’s a simplified example. It just shows an error message when the Max Length for the field is reached.

function onLoad() {
//Use the 'onkeyup' event to check the 'isMaxLength' function
//Get the control
var control = g_form.getControl('comments');
//Set its onkeyup method
control.onkeyup = isMaxLength;
}

function isMaxLength(){
var mLength=500;
var control = g_form.getControl('comments');
if (control.value.length > mLength){
g_form.hideErrorBox('comments');
g_form.showErrorBox('comments', 'You have reached the maximum character limit for this field.');
control.value=control.value.substring(0,mLength);
}
else{
g_form.hideErrorBox('comments');
}
}

Putting it all together in a global UI script…

The above scripts work well enough if you’re just using this for a single field on a single form. It’s often better to create a global UI script that you can call if you’re going to use the function fairly often. The following script can be pasted directly into a UI script in your system. Once it’s in place, you can add a Max Length field check to any string field or catalog variable by using the following…

setMaxLength(‘[FIELD_OR_VAR_NAME]’, [MAX_LENGTH]);

function setMaxLength(fieldName, mLength){
$(g_form.getControl(fieldName).id).observe('keyup', isMaxLength.bind(this, fieldName, mLength));
}

function isMaxLength(fieldName, mLength){
var control = g_form.getControl(fieldName);
if (control.value.length > mLength){
g_form.hideErrorBox(fieldName);
g_form.showErrorBox(fieldName, 'You have reached the maximum limit of ' + mLength + ' characters for this field.');
control.value=control.value.substring(0,mLength);
}
else{
g_form.hideErrorBox(fieldName);
}
}

The post Max Length on Large String Fields in ServiceNow appeared first on ServiceNow Guru.

Let’s say that I’m in the middle of a Change management deployment and I’m using the ‘Configuration item’ field on my Change form. At the same time, my company is trying to roll out Incident management so there’s also someone from another department trying to make configuration changes to the ‘Configuration item’ field on the Incident form. The Incident management process says that the Configuration item field is optional while Change management says that it should be mandatory. Incident management has a very complex reference qualifier for the field, but Change management doesn’t want a reference qualifier at all. Since there is only one dictionary entry for the Configuration item field, we can’t both have our way if we are making configuration changes on the dictionary entry. Below are a few of the common scenarios where you might see this problem and how you can make it work for all tables that access the shared field.

1- Mandatory fields:

Although there is a checkbox on the dictionary table to make a field mandatory, it should be used ONLY when the field in question should always be mandatory in every situation for every table that uses the field. As this is very rarely the case, it’s usually much more effective just to make the decision early on to use UI policies or Client scripts to make the field mandatory when it should be.

2- Read-only fields:

See #1. The solution to this problem is a little bit different though. Because security in ServiceNow can be applied in a few different ways, you’ll want to make sure to evaluate the options closely. Most of the time, Access Control Rules are your best bet through the System Security application. Depending on the situation (and how critical it is to secure the field in question) you may want to use a UI policy or a Client script to restrict access to the field. Just remember that UI policies and Client scripts only secure an object when it is loaded on the form which may leave your field open via list editing or some other method.

3- Reference qualifiers:

If the field in question is a reference field, then it’s very likely that you’ll end up using a reference qualifier to filter the records presented by the field at some point. If the tables sharing the field don’t all need the same reference qualifier (or if some don’t need one at all) then you’ll want to use an advanced reference qualifier. Constructed properly, an advanced reference qualifier gives you the ability to identify the querying table before reference qualifier is returned. This means that you can give each table its own reference qualifier, or no qualifier at all. Here’s a sample script that could be used for a Configuration item field shared between various task tables.

function myRefQualFunction() {
var answer;
switch (current.getTableName()) {
case 'incident':
answer = 'sys_class_name=cmdb_ci_computer^ORsys_class_name=cmdb_ci_service^';
break;
case 'problem':
answer = 'sys_class_name=cmdb_ci_server^';
break;
case 'change_request':
answer = 'sys_class_name=cmdb_ci_service^';
break;
case 'change_task':
answer = 'sys_class_name=cmdb_ci_service^';
break;
default: answer = '';
}
return answer;
}

4- Labels:

This isn’t a dictionary setting, but the concept here is the same. Before you go and personalize the label for a field, you really need to be aware of all of the places that field is used. Changing the label of the ‘Configuration item’ field on the Incident form to ‘Incident CI’ would work great for incidents, but not so great for Change requests. It is possible to set up a separate label entry for the same field on each individual extended table.

5- Default values:

There’s only one place to set a true default value for a field…the dictionary entry for the field. Client scripts can set default values, but that value is only applied when the form loads for a particular record. Here’s a script that I’ve used before to set different default values for the ‘State’ field on the Task table. You would place this in the ‘Default value’ field on the dictionary entry of the field in question.

javascript:
switch (current.getTableName()) {
case 'incident': '1'; break;
case 'problem': '2'; break;
case 'change_request': '1'; break;
case 'change_task': '-5'; break;
default: '1';
}

6- Choice lists:

It’s very easy just to right-click on a choice field and select ‘Personalize choices’. While this option is very simple, it doesn’t always supply you with all of the information you need to make an informed decision about how and where the choice should be added. By selecting ‘Show choice list’ you can see exactly how the choice list is set up for all tables involved. Personalizing choices for a choice field is very straight-forward, you just need to be sure of the scope of the choices you are personalizing. A ‘State’ value of ‘Pending acknowledgment’ may make perfect sense in the Incident world, but might not be useful or needed for a Change task. Fortunately, you can specify unique choice values for each extended table that shares the same field.

The post One Field Shared Between Many Tables appeared first on ServiceNow Guru.