Skip navigation

Developer Community

1 Post authored by: josephpardy

ServiceNow has become a platform that is essential for some businesses to function by supplying a platform for common development where data can be shared. This interconnectedness fosters an environment where data is kept up to date through the daily work of the employees, directly empowering and influencing all corners of the business. To take full advantage of this environment the audience must extend beyond IT.  Once the user base has expanded to interact with more departments in the company its processes and applications must also expand to meet their needs. In this article we will start to discuss the development practices and techniques that should be employed in an environment where many users and applications are interacting; to ensure that the performance of your system is not impacted.


IT organization can drive adoption to the platform by becoming the provider of services to the company’s many groups using core applications like Service Catalog, CMS, and Knowledge. Quick access to information, services, and support can be provided through these tools with an attractive and customizable user interface.  Many times though the needs of an organization become complex and a custom component or application is needed to support their work. Application development on ServiceNow gives organizations both inside and outside of IT the ability to enhance their workflows and business processes. Efficiency and excellence in business can be empowered with this interconnected and flexible system of applications. 


A larger more diverse user base interacting with data from across the business using a variety of applications will start to put strain on the system.  Having a slow and cumbersome application impacts the speed in which the organization performs, and could impact other applications and groups that rely on their data. Structuring your applications with modularity and performance in mind will help build an environment where applications do not collide with each other. There are some key approaches that should be considered to isolate your processes and data and take advantage of the systems resources. Using asynchronous techniques in Business Rules, Script Includes, and Client Scripts will set the foundation for a scalable application environment.


Asynchronous processes can move data and instructions through the system utilizing its resources without making the user wait for those actions to complete. We keep the system busy with processing requests and allow higher priority tasks to execute that would impact other users. Large amounts of data that needs to be processed or code that needs to be executed should happen asynchronously for anything that is not required to return to the user directly. Actions such as additional record creation or field calculation can be placed into an asynchronous Business Rule. To the user these actions perform behind the scene and their page returns to them quickly and allows them to move onto their next task.


Within code we have the capability to control what we are processing utilizing events in ServiceNow. We can create custom events and handlers in the system to send data processing and instructions to be executed in the background. This is perfect for long running scripts that are not required to complete right away or might even timeout. For instance, let’s say you had large amount of records to read and transform data into another table. At some point the number of records you are looping through could make for an extremely long running process, especially if there are additional tables to look up based on each record’s information. Structuring your code to create an event for each record and a handler that will execute the transformation of that single record would allow the system to potentially process multiple records at once and not have any single process execute for too long. Eliminating long running processes on the system will help all concurrent users avoid experiencing any performance issues.

The code below is an example of what would be written to generate events for using a custom event that we have registered "record.transform" for the purposes of transforming each record individually:

//assume the records variable is a GlideRecord object
while ( {
  //the two extra parameters can be used to pass additional information like 'sys_id'
    gs.eventQueue(“record.transform”, records, records.sys_id, '');


               This is some code that would be in place to handle the "record.transform" event:

//Importing a script include that will perform the transform
var sys_id = event.parm1;
var result = new RecordTransformer().transformRecord(sys_id);
//the result here is the success or failure of the the transform
gs.log(result, 'RecordTransformResult');


Sometimes it is not just raw data processing that needs to be optimized in order to provide the user with a good experience. Inefficient client side JavaScript can present the illusion of a poor performing system. For example retrieving a record in another table from the client side would cause an additional communication to the server after the form has loaded. In most cases this could be handled with a before display Business Rule that can perform that action on the server and make it’s result available in the scratchpad to the front end. In some cases it may be necessary to wait for an interaction with the user before that data can be fetched. Enhancing fields with auto population and lookups based on the information that they are providing is a great way to enrich the user experience. In Client Scripts GlideAjax enables our ability to connect data in other parts of the system to the user’s inputs on the form. Not all Ajax performs asynchronously though, using functions like getXMLWait() with stop all functions on the form until it has received a response from the server. This is a very choppy user experience where the user perceives the system to be extremely slow. Using a call back function to update the form on the return from the server would allow the user to keep moving through the form, and the data will populate in nearly the exact amount of time without interruption.


             Here is a code example for using GlideAjax on the client side utilizing a callback function:


//This GlideAjax Function retrieves related records from a Script Include for reference on the clientside
var ga = new GlideAjax('RelatedRecords');
//the sysparm_name parameter calls out the function that will be evoked in the script include
ga.addParam('sysparm_name', 'getRecords')
ga.addParam('sysparm_foreign_id', g_form.getUniqueValue());

function RecordsParse(response) {
   //In this case we are going to assume that the script include is returning an array of records
   var answer = response;


These are some examples of how we can reduce the dependencies of process execution in the system and attempt to avoid poor performance. We focused mostly on asynchronous data processing and code execution. These practices can reduce the appearance of performance issues to users and take advantage of the system’s resources efficiently. Applications that do not create long running processes will not interfere with other users and applications in the system. Having this environment where applications interact but do not collide will encourage people to use the platform. In a future article where we discuss some basic optimizations and strategies for tables and the data stored there to improve querying efficiency and reporting.

Filter Blog

By date: By tag: