Configuration versus customization

ServiceNow instances are complex. There are a great many ways in which they can be changed, and often, there are several ways to achieve the same goal using different techniques. These changes can be done through configuration and customization.

Configuration uses the ServiceNow interface to set up rules, conditions, and other configurations, like global system properties and filters. This is often made by using a series of drop-down lists.

We can see an example of this in a business rule as follows:

In Figure 1.1 we can see filter conditions and and the values to set based on the filter. This configuration example uses no code and is preferable to customization. This type of filtering is seen across the ServiceNow platform.

Most system administrators will be able to administer their instance with configuration alone. A configured instance will suffice for a certain level of functionality on an instance, and, if you are trying to achieve a goal where configuration is available, it is usually the best option.

Customization is when an administrator uses scripts to allow an instance to perform further tasks beyond what configuration can do alone. ServiceNow is extremely open-ended, and the ability to write scripts at multiple points when loading and submitting forms makes it very versatile.

A customization might be to write a script to add a date validation on a field and show a message or clear the field if an incorrect value is entered. Custom scripts are to be managed by the creator, as ServiceNow is not responsible for the code. Therefore, if you start to move into the customization route, make sure you know what you are doing.

As the creator will need to maintain the script created, they will also need to ensure that it will still function when an instance of ServiceNow is upgraded.