4 best practices to align your ServiceNow instance to the out-of-the-box functionality

Table of Contents

Reading time: 6 min
Audience: ServiceNow platform owners; developers; architects

During the Barcelona ServiceNow partners event back in March and also in John Donahoe’s keynote in Knowledge 18 in Las Vegas, ServiceNow encouraged partners and customers to commit to the Out-of-the-box (OOTB) functionality in ServiceNow instances. This has two main objectives:

* to get the most out of the new features coming on new releases

* to reduce the maintenance and upgrades effort on your instances (and to avoid the accumulation of technical debt)


Picture from K18 taken during John Donahoe’s presentation. Out-of-the-box.

Now, clearly that’s easier said than done, but there are a few key best practices which can really help customers to achieve this objective. Here you have a collection:

1 Stick to the Out-of-the-Box (ITIL) processes

Do you really need to change the OOTB process? I truly think it is a good idea to try to adapt your organisations common processes’ to match the ServiceNow OOTB ones. This means that  you will be able to work with configurations (change some settings, ACLs, mandatory fields, etc) rather than with customisations (changing workflows, adding lots of scripts, changing OOB scripts, etc).

2 Ensure you understand how ServiceNow works before attempting any changes

This is an all-too-common mistake: creating new functionality which in reality is not needed. An analyst or a developer should always carefully explore what comes with ServiceNow before writing any script. Time and time again we see new scripts generated by developers when there was no real need. There is a clear example for this: setting a priority of an incident. A developer might take this requirement and write a script which sets the priority based on certain values of the form. That functionality is already implemented in ServiceNow by using the Priority Look Up rules, so there is no need to create such a script. So the best practice here is to check all the ServiceNow documentation before starting our development work.

3 Be a nerd! Have nice architecture in place and use scoped applications

It is also a best practice to migrate your legacy custom applications from the global scope to their own scope. This will help in having a proper architecture in the instance and keeping those customisations in a controlled area of your ServiceNow instance, not interfering therefore with other applications and upgrades. Our instance will also be more aligned to the OOTB functionality.

4 Avoid changing existing scripts

The fourth best practice I want to mention today is preserving the ServiceNow OOTB scripts (business rules, client scripts, catalog scripts, etc). Modifying this code should always be a last resort option. We can always create a new one which extends the function of the old into the new etc. But the recommendation is basically preserving the original code as much as you can.

It is Never too late!

If your instance already has lots of changes in OOTB workflows and scripts (we have seen customers with more than 300 scripts changed), it is not too late to start reviewing them. You can use your next upgrade to do house keeping. Look carefully to all the skipped records of your upgrade. The important part of this analysis is to understand WHY you have customised the functionality and whether you can now, at this point, revert back to the out-of-box functionality and leverage it natively, rather than as a customisation. You can also use QC for ServiceNow to start doing this work before waiting for the next upgrade. The upgradeability dashboard shows all the OOTB configuration records that have been modified in your instance:

Quality Clouds for ServiceNow – Upgradeability Dashboard


Customers can use the information provided by this dashboard to monitor the OOTB changes on a regular basis and ask ourselves if it was imperative changing a particular element. Embedding this routine as part of our regular development and architecture review process will allow us to start reducing the technical debt of our ServiceNow instance and reduce the pain of our next upgrade.

There is a quote from Albert Einstein which I tend to mention quite often: Insanity is doing the same thing over and over again and expecting different results.

If we keep on working the same way in our ServiceNow instance, the story will repeat itself over and over again and things will get even worse! It is time to improve our processes and make our lives easier!



If you want to learn more about how Quality Clouds can help you to reduce the cost of your next upgrades and align to the out-of-the-box functionality, ask for a demo today: http://www.qualityclouds.com/book-your-demo/


Signup to QC Insights!

Interested in what we do?
Find out how Quality Clouds can enhance your SaaS platforms' governance, compliance, and quality in real-time.
Quality Clouds
Quality Clouds was created to address a significant gap in the tech industry: the challenge developers face with Salesforce and ServiceNow deployments. Identifying the risks of working on unknown systems, our founders sought to empower developers with essential insights for quality and governance in SaaS projects.

Want to learn more? Let's talk: