This article is relevant for the following ServiceNow releases: Xanadu, Yokohama, Zurich.

---

Following a support case I was working on with ServiceNow support, I was provided a snippet of code to use as a workaround for a Business rule. Everything looked fine, but then something caught my eye at the bottom of the provided solution:

DISCLAIMER: When changes need to be made to OOB content, it is best practice to first create a copy of the original content and modify the clone. Leave the original files intact so they receive any future updates or have a backup in case the customizations stop working.

ServiceNow Support

To be clear – in this context, this is not ServiceNow Best Practice. The current guidance is, in fact, the opposite:

Additionally, in the past, the best practice strategy for updating baseline scripts was to make a copy of

the record you want to update, make the original record inactive, and change the script in the copy.

This complicated the upgrade process since there were two records to maintain for each change.

Instead, the new best practice from ServiceNow is to modify the baseline record itself. The record will be

available for review and revert as a skipped file during upgrade

https://mynow.servicenow.com/now/best-practices/assets/businesssmart-customization

I took this to the wider community, and to my surprise, many experienced ServiceNow developers still thought the best practice was to take a copy!

It is still a myth that has prevailed in the ServiceNow ecosystem! Consider this a PSA!

What is ‘taking a copy’ ?

Let’s say you have an OOB Business Rule that you need to customise (update an OOB file) to meet a well-justified business outcome.

If we take ‘Cascade closure of Incident Tasks’ as an example

Copying an OOB Business rule

Taking a copy refers to the following process:

• Create an update set to capture your changes
• Deselect the active flag on OOB record
• Save the record
• Select Insert and Stay from the context menu
• Mark the new record as Active
• Make changes

This process can be followed for any configuration that can be duplicated and has a mechanism to control its state (on/off) that needs to be customised.

Why shouldn’t you take a copy?

I did some research and found this fantastic slide that communicates this perfectly:

I’m not sure of the source of this image; it was shared in a ServiceNow community discussion.

Any configuration file where customisations can be managed via the upgrade merge process should not be copied. This is primarily in the domain of scripts that can be modified.

When should you take a copy?

As ServiceNow has evolved into the low-code realm, some complex configuration objects with high coupling do not lend themselves to merging updates in upgrades, often missing version control entirely, but with a mechanism to toggle activation. For those, it may be helpful to mark inactive, then take a copy for reference. This is because they lack a version history or cannot feasibly be merged.

Some of these include:

• Playbooks
• Flows
• Subflows
• Actions
• Decision tables

Where possible, keep an eye out for future OOB changes to those complex objects and consider rolling back where appropriate.

When should you do neither?

It is not always a binary decision – take a copy or not?

Sometimes it is possible to extend. OOB Script includes can be extended. Some Flows contain customisation subflows. Logic can be extended. Business rules with the same trigger can be run at a higher order. Extension points can be used.

Just be sensible when it comes to extending. At the end of the day, it is about doing what is most supportable and maintainable. Do point extending in such a way that it creates high coupling and makes it more difficult to support than a single customised file.

TLDR

• Before customising, always check for methods to extend first.
• If customising scripts cannot be avoided, don’t take a copy – update and document your changes.
• When customising complex objects, such as low code – you may take a copy and deactivate the original.
• Find all of ServiceNow’s best practices in one location – https://mynow.servicenow.com/now/best-practices

The post Why you shouldn’t take copies of scripts when customising appeared first on The SN Nerd.