Configuring or Customising?

To Customise, or not to Customise? That is the question.

But of course it’s not – because it’s so hard to agree what counts as ‘Customisation’.

The ground rules in ServiceNow sound easy – “configure the tool to suit your way of working; but don’t customise it.”

What is customisation?

There have been so many differing opinions on this but my view is simple : a customisation is something which complicates a future version upgrade.

I have been reading an excellent new book – “Spinning Up ServiceNow: IT Service Managers’ Guide to Successful User Adoption” by Gabriele Kahlout.

Link to Amazon UK (not an affiliate link – it’s quite safe to look!)

It’s a great real-world view of ServiceNow deployment, focusing on the business change and user impact of ServiceNow projects.  A lot of this book will be sadly familiar to any ServiceNow consultant I’m sure, but it’s well written and full of good advice.

One section I have to disagree with is about this topic of customisation : Gabriele simplifies this as ‘anything requiring code’.

I agree that best practice is to use, for example, a Business Rule where you use the GUI-based options to define when it fires and what it does.  And for anything more complex you use the (often hidden) script boxes.  But that doesn’t mean that those scripts are necessarily bad customisation.

Oversimplifying the issue?

The arguments about this generally come from trying to reduce this to a binary distinction : configure or customise.  It’s easier not to do this.

There are (at least) two levels of customisation which quantify the risk:

  1. Things which allow an upgrade, but where you cannot benefit fully from the upgrade.
  2. Things which prevent an upgrade or break after an upgrade.

Level 1 can be considered perfectly acceptable with suitable governance to control it and ensure Continual Service Improvement keeps a close eye on it.

Level 2 is the bad one.  But even this may be considered acceptable as a short-term solution, particularly when the long-term fix or change is in the ServiceNow release pipeline.

Examples – Level 1 Customisation

  • Take a standard approval workflow.  Clone it and use that for your process.  Tweak it as you need.  All good except you are no longer using the default workflow, so won’t benefit (or not…) when that workflow is upgraded in a later release.
  • Take a script include.  Override it in your own script and add a new function or functionality.  Again, no problem there except your new functionality is dependant on the original not changing.

Examples – Level 2 Customisation

  • Take a standard approval workflow.  Add a step to include line-manager as an approver.  Publish the workflow.  This marks the workflow as ‘customer modified’ and it will not be upgraded.  It will be flagged when performing an upgrade as something which was skipped during the upgrade.
  • Modify an existing Script Include to enhance the logic with your own business requirements.  Again, marking an out of the box object as customer modified and excluding it from upgrades.

But what about…

And there’s the catch. There’s exceptions to everything.  There’s always another example to find.  In a nutshell, there is no single simple definition of the ‘big bad customisation’ versus ‘good old configuration’.

Hard-coding a sys_id into your workflow isn’t really ‘customisation’ except of course it’s bad practice and may lead to things breaking on upgrade because the object you’re referencing may change or be removed in a future version upgrade.

Further Reading

For more on this subject, check the ServiceNow Best Practice documentation.


If you have an active ServiceNow subscription, talk to your account manager about running an ACE report.  This automatically reviews your instance and reports on any configurations (or indeed customisations) which are not considered ‘best practice’

Bite-Size Take Away

  • Preaching ‘configure don’t customise’ is over-simplifying a complex subject.
  • Keep a close eye on changes which affect future upgrades.
  • Maintain strong CSI plus control in your release processes to ensure potentially risky changes are kept track of.
  • Document your configurations/customisations outside of the tool – so they are easily referenced and reviewed by future developers and when planning / testing an upgrade.
  • Use the ServiceNow ACE report service to monitor your changes for belt-and-braces reassurance that you’re keeping to good practices.

Happy Customising, and thanks for reading.

Leave a Reply

Your email address will not be published. Required fields are marked *