Avoid coding pitfalls

Experiment in a Sandbox

Trying out new coding ideas or concepts in a development instance can lead to messy results later on. If you make changes, then alter your approach while using an update set, you may find unwanted changes getting in the update set and being promoted to other instances. If you do not use an update set for your proof of concept, your development instance may behave differently than your other instances, making it difficult to verify defects and fixes.

If you do not have a sandbox environment available, use a ServiceNow demo instance. When you understand how to implement the new concept in a sandbox, build the solution in development.

Code in Stages

Do not attempt to write hundreds of lines of code in one sitting. This is especially true if you are learning a new technology. Write a few lines of code at a time and test as you go to ensure it works as expected.

Although this process may seem slow and tedious at first, it is ultimately more effective. If you try to write too much code at one time, it becomes difficult to locate the source of a problem. Instead of tracking back through lines and lines of code to find the defect, save time and effort by incrementally writing functional code.

Do Not Use Hard-Coded Values

Avoid using hard-coded values in scripts, as they can lead to unpredictable results and can be difficult to track down later. Hard coding sys_ids is not recommended, as they may not be the same between instances. Instead, try looking up a value by reference or by creating a property and retrieving the value with gs.getProperty().

Hard-coding group, user, or other names often leads to problems when an organizational change occurs. For example, assume you assign a value of Service Desk to the script variable for a group name:

var taskID = '26c811f06075388068d07268c841dcd0';
var groupName = 'Service Desk';

The script will not function as expected when the group name changes from Service Desk to Help Desk. Instead, use a property:

var taskID = gs.getProperty('acme.default.task');
var groupName = gs.getProperty('acme.group.name');

Also consider the following example in which a workflow needs an approval from the IT director of Acme Corp. Sara, the former IT director, has been replaced by Dale. See why the initial approach of hard-coding Sara’s user information is not preferable.

Initial Approach

1. Create a user approval activity for Sara.
2. When Dale becomes the new IT director, update the workflow.

Better Approach

This method eliminates the need to add hard-coded data in the workflow.

1. Create a group, IT Director, and make Sara a member.
2. Use the Group Approval Activity.
3. When Dale becomes the new IT director, simply update the group membership instead of the workflow.

Avoid Dot-Walking to the sys_id of a Reference Field

It is not necessary to include the sys_id of a reference field when dot-walking, as in the following example:

var id = current.caller_id.sys_id; // Wrong

The value of a reference field is a sys_id. When you dot-walk to the sys_id, the system does an additional database query to retrieve the caller_id record, then retrieves the sys_id. This can lead to performance issues. Instead, use the statement.

var id = current.getValue('caller_id'); // Right

Use getDisplayValue() Effectively

When scripting, become familiar with the tables and fields you are using. Instead of using name, number, or other explicit field name used for the display value, use the method getDisplayValue(). Consider the following example:

var parent = current.parent.number;
var myCI = current.cmdb_ci.name;

You would be required to update this code if the display value requirement changes on either of these two tables. For example, the business now wants to display the CI’s serial number field instead of name. When someone changes the dictionary attribute on the Configuration Item [cmdb_ci] table, from name to serial_number, this code no longer reflects the current requirements. Instead, consider using the following code:

var parent = current.parent.getDisplayValue();
var myCI = current.cmdb_ci.getDisplayValue();

To determine which field on a table is used as the display value, inspect the dictionary entry for the table and note which field has a Display field value of true.