Considerations for All ServiceNow Administrators as they Build and Configure
Introduction
I often write about leveraging the platform for bespoke business needs, thoughts about proper design and architecture, reviews of ServiceNow solutions and how they fit into an overall platform strategy. But sometimes it’s good to focus on the basics – what a manager I had called “blocking and tackling” – the fundamentals of administering a ServiceNow platform for its overall health and creating the best experience for users. These are things I tend to take for granted, but then I see customer instances and realize people working in ServiceNow are not thinking about them.
In Part 1 we covered UI Administration and Table Administration. In this part we’ll delve into everyone’s favorite subject: coding. And of course when we say “coding”, in ServiceNow we mean scripting in Javascript and the Glide APIs.
Coding
- Only script (code) when you can’t configure. I’ve written on this topic previously, both how to design for a configurable solution, i.e. code once, configure often, and when you should and shouldn’t code. So we won’t dive deeply into this topic. Suffice it to say the lesson for administrators and developers is when you think about creating a solution in ServiceNow, exhaust all options before you start writing a script. It’s often super easy to just start writing a script that will give you the solution you need, and while it solves the need for a particular requirement, as each solution is developed, you wind up with more and more one-off code, making system maintenance and further development harder and harder.
Quick thoughts:- Can you use a UI Policy instead of a Client script?
- Can you use a Data policy instead of a Client script or Business rule?
- Can you use a Display Business rule instead of GlideAjax? (more on this below)
- Can you use a Condition builder instead of a coded Condition?
- Can you use the Set field value function of a Business rule instead of scripting?
- Can you build a configuration table instead of writing it all in code?
- Default to building server-side. The very simple reason for this is that things that run server-side run orders of magnitude faster, and far more securely. For the former, you have the beefiest computer at your fingertips, but it is not likely faster than the server with its dozens of processors and dozens of gigabytes of memory. For the latter, processing data on the server is always more secure than sending it “over the wire”, and a server in a data center is always more secure than a laptop in your home or at a coffee shop or airport.
What are some examples of this?
- Using a display Business rule to process logic on the server for a form view of a record, and using the scratchpad to make the data available to Client scripts. (Versus GlideAjax calls to the server.) This of course is if your order of execution supports it.
- Using a before or after Business rule to process logic on the server “on the way” to the database. Compared to processing it on the client and having the client pass it back to the server.
You’ll need to understand where the different elements of ServiceNow run to be able to fully embrace server-side design. But the key is to always think “can this work on the server” as you design your solutions, and default to building it there if you can.
- Run your code async where possible. Akin to the previous point, it’s the correct choice to run your code asynchronously whenever possible. In ServiceNow, asynchronous means that the code is placed into a system managed queue to be processed as system resources allow, rather than running the code synchronously as part of a user session that requires the user to wait until processing is complete. Ergo, the user experience is better, and the system is allowed to manage its resources better. As a developer or administrator, you have to know when this is possible. At its most basic level, if the logic you are running does not need to be completed before the database transaction, or does need to be immediately reflected to the user as part of their session, then you can run it asynchronously. Technically, this means using the async value in the When field on Business rules, and events and Script Actions in other cases. (This is a technical approach that is beyond the scope of this article.) At the very least, consider the question: When does your code need to run, and don’t blindly create code elements that run synchronously and release them because they “test OK”.
- Consider reusability. Most folks who have scripted in ServiceNow know there are inline scripts that are meant to run as processes are executing – Business rules, Client scripts, Transform scripts, etc., (most scripts are of this type) and standalone scripts that are meant to be called by these inline scripts – Script Includes. As you are developing code-based solutions, consider if the code you are writing could be used or called from other inline processes, and develop it in a Script Include function rather than directly inline.
- Add comments tactically. Commenting code tends to either be “not at all” or “more comments than code”, with the former being the most popular. My rule of thumb is to comment in three ways:
- Add a block comment at the beginning of functions to note the purpose of the function, the input(s) and the output(s).
- Add inline comments if you’re writing a block of code that is non-standard or more esoteric than ordinary Javascript
- If the code is as a result of an Agile Story, or Enhancement, or Bug Fix, or other development tracking record, add a comment noting the record number. It helps other developers backtrack why the code exists.
- Keep your logs clean. A common trait I see on customers’ instances are busy and messy logs. As I’ve mentioned, ServiceNow itself is as guilty as anyone for this: “out of the box” instance logs are pretty massive. But it’s also true that developers add logging in their DEV instances for troubleshooting and do not turn it off before moving to PROD.
A good rule of thumb is to take one of two approaches: Either have the last step you do before closing out an update set be to review all the code in that update set and comment out the logging, or, as a more robust solution, add a system property the application that can turn logging on and off, and wrap your logging statements inside an IF check on that property. There are many out of the box examples of ServiceNow doing this.
The obvious reason to do this is the processing and storage logging takes up. But the more important reason is that when you are troubleshooting issues in your instance, having to fight through extraneous log statements to get to the ones that help identify the root cause can be time consuming and frustrating.
Part 2 Conclusion
Despite the marketing claims to the contrary, anyone who’s worked with ServiceNow for more than a moment knows that you cannot really create anything bespoke without some scripting. But anyone who’s been around multiple customer instances also knows that scripting can get out of control quickly – making the system harder to maintain, fix, and create new solutions on top of. Keep the fundamentals in mind and you can at least keep the damage to a minimum.
In Part 3 we’ll discuss security and other platform areas, and draw some larger conclusions.
