Client scripts
Summarize
Summary of Client scripts
Client scripts in ServiceNow enable running JavaScript in the user's web browser to respond to client-side events such as form loading, field changes, or form submission. They are designed to enhance the user experience by dynamically controlling form behavior, field visibility, read/write status, mandatory conditions, field values, choice list options, and displaying messages. However, client scripts are not a security measure and should not be relied upon to restrict data access; instead, use ACLs or data policies for that purpose.
Show less
Client scripts primarily run on forms and search pages, not on lists (except for onCellEdit() scripts) or ServiceNow mobile applications. For list editing validation or restrictions, other mechanisms like ACLs, business rules, data policies, or disabling list editing should be used.
Key Features
- Script Types:
- onLoad(): Executes when a form first loads, allowing default values or form manipulation before user input.
- onSubmit(): Executes during form submission to validate data; can cancel submission by returning false.
- onChange(): Executes when a specified field value changes; provides parameters such as the control widget, old and new values, and loading status.
- onCellEdit(): Executes when a list cell is edited, with parameters for sysids, table, old and new values, and a callback to manage script execution flow.
- UI Type Targeting: Scripts can be configured to run in Desktop UI, Mobile/Service Portal UI, or all interfaces.
- Field and Table Specificity: Scripts apply to specified tables and can be scoped globally or to particular views.
- Script Isolation: By default, scripts run in strict mode with limited DOM, jQuery, and window object access for security. This can be adjusted per script or globally via system properties.
- Localization Support: Messages can be defined for use within scripts to support multiple languages.
Practical Use for ServiceNow Customers
- Use client scripts to create responsive, dynamic forms that improve usability by automatically adjusting fields based on user roles or other field values.
- Implement onSubmit client scripts to validate form data client-side before submission, reducing server load and improving feedback times.
- For field-level dynamic changes, utilize onChange scripts, but remember these only apply on forms, not lists.
- Manage list cell edits with onCellEdit scripts to validate or react to changes made directly in list views.
- Remember to secure sensitive data access using ACLs or data policies, as client scripts alone cannot enforce data protection.
- Configure scripts for the appropriate UI type to ensure they function as expected across desktop and mobile environments.
Client scripts allow the system to run JavaScript on the client (web browser) when client-based events occur, such as when a form loads, after form submission, or when a field changes value.
Use client scripts to configure forms, form fields, and field values while the user is using the form. Client scripts can:
- make fields hidden or visible
- make fields read only or writable
- make fields optional or mandatory based on the user's role
- set the value in one field based on the value in other fields
- modify the options in a choice list based on a user's role
- display messages based on a value in a field
Client scripts are intended to optimize the user experience on a form. Client scripts are not meant to protect unwanted access to data.
To prevent unwanted access to data, ensure that sensitive fields are hidden or read-only through ACLs or data policies.
For more information, see Access Control List Rules or Data policy.
Where client scripts run
- Create an access control to restrict who can edit field values.
- Create a business rule to validate content.
- Create a data policy to validate content.
- Create an onCellEdit() client script to validate content.
- Disable list editing for the table.
Client script form
| Field | Description |
|---|---|
| Name | Name of the client script. |
| Table | Table to which the client script applies. |
| UI Type | Target user interface to which the client script applies.
|
| Type | onLoad() — runs when the system first renders the form and before users can enter data. Typically, onLoad() client scripts perform client-side-manipulation of the current form or set default record values. onSubmit() — runs when a form is submitted. Typically, onSubmit() scripts validate things on the form and ensure that the submission makes sense. An onSubmit() client script can cancel form submission by returning a value of false. onChange() — runs when a particular field value changes on the form.
The onChange() client script must specify these parameters.
onCellEdit() — runs when the list editor changes a cell value. The
onCellEdit() client script must specify these parameters.
|
| Field Name | Name of the field to which the script applies. Available only if the script responds to a field value change (onChange or onCellEdit script types). |
| Application | Application where this client script resides. |
| Active | Enables the client script when selected. Unselect this field to disable the client script. |
| Inherited | Indicates whether the client script applies to extended tables. |
| Global | If true, the client script runs on all views of the table. |
| View | Only visible when Global is unselected. Views on which the client script will run. |
| Description | Content describing the functionality and purpose of the client script. |
| Messages | Text string (one per line) available to the client script as localized messages using getmessage('[message]'). For additional information, see Translate a client script message. |
| Script | Contains the client script. |
| Isolate script | New client scripts are run in strict mode, in which direct DOM access is turned off. Access to jQuery, prototype, and the window object are also turned off by default. To enable DOM access on a per-script basis, leave the Isolate script option cleared. To turn off strict mode for all new globally scoped client scripts, set the glide.script.block.client.globals system property to false. |