Do not use hard coded sys_id

What is hardcoding?

Hardcoding refers to the practice of embedding specific, fixed values directly into the source code of a program or script, instead of using variables or parameters. These hardcoded values are typically constants or literals that are explicitly written into the code.

Why is this an issue?

Hardcoding the sys_id of a record can introduce significant challenges in ServiceNow development. Embedding specific values directly into the source code, rather than utilizing variables or parameters, gives rise to issues such as:

Dependency Issues: If a hardcoded sys_id refers to a record that is deleted or altered, the code might fail unexpectedly, requiring further updates.

Increased Error-Proneness: Manually updating hardcoded sys_ids in multiple places can easily lead to mistakes, potentially breaking functionality or causing unintended data changes.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// Hardcoded sys_id for an incident
var hardcodedSysID = '3c741b2cdb20030044c8b07cc144b062';

// Create a new GlideRecord for the 'incident' table
var incidentGr = new GlideRecord('incident');

// Check if the incident with the hardcoded sys_id exists
if (incidentGr.get(hardcodedSysID)) {
    // Log a message if the incident is found
    gs.log('Incident found with sys_id: ' + hardcodedSysID);
} else {
    // Log a message if the incident is not found
    gs.log('Incident not found with the hardcoded sys_id: ' + hardcodedSysID);
    // Potential issue: Hardcoded sys_id may become outdated due to changes in the instance or data.
}

This code snippet illustrates the potential issues associated with hardcoding sys_id, including challenges in maintaining and updating the codebase, as well as potential complications during system updates or debugging processes.

How do I fix it?

To address this issue, ServiceNow has empowered developers to store arbitrary values using System Properties. Utilizing System Properties encourages developers to use meaningful names that align with a given context. The initial step involves creating a System Property, following these steps:

1. In the Filter Navigator, type and enter sys_properties.do.

2. Populate the fields accordingly:

   • Name: your_property_name.
   • Description: "Add a description that will identify what you are accomplishing".
   • Type: string.
   • Value: 1234567ABCDEF6789012345678901234 (your sys_id).

3. Double check if the fields are correct and Save.

After creating the new System Property, proceed to incorporate it into your code on the relevant record. While it is challenging to provide a universal example for every scenario, a best practice enforced by ServiceNow involves retrieving the property using the gs.getProperty() method:

1
var yourSysId = gs.getProperty("your_property_name");

The example above works for the Server-Side, but since there is no gs API in the Client-Side, there is an alternative way to get the System Property. A good way would be to apply the global object to store and retrieve values without making additional server calls:

1
2
3
4
g_scratchpad.yourSysId = gs.getProperty("your_property_name");

// Client Script
g_form.setValue("group", g_scratchpad.yourSysId);

A common scenario is initializing fields with default values. While many developers might resort to using Client-Side scripts like the one below:

1
2
3
function onLoad() {
  g_form.setValue("group", g_scratchpad.userID);
}

It is important to note that this is not always the best practice. Although there are ways to handle Client-Side scripts, it is more efficient to use the default value field of the dictionary entry.

For example, instead of manually inputting values, a construction like the following for a sys_id column in the Group table can be used:

1. In the Filter Navigator, type and enter sys_dictionary.do.

2. Populate the fields:

   • Table: sys_user_group
   • Type: String
   • Column label: UserID
   • Column name: u_user_id

3. In Default Value, add javascript:gs.getUserID().

This ensures that the column automatically indicates the sys_id of the person creating the record each time a new entry is added, improving performance by avoiding the loading of unnecessary Client-Scripts.

Limitations and Solutions

Frequently, the need arises to identify the originator of a record generated by a record producer. This information may be crucial for creating reports on catalog item frequency, triggering SLAs, or facilitating email notifications. However, there is a limitation in ServiceNow where the sys_id of the record producer is not automatically set in the generated record.

To overcome this limitation, a workaround involves utilizing a client script, specifically an onLoad client script, to set the record producer's sys_id in a variable. Below is an example of the JavaScript code for this workaround:

1
2
3
function onLoad() {
  g_form.setValue("this_item", g_form.getUniqueValue());
}