How to: Keep your ServiceNow instance on top form

Let’s talk customisation! This is something that unless absolutely necessary, should be avoided. For example modifying any out of the box state models, as these come from industry standard best practices i.e. ITIL. Some out of the box state models within Service Now are Change Management and Incident Management this moves and tracks several stages aligned to ITIL.
When looking at building new custom functionality, it is best to always refer back to Service Now docs. It is very likely that Service Now has capability that will be able to support your requirement within the platform already.

When coding within Service Now it is best to avoid hard coding sys_id’s into the script. Instead whenever a sys_id is required in a script it is best to create a property in the platform and access it via gs.getProperty(“propertyName”,”sys_id”) This will first try to retrieve the value from the property and if the property does not exist then it will use the hard-coded sys_id.
Using the GlideUpdateManager2() API to push things to update sets that aren’t normally captured. A good example is groups, so groups can easily move through environments maintaining the same sys_ids.
Grouping all related functions into a script to enable the functionality to be easily be reused elsewhere.

Avoid database operations (GlideRecord,GlideAggregate etc) on the client-side such as in client scripts as this will impact the performance for a user. Instead move the required logic to a service-side Script include which can be called from the client script via GlideAjax which does not impact performance.
Making sure reviews on both queues and logs are carried out during development this helps to identify any issues which they may not appear right away. Issues that aren’t corrected can cause performance issues, therefore no error or warning messages makes sure the highest quality of development is achieved.