These are the Top 5 Best Practices You Should Be Using in Your ServiceNow Instance Today


Most training courses and college classes on software development cover specific coding environments with one language (e.g. Java) or a set of languages (i.e. HTML, CSS, JavaScript). Each of these courses focuses on the core features, functions, and syntax of the subject system, but only lightly touch on best practices that run across the board. Even then, it’s often tilted toward the style and opinion of the instructor. Students are then left on their own to research and find the right way to perform tasks and functions, including those that are repeated throughout the development process.


When it comes to ServiceNow development, there are tons of best practices and rules for each application on the platform. Today I’m discussing my top 5 that apply across the board to enhance code maintenance and supportability.


1 - Minimize Server Calls in Client Scripts


The user’s experience in their browser is dependent upon fast load and response times. Even a couple of seconds delay can cause a user to discount the system’s value. When writing client scripts, developers can severely impact, or enhance, the user experience.

A key element is to never use GlideRecord or other direct server calls in the client script. Instead, put the server call in a script include, and use GlideAjax to perform an asynchronous call to the database that keeps your user’s browser running.

On this same vein comes the next item on my list:


2 - Business Rules’ Performance Impact on Clients


Business rules are server-side code, executed during various server calls (i.e. before, after, async, display). Whether at insert, update, delete, or query, these rules can be used to perform a multitude of useful and beneficial tasks to meet our customer’s requirements. They can also hamper performance to the client browser.

Rules set to run ‘before’ and ‘after’ an action can cause the browser to wait for a response. If the script is performing updates to other records, the additional database calls may cause the user to think the session is hung. For this reason, best practice is to never update records in another table within a ‘before’ business rule, and where possible, use ‘async’ rules to drive the load to the server with no impact to browser performance.


3 - Don’t Use “update()” in business rules


Our next best practice has to do with preventing recursion. Say you want to modify the value of another field on the same record that has just been updated. If you write a script to set the value and then add ‘current.update()’ on the end of the rule, you’ll cause some trouble.


‘Before’ business rules set values before the database operation is complete. This means if you set a value with your script, the database operation will then complete including your updated value. If your script includes ‘current.update()’ it will cause the record to save again. Additionally, everytime ‘current.update()’ is used, EVERY business rule set to run on ‘update’ will run. This could potentially lead to rules running over and over, degrading performance.


4 - Proper Prefixes and naming


When writing code, there are as many opinions on variable and parameter naming as there are developers creating them. For long-term supportability, it’s important to adhere to at least a few best practices in naming. Here are a few examples:


- GlideRecord variables should be prefixed with ‘gr’

- e.g. var grUser = new GlideRecord(‘sys_user’);

- GlideAggregate variables should be prefixed with ‘ga