Configuration vs Customisation in ServiceNow

Should you configure or customise your ServiceNow platform? Or something in between? Which approach will best fulfil your requirements? Each option comes with trade-offs, depending on what you need to achieve. Is specialist functionality worth the risk to the environment’s stability and upgradability?

But how do we define configuration and customisation? Where are the lines between them?

The answer isn't always black and white. There are various approaches to delivering on the requirements that align with your business processes. There are many shades of grey between the two extremes, and secondary considerations.

Your ServiceNow partner should put your interests at the heart of their solution designs. After all, it’s your business we want to run smoothly, more efficiently. And that means your ServiceNow partner has a duty to protect the integrity of the ServiceNow platform: to ensure it remains performant, and to preserve maintainability and upgradability.

The trick is to design a solution that fulfils your requirements within the bounds of the platforms’ flexibility.

Implementing client-specific functionality begins with gathering requirements.

When capturing requirements, a consultant must understand where the need comes from – what policy underpins it? Is it a personal preference? What business value will the change deliver? Only with solid policies and/or anticipated business value can we justify sidling further along the configuration-customisation spectrum.

So how do we define configuration, customisation, and the grey spaces in between?

Configuration is the process of making changes to ServiceNow using the platform’s administration features. This allows for changes that are variations on the basic capabilities of the ServiceNow platform.

You can add fields to a database (or choose which not to show). You can configure the labels associated with those fields, adjust their display order and labels, and identify which require population to process a form. You can set triggers on certain inputs to initiate other processes.

Configuration allows you to take full advantage of all the capabilities in an out-of-the-box ServiceNow instance.

Extension is a step beyond configuration. Fundamentally, it involves the deployment of custom code, proprietary processes that go beyond what ServiceNow can do on its own.

The key to extension is in how it interfaces with the default ServiceNow platform: it uses interfaces and attachment points that are designated by ServiceNow for this purpose. For example, the Incident script include is designed to allow the behaviour of the read-only IncidentSNC script include to be overridden with proprietary functionality.

Using these interfaces preserves the upgradability of the extended platform. However, it is no guarantee of stability and performance. The quality of the extension code becomes a key issue. Is it clean, light-weight and well-written? Does is run smoothly in all situations, or can it get bogged down?

A poorly-implemented extension can have serious consequences, degrading the performance of the entire platform. This affects user experience, and thereby adoption and benefit realisation. It could, in the worst of cases, interfere with the platform’s default code, causing processes to fail.

As such, extensions cover quite a gamut, from the simple to the complex.

Sometimes, a request is so complex that it pushes the bounds of ServiceNow’s capabilities. Maybe you want to record, track and manage marketing events. There is no clean way to integrate the new functionality: new data tables are required; custom code is required to support the proposed processes, maybe replacing deactivated baseline code.

This is where we reach the dangerous ground of full-on customisation.

Customisation carries all the risks of extension, but also interferes with upgradability. Whenever you replace baseline code, you are adding overhead to future upgrade processes. Every customisation will need to be referenced against the upgraded baseline and the changes merged, requiring even more testing before it is safe to deploy again. In some cases, the upgrade may render the customisation unportable, leaving you to face decommissioning the custom capabilities people have come to rely on, or foregoing the upgrade.

First and foremost, the advice is to configure, rather than to extend or customise, wherever possible. And all custom code, whether extension or customisation, should be as minimal as possible.

Keep in mind, also, that when you modify any out-of-the-box platform code, you are taking ownership of that code, of those records. It will no longer be supported by ServiceNow and will be skipped during upgrades.

Of course, sometimes customisation is the only way to implement a requirement. These best-practice guidelines we help streamline the process of managing customisations:

• Duplicate the code you need to customise, leaving the original intact while giving you a template to apply your changes to.
• Deactivate the original code so it does not conflict with your modified code.
• Monitor upgrade release notes for changes to the replaced code, and for newly-introduced functionality that could clash with or replace your custom code.

Want to Learn More?

Deciding the best approach to set-up your ServiceNow platform is key to long-term success. Click here to learn how the FlyForm team can help you.

Learn more about FlyForm's IT management and get in touch with us