Contents

1 Document Administration ....................................................................................................................... 3

2 Purpose................................................................................................................................................... 4
3 Solution check list ................................................................................................................................... 5
4 Coding requirements and standards ...................................................................................................... 6
4.1 Coding Requirements ...................................................................................................................... 6
4.1.1 Performance ............................................................................................................................. 6
4.1.2 Security .................................................................................................................................... 6
4.1.3 General checkpoints ................................................................................................................ 7
4.2 Coding Standards ............................................................................................................................ 7
4.2.1 Commenting ............................................................................................................................. 7
4.2.2 Spacing .................................................................................................................................... 8
4.2.3 Simple statements .................................................................................................................... 9
4.2.4 IsLoading check ..................................................................................................................... 10
5 Best Practices ....................................................................................................................................... 11
5.1 Global vs Scoped Applications ...................................................................................................... 11
5.2 Custom tables................................................................................................................................ 11
5.3 Design/style guide ......................................................................................................................... 12
5.4 Naming convention ........................................................................................................................ 12
5.5 Client Side Coding Best Practices ................................................................................................ 16
5.6 Logging for Debugging Best Practices .......................................................................................... 19
5.7 Orchestration/Workflow Best Practices ......................................................................................... 19
5.7.1 Coding Best Practices ............................................................................................................ 20
5.7.2 Final Tips for Orchestration Success ..................................................................................... 20
6 Reusability ............................................................................................................................................ 22
6.1.1 Create Small, Modular Components ...................................................................................... 22
7 Self-documentation ............................................................................................................................... 23
7.1 How to use ..................................................................................................................................... 23
7.1.1 Support/Release/Change Documentation ............................................................................. 24
8 Making updates to OOTB ..................................................................................................................... 25
8.1 Best practice for updating OOTB objects ...................................................................................... 25
8.2 Reverting changes to OOTB ......................................................................................................... 25
8.2.1 Clean up the object version ................................................................................................... 25
8.2.2 Update set impact .................................................................................................................. 27
9 General Tips ......................................................................................................................................... 28

Page 1 of 26
1 Document Administration

I.Document Approvals

II.Version Control
Version Author(s) Description of Change Date
01. Braj Bhushan Initial version 11/11/2023
Tamrakar

III.Document Review
Reviewed by Comments Date

IV.Related Documents
The following documents can be used for more information and detail related to the standards described
in this document:

Document Type Name

Page 2 of 26
2 Purpose
The purpose of this document is to define the standards that developers should use when working on
ServiceNow instances.

By adhering to a known set of standards, the following benefits can be obtained:

1. Improve code consistency

2. Improve code understanding
3. Reduce development time
4. Reduce defects
5. Reduce maintainability effort

The document is intended to be a “living document” and be regularly updated as more design patterns
are added.

Page 3 of 26
3 Solution check list
Is ServiceNow the right solution for this requirement? It may be better to push this requirement into
another platform or system. Use the following as a guide.

Page 4 of 26
4 Coding requirements and standards
All developers should obtain access to the ServiceNow Developer Portal (free account). Along with
documentation, forums and tutorials, it also provides access to a developer instance that can be used as
for debugging/testing. The recommendations below come directly from the Developer Portal and the
ServiceNow Health Check tool.

4.1 Coding Requirements

The following are a list of best practice code requirements.

4.1.1 Performance
o Large scripts (larger than 500 lines) should be converted into script includes wherever
possible.
o Queries should not exceed out of box transaction quota rules. (sysrule_quota_list.do)
o Recursive Business Rules must not be used.
o Client-side code to fetch data from server should always use Glide AJAX with a callback
function (See section Client Side Coding Best Practice).
o The current.update() method should not be used in an onBefore Business Rule/ Transform
script.
o A module that links to a known large table should have a filter. If the module displays the
records of a large table (>50,000 records), you must add a filter. Unfiltered lists can be very
slow to load, causing performance issues and a poor user experience.
o DOM manipulation is not allowed.
o The default "system" user preference for "rows per page" should be set to 20 or less.

4.1.2 Security
o Integration roles should only inherit the roles for the purpose of that integration. admin, itil,
soap_ecc etc. should not be used for Integration User Roles.
o There must be no hardcoded URLs or passwords in the application code.
o Inbound web services that modify tables should be restricted to appropriate roles.
o Each scoped app/module should have at least one role defined.
o Always use the default ServiceNow APIs such as Glide Form, Glide System, GlideRecord,
GlideRecordSecure and other. Custom code should not be substituted for handling these.
o Test code, logs or any other content, which is not intended for production use, must be
removed from your application.
o Input parameter validation should be server side for sensitive data and secure elements. (All
the validation failures should result in input rejection. Validate for expected data type and
data range.)
o Always escape output in jelly.
o Encrypt Sensitive data with Password2 or encrypted_text type for sensitive data.
o Any inbound and outbound calls to external domains & IPs must be documented.

Page 5 of 26
 o Do not send sensitive information over http.
o Protect tables, UI pages, Property pages and other content with proper ACLs and roles.
o Make sure proper ACLs are set for:
▪ Record (Both list and record view)
▪ Client_Callable_Script_Include
▪ Processor
▪ ui_page
o Please use Scripted REST API or web service as integration end points. Don’t use
Processors as integration end points in ServiceNow.

4.1.3 General checkpoints

o You should include a dedicated integration user (not “admin”) that external systems will use
to integrate with the ServiceNow instance during authentication.
o All scripts used in the app must use proper error handling.
o Avoid using additional frameworks, if needed, all languages supported by the app must be
clearly documented. (Ex: additional JS frameworks)
o Import set tables must be used for writing data into ServiceNow tables from external source.
It should not be used for querying a table.

4.2 Coding Standards

The following coding standards come from the ServiceNow Developer Portal section Technical Best
Practices.

4.2.1 Commenting
• Single line comments start with a double forward slash (//) and can be placed anywhere on the
line.
• Everything after the // and up to the new line is considered a comment. For example:

// Initialize variables
var count = 0;

if (count > MAXVAL) // Check if we are over the limit

• Use comments liberally – the goal is for another developer (or future self) be able to quickly view
a section of code and understand its function!
• Block comments start with a forward slash and one asterisk (/*) and end with the reversed
combination (*/).
• Everything between the markers is considered a comment. Adding extra asterisks, like those

Page 6 of 26
 shown in this example, can make it easier to locate blocks of comments.

/***
* getRiskEnvironment - determine the environment of the CIs to calculate the risk
*
* @param: chg - GlideRecord of change record
* @return: result - Highest environment value of CIs: 1=production, 2=QA, 3=test, 4
=dev, 0=error
*
***/

• Clearly describe the purpose of functions and all inputs and outputs. For example:

/***
* putUserPref - save a user preference/value pair for this user
* If the preference already exists, check the current value and update
if necessary
*
* @param prefName - name of the user preference
* @param prefVal - string value to save
* @return - None
*
***/

NB: See section on Self-documenting which explains how to add block comments to self document
functions.

4.2.2 Spacing
• Use empty lines and TABs to make code more readable.
• The easier it is to read code, the easier it is to identify and correct issues.
• Empty lines help visually group blocks of code together so the reader can see the logical
organization.
• Spaces on each line help make the items on an individual line easier to read.
• The format code button in the ServiceNow syntax editor toolbar is a useful tool for adjusting
indentation without altering other spacing.

/***
* putUserPref - save a user preference/value pair for this user
* If the preference already exists, check the current value and update
if necessary
*

Page 7 of 26
 ***/

function putUserPref(){
// Put spaces between parameters and before curly brace

var newRel = new GlideRecord('cmdb_rel_ci');

// Put spaces around '='.
var newrelType = new GlideRecord('cmdb_rel_type');
// Optionally, put additional spaces to align '=' w/previous line.
var relTypeID;
// Group variables together where appropriate

if (childCI == parentCI){
// Put a space after 'if' and around operators ('!=')
return;
}

if (newRelType.get(relType)) {
// Use extra blank lines to help break up chunks of code and improve readability

relTypeID = newRelType.getValue('sys_id');

newRel.initialize();
// Group similar statements together
newRel.setValue('type', relTypeID);
newRel.setValue('child', childCI.getValue('sys_id'));
newRel.setValue('parent', parentCI.getValue('sys_id'));
newRel.insert();
}
}

4.2.3 Simple statements

• Make your code as easy to maintain as possible. In general, it is the compiler’s job to make code
fast, so minimize the use of fancy tricks.

Complex:

var result = (x == y) ? a : b;

Simple:

var result;
if (x == y) {
result = a;
}

Page 8 of 26
else {
result = b;
}

4.2.4 IsLoading check

For client scripts, “isLoading” check is mandatory. If it is required for your implementation to have a client
script of type “onChange” run on form load, implement the following line to acknowledge the isLoading flag
but continue processing:
if (isLoading) {}; // run during loading

Page 9 of 26
5 Best Practices

5.1 Global vs Scoped Applications

There are two use cases when considering application scope: extending an existing app or creating a
custom app from scratch. If you are extending or modifying an existing global scope application and the
changes are having a high impact on other applications, then leave the change in the global scope.
However, if the changes are going to have less impact to other applications, then the modifications can
be done as a scoped app.

When you are creating a new application from scratch, you should be creating it as a scoped app.
ServiceNow's product strategy is to develop more and more scoped apps to make it easier for customers
to deploy the application and to simplify future upgrades. Also, backing out changes to scoped apps is
much simpler and can be done with a single push of a button.

All Now Platform core services (such as workflow, business rules, and UI policies) that are available in a
global scope are also available in a scoped app. Global artifacts like tables and scripts that are marked as
accessible from a global scope are available in a scoped app. However, there are a few out-of-the-box
APIs that do not work currently in a scoped app, see list

https://developer.servicenow.com/dev.do#!/reference/api/quebec/server/no-namespace

5.2 Custom tables

Madrid version of ServiceNow introduces a new subscription model whereby new custom tables have a
licensing implication. This will only impact customers once they upgrade to Madrid or beyond.
ServiceNow have mentioned that customers with existing custom tables can be exempted via a

Page 10 of 26
‘grandfathering’ arrangement, but each case may be different and it’s a discussion for the customer to
have with their account manager.

This means the creation of new custom tables should be evaluated to determine the license
implications.

The decision to create custom tables should be raised with the ServiceNow Product Owner/Platform
Architect / Architecture Review Board.

5.3 Design/style guide

The ServiceNow user interface contains different elements, the following style guide explains those
elements and their default values http://designsystem.servicenow.com

5.4 Naming convention

The company prefix is “AVATU”.

• Client scripts

<<company prefix>> - <<description>>

Example: AVATU – onLoad set manger name

Note: For the description, lead with the type of action being performed e.g. onLoad, onChange,
onSubmit etc

• Script includes

Use PascalCase notation

<<company prefix>><<FunctionDescription>>

Example: AVATUUserHelper
Note: Use “Helper” for script includes that help a particular function e.g. AVATUUserHelper,
TaskHelper etc

• UI Script

Use snake case notation

<<company prefix>>_<<function_description>>

Example: Avatu_user_functions

• UI Page

Use snake case notation

Page 11 of 26
 <<company prefix>>_<<function_description>>

Example: Avatu_user_login

• UI Macro

Use snake case notation

<<company prefix>>_<<function_description>>

Example: Avatu_user_form

• Business Rules

<<company prefix>> - <<description>>

Example: AVATU - User Events

Note: Set the order value – unless there is any order dependency, AVATU BRs should start at 2000 –
Don’t use 100, standard incremental value 10.
Use description names to make scanning a list of BR’s for meaning easier.

• Constants

Use snake case notation, all uppercase

Example: USER_INFORMATION

• Class

Use PascalCase notation

<<company prefix>><<function_description>>

Example: AVATUUserHelper

• Variable

Use camelCase notation

<<functionDescription>>

Example: userName

Page 12 of 26
• Function

Use PascalCase notation

<<company prefix>><<function_description>>

Example: AVATUgetUserName
Note: A function is available in the global scope (e.g. used within client scripts) and therefore should
have the company prefix to ensure uniqueness and prevent scope clash.

• Method

Use camelCase notation

<<company prefix>><<method_description>>

Example: getUserName
Note: A method is used within script includes so company prefix is not required (given it is scoped
within the script include class).

• Tables

Use PascalCase notation

u_<<description>>

Example: War Room

Note: Table names should be singular e.g. War Room (u_war_room) as opposed to War Rooms
(u_war_rooms).

• Fields

Use sentence case notation

<<description>>
Example: Affected contact

• Choice Lists

Setting up choice lists includes:

• Using only letters, numbers, and underscores in choice list options.

• Double-checking the Value field for special characters.
• Referencing choice lists for repetitive options.

• System Properties

Use dot notation and

Page 13 of 26
 • Use system properties instead of hard-coded values.
• Group properties into categories.
• Create properties pages.

Example: Avatu.<<function>>.property
Note: Multiple dots can be used to separate sub sections of a property where required.
E.g. Avatu.service_provider.request.email
Avatu.service_provider.request.phone

• Groups

Define: Groups Hierarchy and Type

Example: Application Development

• Roles

Use snake case notation and customer prefix.

<<company prefix>>_<<role_description>>

Example: Avatu_approval_admin

• Notifications

<<company prefix>> - <<description>>

Example: AVATU - Incident commented for ITIL

Note: Use a description which indicates the table and action being performed.

• Email templates

Use dot notation

<<company prefix>><<table>><<template>>

Example: Avatu.incident.header.comments.details

• SLAs
<Ticket priority>-<Table/ticket type>-<ReSPond or ReSolVe SLA>-<Business Unit /
Service><space><Description to capture Contract / Region and other details>

Examples:

P1-INC-RSP-OPS UK

Page 14 of 26
 P1-INC-RSV-OPS UK

• Knowledge articles
<<Document Type>> - Description

Example:
Customer Service – How to login via ClinPhone

• Scheduled Jobs
<< company prefix>> - Description

Example: AVATU-CMS Daily Job

Note: Set the “run as user” to be system or a generic user

• Service Portal Widgets

<< company prefix>> - Description

Example: AVATU-Widget xxx

• Orchestration (Workflows, Flow)

<<company prefix>> - <<description>>

Example: AVATU - User Events xxx

5.5 Client-Side Coding Best Practices

• In general, UI policies should be used before using a client script. For example, when you need
to control visibility/mandatory/read-only.
• UI policies and client script should make use of the “Order” attribute to ensure they run in a
defined sequence. The order attribute should start at “2000” and increment by 10.
• When data is needed to be returned from the server there are two approaches:
1. GlideAjax:

Page 15 of 26
// Client side onChange function
function onChange(control, oldValue, newValue, isLoading) {

if (isLoading || newValue == '') {

return;
}

var ga = new GlideAjax('asu_GetLocationData');

ga.addParam('sysparm_name', 'getCampus');
ga.addParam('sysparm_buildingid', g_form.getValue("u_building"));
ga.getXML(updateCampus);
}

function updateCampus(response) {
var answer =
response.responseXML.documentElement.getAttribute("answer");
var clearvalue;
if (answer) {
var returneddata = answer.evalJSON(true);
g_form.setValue("campus", returneddata.sys_id,
returneddata.name);
} else {
g_form.setValue("campus", clearvalue);
}
}

Page 16 of 26
// Server side Script Include:
var asu_GetLocationData = Class.create();
asu_GetLocationData.prototype =
Object.extendsObject(AbstractAjaxProcessor, {
getCampus: function () {
var buildingid = this.getParameter('sysparm_buildingid');
var loc = new GlideRecord('cmn_location');
if (loc.get(buildingid)) {
var campus = new GlideRecord('cmn_location');
if (campus.get(loc.parent)){
var json = new JSON();
var results = {
"sys_id":
campus.getValue("sys_id"),
"name": campus.getValue("name")
};
return json.encode(results);
}
} else {
return null;
}
}
});
2. GetReference with callback:
// getReference with a named callback:
g_form.getReference(‘assignment_group’, doGroupCallback);

function doGroupCallback(group){
g_form.setValue(‘email_address’, group.email);
}

Page 17 of 26
 // getReference with anonymous callback function:
g_form.getReference(‘assignment_group’, function(group) {
g_form.setValue(‘email_address’, group.email);
}

// getReference with a named callback:

g_form.getReference(‘assignment_group’, doGroupCallback);

function doGroupCallback(group){
g_form.setValue(‘email_address’, group.email);
}

5.6 Logging for Debugging Best Practices

Use logging properties/scripts so that logging levels can be controlled across environments.

5.7 Orchestration/Workflow Best Practices

These best practices are meant for Orchestration projects, but you can also apply them to workflows:
OoB functionality should be used before custom code and configuration should be used before custom
code.

1. NEVER delete a workflow version. Set a workflow version to inactive instead.

2. When using the Create Task or Run Script activities, avoid creating a record on the same table as
[Table] used in workflow version. Doing so will cause an infinite loop.
3. Avoid using gs.sleep on any of the workflow activities. The gs.sleep does not release session; the
workflow will hold on to the thread; the instance will run out of worker threads for other jobs. Use a
Workflow Timer activity instead of gs.sleep.
4. Use system properties to configure the workflow. If you have a constant in your script, move it to a
system property. Benefits include the ability to make on-the-fly changes without the need to check out
the workflow and the ability to store the value in a format other than plain text.
5. Remove workflow input variables prior to going to production. Use workflow.scratchpad or system
properties and be sure to use input variables for unit testing purposes only.
6. Consider using a primary workflow and then building out sub-workflows for each task grouping. This
allows you to "build" upon existing functionality and reduces workflow complexity.

Page 18 of 26
5.7.1 Coding Best Practices
1. Use a Run Script Activity at the beginning of the workflow to initialize your workflow scratchpad
variables (including system property gets) to be used downstream.
2. Create a library of functions using a Script Include(s) for reuse.
3. Use code to call Script Includes (Helper) to retrieve data, operate on data or where involved
processing needs to occur.
4. Use a Set Values Activity or Run Script to update the current object. If a Run Script is used do
not use current.update().
5. Handle errors in Try/Catch blocks.
6. Use JSUtil.nil()/.notNil() <string>.nil() in condition statements.
7. When converting a value to a String, use getValue(<field>), but remember that getValue() cannot
dot-walk.
8. If you need workflow debugging, set the system property glide.workflow.log.debug to true and use
workflow.debug during testing.
9. Comment your code

5.7.2 Final Tips for Orchestration Success

To finish off, remember to keep things simple and straight-forward when you're creating an
Orchestration workflow and code. Comments and standards keep the number of hours spent in
maintenance to a minimum. Last but not least, the following points should be followed:

1. Consistency of the workflow, coding best practices and variable usage are the key to reusable
and maintainable code!
2. Your changes to a workflow are not placed into the current update set until you publish.

Page 19 of 26
6 Reusability
6.1.1 Create Small, Modular Components

• Break your code into modular components or specialized functions. Script Include functions are
excellent examples of this technique. Script Includes are essentially libraries of functionality that can
be implemented in other server-side scripts, such as Business Rules, UI actions, and Script Actions.
Some of the benefits of specialized functions include:

o They are easy to create because they are small and simple with limited functionality.

o They are generally simpler and shorter, so it is easy to understand the logic, inputs, and
outputs. This makes it easier for the next person who works with the code to make
modifications.

o They are easier to test. As a related note, when you test the code, be sure to test both valid
and invalid inputs to ensure the script is as robust as possible. As you create small
specialized functions, keep in mind how the small bits fit together in a larger construct. For
example, you may find that doing a query of the same data inside ten separate functions is
not database-friendly, and that a different approach is necessary.

o Make the code available to other functionalities

Page 20 of 26
7 Self-documentation
In an effort to improve code understanding and reduce maintenance, a self-documentation tool can be
trialled for the ServiceNow Project. The tool is available from the ServiceNow developer store and
functions similar to industry recognised JSDoc.

7.1 How to use

To use the self-documentation tool simply mark up your code (classes/methods/functions) with the
following comments example.

/**SNDOC
@name Log
@description Logging function with level determined by parameter. Will log message to ServiceN
ow logs at the specified level.
@param {string} [msg] - Message to be logged into ServiceNow Logs at the Debug level
@param {string} [level] - Level for the message to be logged at. Defaults to Debug level. Leve
ls are 'debug','info','warn' or 'error'
@param {string} [id] - Unique Identifier for tracking series of logs.
@example
*/

Page 21 of 26
 • Documentation is live, there is no need to run a specific process to update the
documentation, just open up a portal to see the latest documentation
• Documentation relies entirely on the comments that you create

7.1.1 Support/Release/Change Documentation

Above Documentation Portal can support static documentation, this documentation is extracted and
stored at a point in time to be displayed

7.1.1.1 Update Set Documentation

Process to retrieve changes from update sets (sys_update_set) based on the same logic above.
Description field to include required information for change request.

Page 22 of 26
8 Making updates to OOTB
The ServiceNow platform delivers baseline functionality for licensed applications which can be
configured from OOTB (out of the box) with no customisations to get the customer up and running very
quickly, once the customer’s data has been loaded. However, there is usually a requirement for
ServiceNow consultants to review the customer’s business processes and perform some additional
development to tailor the platform to suit the customer’s business needs, which means changing OOTB
objects which impacts on future upgrades.

8.1 Best practice for updating OOTB objects

In brief, ServiceNow have changed their stance on the best practice method to update OOTB objects
(this is mainly with reference to the classic platform and “sys_” prefixed objects.) It used to be that
ServiceNow recommended always cloning the original object and setting the original to inactive (where
applicable) but this position has changed.

“Customizations should be made to baseline objects where necessary, so that conflict resolution and
decision making can be appropriately recorded in the updates. Hidden customizations may cause
administrators to overlook updates in future assessments in case reverts or merges are necessary.”

Refer KB0553407

8.2 Reverting changes to OOTB

When you have touched an OOTB (out-of-the-box) object and recorded an ‘invalid update’, because it
was a mistake, relates to a POC or for some other reason the update is not required, it is best practice to
revert the update back to original. When updates such as these are not reversed out in the right way, it
can cause confusion to other developers as you’ve left a trail behind. Did the developer intentionally
make an update which I should build on top of? How can I know that I’m updating a clean version of the
object? It shouldn’t be a problem left to the next developer.

Additionally, invalid updates such as this can impact on the upgrade process whereby “touched” objects
are reported as an upgrade conflict, even if you manually removed your changes but left the update
record in an update set which was moved through the landscape into PROD.

There's a two-step process to successfully remove all traces of an invalid update.

8.2.1 Clean up the object version

From the update set, open the customer update representing the invalid update, then access the Show
Related Record link (under Related Links), then Context Menu->Show Latest Update

Notice the ‘Replace on upgrade’ flag is currently empty…

Page 23 of 26
After performing manual updates in your code or relevant fields to restore the changes back to original,
this flag does not get ‘reset’.

We need to navigate to the Application File for the object in question to reveal all recorded versions.

From the customer update record, the navigation path is - Show Related Record link (under Related
Links), then Context Menu->Show File Properties

Click on the linked Name field where the source is the original version (in the example above it’s the
record where the source is “System Upgrades…”)

Now we are on the Update Version form. From here, click the “Revert to this version” link (under
Related Links)

The version list has now been updated to reflect that the current version is now the original version as it
has been restored.

Page 24 of 26
The ‘Replace on upgrade’ flag which was showing as empty earlier, has now been updated to reflect that
this object should be replaced in an upgrade.

We are not done until all customer updates for the object in question are removed from in-flight update
sets. The revert action which we just performed is not recorded as a customer update.

As a side note, the revert operation might be represented differently if the object was installed as a
store application, in which case you access the ‘Revert to Store App’ link under Related Links.

8.2.2 Update set impact

It is not necessary to remove updates relating to customisations which have been reversed. Add steps
here on how to move an invalid update to ‘Global’ if developers are not sure.

Page 25 of 26
9 General Tips
• Be wary that ServiceNow server side uses Mozilla Rhino and supports up to ES5 whereas client
side (browser) javascript uses ES6. This means there could be functions available in the browser
(ES6) that are not available on the server (ES5). If unsure if a server side javascript function is
available – test in a background script.

• When workflows are not required to be run in a server-side script, use setWorkflow(false)

• When glide record is not required to have last updated/created changed via a script, use
autoSysFields(false)

• The Glide Element function getRefRecord can be a more efficient way to get a referenced field
rather than querying for it.

• The Glide System function nil() can be used to test if an object is null, undefined or empty.

• The Glide Record function of getValue and setValue should always be used for getting and
setting values.
Server-side GlideRecord objects contain an element for each field on the record. These elements
are not primitive values (strings, numbers, Booleans), but Objects. The type of object is
GlideElement, and the usual GlideElement API is available. However, since JavaScript is a
loosely typed language, you can reassign a variable of one data-type (such as an Object) to
another type (such as a string). Thus, setting a GlideRecord (gr) element's value to a string will
overwrite the reference to the GlideElement object itself. This bad-practice example would look
like:
gr.short_description = 'New short desc.';
This would replace the GlideElement object with a string. This is not good.
Technically, Rhino (the server-side implementation of JavaScript that ServiceNow uses) handles
this on the server so we can't overwrite the GlideElement object with a string like this, but it's still
best practice not to write our code like this.

• The ServiceNow Developer Portal has an excellent list of API reference functions.

Page 26 of 26