Go to portal
There is something of a mantra in the SaaS industry of ‘configure don’t customize’. Along with keeping to out of the box, ServiceNow customization is a topic that keeps on coming up in architectural decisions. We’ve got a guide to help you better understand the topic and make conscious decisions about if you want to customize or not in the future.
Definitions
Before we start, let’s define terms:
Configuration – changes that are made using default platform functionality.
Customization – changes that are made using code and modify core functionality.
Or, if you want it even more simply, then “clicks vs code” is a helpful way of remembering the difference.
Why to configure and not code
So why do industry best practices recommend configuration? The first major reason is that it affects the upgradeability of your instance. If you modify functionality with code it might cause a conflict when you are upgrading to the latest ServiceNow release. Not customizing can save considerable development time here. We’ve seen customers with heavily customized platforms reduce their upgrade time from several months to a few weeks by cutting back on their customizations. Customization does not necessarily mean less quality, but it definitely has implications for scalability.
Having said that, you are less likely to introduce technical debt when using configuration. You eliminate the risk of hard coding, code duplication or not following coding best practices this way. Less technical debt will mean a better performing platform, which is easier to upkeep and scale. Less code also opens the door for your citizen developers or admins to help share the burden your developers face. As low-code platforms such as ServiceNow were first introduced into the marketplace to address the issue of a lack of development talent, it makes sense to try to use your resources wisely.
Another reason you might want to configure is to take advantage of all of the latest ServiceNow functionality. With its updates coming twice a year, ServiceNow are continually expanding their platform and empowering their users to automate ever more processes. The system you may have customized a few years ago may now be possible in a configured state. There may even be extra features on top plus even more in the roadmap. Using this would deliver immediate value to the business which you are currently missing out on. Keeping track of such developments in each release notes ensures you can effectively plan and optimize your platform.
The general trends
So let’s take a look at where most users currently are. While compiling our latest development report we found that 29% of the average instance (excluding dictionary and table) was customized, compared to 71% which was configured. Some instances can have a much higher ratio than this. The higher the ratio, the more problems that are likely to occur. It is worth repeating again that customization is not inherently bad. But it does require far more care with implementation to prevent thorny issues down the line.
ServiceNow customization – is it ever advisable?
Yes. ServiceNow would clearly not give the option to customize if it were not needed by its user base. ServiceNow does not and probably will never cover every single need of every user. However, customizing should always be a conscious decision. Always look for a configuration option first and do a full business evaluation of any customization you intend to make. Ensure that it is both worth the time that you will spend and that is essential to your business. Making changes for the sake of new legislation is one such circumstance where it becomes a good idea.
If you do have to code, then consider doing so in a more sustainable way. If you don’t already use them then scoped apps should be part of your architectural solution. Keeping your code in controlled environments provides many benefits such as easier governance and improved security. Rather than having to unpick your way through an uncontrollable mess, scoped apps can create containers for your code. For a non-tech analogy, this is the difference between having papers scattered on your desk or in a filing system. Scoped apps may not always be appropriate, but can let you code with fewer headaches than simply putting everything in global scope.
