Search for a command to run...
I am a technical architect and ServiceNow enthousiast. Since then I have been obsessed with development and later on application design & architecture. Today I'm using my skills to design solutions for IT companies within the ServiceNow industry whilst in my free time, spent the majority of my time creating applications for all kind of things unrelated to ServiceNow.
No comments yet. Be the first to comment.
What is the ArchX program? The ServiceNow ArchX program, a 4-week cohort-based program built by ServiceNow for early-career architects. The program aims to teach students how to excell in the world of
Today I successfully passed the ServiceNow Certified Implementation Specialist exam for Customer Service Management. In this article, I will be sharing my personal experience with the preparation, the training material provided by ServiceNow, and my ...
Learn the Best Situations for Scoping and What Needs to Be Scoped
Understanding ServiceNow's Conditional Table Query Range ACLs
For developers, adopting coding habits is crucial to increasing productivity and enhancing the maintainability of their implementation solutions. This article will cover 5 must-know skills every ServiceNow developer should master.
The DRY principle (Don’t repeat yourself) is all about not repeating the same code twice. Repeating the same logic twice also means updating it in multiple places when the logic has to be changed.
Script includes are your friend. Instead of maintaining all your code in lower-level artifacts such as UI actions, business rules, client scripts, etc., create meaningful script includes that act as centralized spaces to store your business logic.
// Business Rule 1: Before Insert on Incident
(function executeRule(current, previous) {
if (current.priority == 1) {
current.impact = 1;
current.urgency = 1;
}
})(current, previous);
// Business Rule 2: Before Update on Incident
(function executeRule(current, previous) {
if (current.priority == 1) {
current.impact = 1;
current.urgency = 1;
}
})(current, previous);
There is a clear repetition of the code which means we are violating our DRY principles. Instead, we can transfer the code to a script include and have our artifacts call the script include.
var IncidentService = Class.create();
IncidentService.prototype = {
initialize: function() {},
setHighPriorityDefaults: function(gr) {
if (gr.priority == 1) {
gr.impact = 1;
gr.urgency = 1;
}
},
type: 'IncidentService'
};
Some additional tips:
If needed, separate your code into multiple (private) functions
Use variables to temporarily store values and reuse them in your code
Stop building and nesting your if/else statements. There are only a handful of scenarios where I found an "else" statement is actually needed.
A guard clause is about effectively exiting out of your function as soon as a condition is met, instead of nesting multiple if-else statements. This approach simplifies your code by reducing the number of nested conditions and actions.
// Guard clause
function checkNumber(num) {
if (typeof num !== 'number')
return 'Input is not a number';
if (num > 0)
return 'The number is positive';
if (num === 0)
return 'The number is zero';
return 'The number is negative';
}
// Nested if statements
function checkNumber(num) {
if (typeof num === 'number') {
if (num > 0) {
return 'The number is positive';
} else {
if (num === 0) {
return 'The number is zero';
} else {
return 'The number is negative';
}
}
} else {
return 'Input is not a number';
}
}
Commenting your code is one of the most forgotten and underrated tasks for writing high-quality code. By providing comments, you are making your code accessible to anyone who has to later work on or troubleshoot your implementation.
If you want to step up your game, when creating script includes, you can make use of the JSDoc annotation to make your script include functions even more accessible. By using the annotations, other IDE including for ServiceNow implementations will provide feedback while referencing these script include functions, such as the list of available functions, parameters, and a description.
While it is important to provide comments, you can easily overdo it, causing the code to become messy and difficult to read. Whenever you add inline comments, make sure the comment is meaningful and necessary to explain your code.
/*
* Function to escalate the incident
* @param {string} incidentId - the sys_idof the incident to escalate
*/
escalateIncident: function(incidentId){
var grIncident = new GlideRecord('incident');
grIncident.addQuery('sys_id', incidentId);
grIncident.query();
while(grIncident.next()){
//escalating the incident if the priority is 1
if(grIncident.getValue('priority') == 1){
grIncident.comments = 'Your incident was escalated';
grIncident.work_notes = 'The incident was escalated';
}
}
}
escalateIncident: function(incidentId){
var grIncident = new GlideRecord('incident');
//query the incident
grIncident.addQuery('sys_id', incidentId);
//execute the query
grIncident.query();
while(grIncident.next()){
//check if the priority of the incident = 1
if(grIncident.getValue('priority') == 1){
//provide feedback in the comments
grIncident.comments = 'Your incident was escalated';
//provide feedback in the work notes
grIncident.work_notes = 'The incident was escalated';
}
}
}
When writing code in ServiceNow, always design your functions in a modular and reusable way. A well-structured function should focus on a single responsibility: returning data in the most flexible format possible. This allows the calling implementation to decide what to do with the result, rather than forcing an outcome in the function itself.
This approach keeps your code:
Reusable: the same function can be used in multiple contexts without modification.
Maintainable: changes are isolated to one place instead of scattered across implementations.
Flexible: different business rules, scripts, or integrations can interpret the return value differently.
// GOOD EXAMPLE : by returning null, we are informing our calling function about the missing value.
// This allows our implementation to take full control over the expected outcome
getUserPhoneNumber: function(grUser){
if(gs.nil(grUser.mobile_phone)){
return null;
}
return grUser.mobile_phone;
}
// BAD EXAMPLE : we are returning a specific string, making it difficult for implementations
getUserPhoneNumber: function(grUser){
if(gs.nil(grUser.mobile_phone)){
return "No phone number";
}
return grUser.mobile_phone;
}
An easy way to compromise the quality of your code is through inconsistency in your development approach. This includes varying naming conventions, choosing between flow and script inconsistently, or deciding whether or not to use variables.
Always define your standards and naming conventions at the start of your assignment. These conventions will form the foundation of your consistent development approach.
Some examples:
How do you name your update sets?
What would be the name of your script include?
What is the format of system property names?
How are you deploying configuration (update set/application repository, …)
Something many people forget, yet it is considered one of the most important aspects of your implementation. Commenting your code won’t help you or your organization understand the complete solution.
Therefore, always properly document your solution, how the pieces fit together, how they interact with each other, and any other important information that might be relevant to anyone trying to understand your implementation.
There are various tools that make it possible to visualize your solution. I personally use LucidChart at work, but for my personal projects, I also get the job done with draw.io, which is a free-to-use tool.
I cannot emphasize enough how important it is to learn how to work with developer documentation such as the ServiceNow developer docs.
The docs are more than just a page of information. They contain all the classes you might need to use, their corresponding functions, the parameters, returned values, and their corresponding types. Once you gain a better understanding of how the different functions and their return types are linked together, you will significantly improve and speed up your development experience.
Mastering these five coding habits DRY, guard clauses, JSDoc & commenting, modular code, consistency, and documentation will not only make your ServiceNow development more efficient, but also make your solutions easier to maintain, extend, and hand over.
Strong coding practices don’t just help you, they also set up your team and future developers for success. Every clean script include, every meaningful comment, and every consistent naming choice reduces confusion and accelerates delivery.
If you start applying even one of these habits today, you’ll immediately notice a difference in how smooth your development feels. Combine them all, and you’ll quickly move from “getting things done” to building sustainable, enterprise-ready solutions in ServiceNow.