Executes on: server

In a previous chapter, we learned about how access controls (AKA security rules / ACLs) control whether a user can access a record, or perform a certain operation upon it (read, write, delete, and so on). Access controls have a great deal of functionality without scripting, but they also have the capability to execute server-side scripts if the Advanced tick-box is checked:

This script should evaluate to either true or false, depending on whether the ACL should allow or deny access.

Don't forget that for a user to pass an ACL challenge, all three conditions (those in the condition builder, roles list, and script field) must all evaluate to true!

Executes on: server

Much like ACLs, business rules have a significant amount of functionality without the need for scripting. Also like ACLs, business rules support scripting when the Advanced tick-box is checked, in the Script field which will then be displayed.

Business rules execute on the server, so the usual server-side APIs are available to any scripts that might need to be run. Much like many other server-side scripts, the current object is also available. This object is a pre-populated GlideRecord containing the current record; that is, the record which triggered a business rules to run by being inserted, queried, or modified.

Based on the value selected in the When field, under the When to run section of the business rule form, a business rule can execute either before the record has been saved to the database, after the record has been saved, asynchronously (sometime after the record has been saved to the database, when the server gets around to it), or on display (when the record is requested from the database to be shown on a form):

Display business rules are a special sort which execute on the server whenever a record that matches the condition in the When to run section is… well, displayed on a form. These business rules have access to a special object called g_scratchpad. This object can store data from the server-side script, and it can be accessed through any client-side script. In this way, you can easily present data from the server, to the client, under a given set of conditions.

Executes on: client

Client scripts and catalog client scripts are virtually the exact same sort of script. The differences are that client scripts execute on a form with a certain type of record, whereas catalog client scripts execute on a certain catalog item, or variable set within a catalog item.

In either case, both script types execute exclusively on the client (the user's browser). As such, they unfortunately do not have access to some very useful server-side APIs, but there are ways around that. We'll get into how to execute server-side code and APIs from a client-side script (and return the result) in a later chapter.

Client scripts can be used to show and hide options within a drop-down list, add messages to fields, show alerts to the user, or even replace the functionality of UI policy actions (though the latter is not recommended).

Depending on the value of the Type field, client scripts can run either onLoad (as soon as the form loads), onChange (whenever a specified field's value changes), onCellEdit (when a cell on a list changes value), or onSubmit (when the user attempts to submit the form):

Executes on: server

Perhaps a lesser-known part of the platform that supports scripting, is the condition builder. You can use simple scripts to grab and return values to be used within a query, by using the keyword javascript: at the beginning of your query parameter:

For example, if you navigate to the Incident list, and create a new filter that says Caller, is, javascript:gs.getUserID(); as you can see in the previous screenshot, and click Run, then you'll be presented with a list of all incidents for which your user account (or the user account you're impersonating) is the Caller. If you then right-click the last query breadcrumb and click Copy URL as you can see in the following screenshot, the URL will contain the JavaScript code you used to retrieve your tickets as part of the encoded query (the part of the URL following sysparm_query=). If you give this link to another user, they'll see the tickets for which they are the caller, rather than you:

You can also invoke a pre-written script by using a dynamic query on certain fields by changing the is operator, to is (dynamic) (if it is an option). This will execute a server-side script and return appropriate values to be used. These dynamic filter options can be created and modified from the following module in the application navigator: System Definition | Dynamic Filter Options. You can see an example of one of these types of dynamic filter options by going to the Incident table, and filtering using the following query:

[Assigned to] [is (dynamic)] [Me]

Executes on: server

Like many fields within ServiceNow, the default value field accepts JavaScript by prefacing it with the javascript: keyword, just like in the condition builder. Scripts within this field even have access to the current object, and you can dot-walk through reference fields in them.

For example, let's say you want the Country field in a given table to be set to the same value as the Country field on the Caller's user account. To accomplish this, you could navigate to the Country field's dictionary entry, and set its Default Value to: javascript:current.caller_id.country.

You can also use pre-defined/pre-written scripts as the default value, by checking the Use dynamic default checkbox. This will display a new reference field which allows you to select a dynamic default from the Dynamic Filter Options [sys_filter_option_dynamic] table.

Executes on: server

A script include is a repository for reusable code. It is available and executes on the server, and doesn't need to be included in a page or loaded with a form. Any code that executes server-side and in the same scope as the script include, can call it like any other API in the system.

script includes are not triggered by a database action like business rules are, or by an event like client scripts. Instead, script includes are scripts which exist on the server, and are called from other server-side scripts. You cannot directly call a script include from a client-side script, but you can make a script include accessible from a client-side script (though it still executes on the server) by making it extend the GlideAjax class. More on GlideAjax and how to use it in a future chapter. For now, suffice it to say that script includes only execute on the server, and typically only when called from another server-side script.

Executes on: client and/or server

UI actions correspond to buttons in the banner, links under Related Links in the form, options in the context menu, and a few other places:

Clicking on a UI action typically results in a list or form being submitted and reloaded, so UI actions can be configured to run either client-side before the submission, or server-side after the submission (but before the reload). It is also possible to configure a UI Action to run some code on the client, and other code on the server.

As with most condition fields, the conditions for whether to display the UI action are evaluated on the server. This can have meaningful consequences. For example, consider a UI action that's configured to only be visible when the State field is set to Pending. In this case, you would have to save the form and reload it with the State field set to Pending, before the UI action's condition will be re-evaluated and the UI action will be displayed on the form.

Executes on: client

UI policies and catalog UI policies define the behavior and visibility of fields on forms and catalog items. UI policies operate on a specific table, while catalog UI policies operate on a specific catalog item or variable set.

UI policies and catalog UI policies operate entirely client side.

Executes on: client

UI scripts are a lot like script includes. While script includes are libraries of code that are available to any script running server-side, UI scripts are libraries of code which are available to any script which runs client-side, on a page where the UI script is included. If the UI script has the Global tick-box checked, then code within it will be included on every form, list, and page on the client, except on the Service Portal. To include a UI Script on Service Portal pages, you can add it as a JS Include. More information on this, should you ever need to do it, can be found at: http://attachments.sngeek.com/.

UI scripts are a great way to avoid re-writing the same code over and over, and maintain a central repository for a given set of methods or APIs. This can save you time, and help with maintainability.

Of course, having code available on the client means that it must be sent from the server to the client, and be loaded in the user's browser. This can have performance implications during page-loads, and whenever these scripts are invoked. For this reason, it is wise to be judicious about using the Global tick-box on UI scripts. Instead, it would be wise to specifically load these scripts on pages and tables where you know they'll be used, and avoid loading them when they don't serve a purpose.

Executes on: server

Workflow activities always execute on the server by nature and design. These scriptable activities obviously include the Run script workflow activity, but also include activities like Create task, or the If conditional activity. These workflow activity scripts have access to the current object, and are evaluated at the time the activity is invoked via the workflow process. If an activity is not invoked through the natural progression of the workflow, then the script(s) it contains will also not be run.

In addition to any Script fields, all conditions are also evaluated on the server, which means that they are not re-evaluated, and the workflow will not progress past a blocking If activity, until a record is saved to, or updated in the database.

Workflows also contain a special scratchpad object: an empty object which allows your activities to store and retrieve data, effectively facilitating cross-communication between the different workflow activities. For example, if I have a Run script activity which checks some record for some value, I might want to pass the result of that check to another workflow activity so that it can use it in its Condition field.

In the new Kingston release of ServiceNow's Now platform, the workflow wf_context and wf_executing scratchpads support encryption! However, in order to activate that functionality, you must request the plugin (com.snc.encrypted.scratchpad) through a request in the ServiceNow HI customer service portal (hi.service-now.com).