Scripting in ServiceNOW

In ServiceNOW there can be scripts written at the server side or the client Side:
Server side scripting include:
  1. UI Actions
  2. Business Rules 
  3. Script Includes
Client Side Scripting include:
  1. Client Scripts
  2. UI Policies
  3. Data Policies
1. Client Script:

Client-side scripts execute within a user’s browser and are used to manage forms and form fields. Examples of things client-side scripts can do include:
  • Place the cursor in a form field on form load
  • Generate alerts, confirmations, and messages
  • Populate a form field in response to another field’s value
  • Highlight a form field
  • Validate form data
  • Modify choice list options
  • Hide/Show fields or sections

Client Scripts can be written either by accessing client scripts from the configure option on the form header or from the application navigator.
The different types that are available are
  • onLoad - The script is executed when the form is loaded
  • onCellEdit - Runs the script when we try to change any cell from list view
  • onChange - Runs the script when there is a change on specific field
  • onSubmit - Runs the script when the form is submitted
Client Scripts can be applied to only for one view and we need to specify the view to which the client script should be applied. If global is selected this script is applied to all the views.

Client Scripts can also be inherited on to other tables which extend to the table https://developer.servicenow.com/app.do#!/lp/servicenow_application_developer/app_store_learnv2_scripting_istanbul_exercise_test_client_script_types?v=istanbulon which we create the client script.

Onload and onSubmit doesnt have any parameters passed to it, but onChange has some parameters to it.

function onChange(control, oldValue, newValue, isLoading, isTemplate){
// This is mandatory to ensure that the script doesnt execute when the onChange is called on loading
      if(isLoading || newValue == '')
         return;
}

  • control: The field for which the onChange is configured
  • oldValue: Value saved in the DB. This doesnt change with the intermittent values entered.
  • newValue: The  value to which the user has changed to.
  • isLoading: boolean value to indicate the onChange is called when the form loads.
  • isTemplate: If the change is from a template.
GlideUser and GlideForm are the only two classes that we can use in the script.

GlideForm Class:
The GlideForm client-side API provides methods for managing form and form fields including methods to:
  • Retrieve a field value on a form
  • Hide a field
  • Make a field read-only
  • Write a message on a form or a field
  • Add fields to a choice list
  • Remove fields from a choice list
The GlideForm methods are accessed through the global g_form object that is only available in client-side scripts. To use methods from the GlideForm class use the syntax:
 
g_form.<method name>


To see all the method the API link is below
https://developer.servicenow.com/app.do#!/api_doc?v=istanbul&id=client





GlideUser Class:


The GlideUser API provides methods and non-method properties for finding information about the currently logged in user and their roles. The typical use cases are personalizing feedback to the user and inspecting user roles. Note that client-side validation in any web application is easily bypassed.
The GlideUser API has properties and methods to:
  • Retrieve the user’s
    • First name
    • Full name
    • Last name
    • User ID
    • User name
  • Determine if a user has a particular role assigned
The GlideUser methods and non-method properties are accessed through the global g_user object that is only available in client-side scripts. To use methods and properties from the GlideUser class use the syntax: 

g_user.<method or property name>

The g_user.userID property contains the record’s sys_id. Every record has a 32-character unique sys_id.

The GlideUser API also has methods for determining if a user has a specific role. For example:
g_user.hasRole('client_script_admin');
 
 
2. UI Policies:
 
 Like Client Scripts, UI Policies are client-side logic which governs 
form and form field behavior. Unlike Client Scripts, UI Policies do not 
always require scripting.
 
UI Policy Actions are client-side logic in a UI Policy used to set three field attributes:
  • Mandatory
  • Visible
  • Read-only