ServiceNow Best Practises on Instance Customization

[Sebastian R_]

Yesterday I had a longer discussion with one of my clients about Instance Customization and changing OOTB functionality.

Years ago the recommendation was to deactivate the OOTB record and then copy and modify the new record. The problem with this approach is that you are drifting away from the baseline version with each upgrade unless you compare each of your cloned records with the new OOTB Version during an upgrade (but this can be a lot of effort and is often forgotten during the upgrade process).

During our discussion we came across a knowledge article from ServiceNow about Instance Customization and a quick answer sheet about the best practices for customizations in the Customer Success Center.

The short answer from ServiceNow on this topic: 

Customizations should be made to baseline objects where necessary, so that conflict resolution 
and decision making can be appropriately recorded in the updates. Hidden customizations may cause 
administrators to overlook updates in future assessments in case reverts or merges are necessary.

Avoid copying objects. Instead, update objects in place wherever possible, except for Service Portal 
widgets and other items designed to be reused

Because those two links are hard to find and they include very important things I want to share them with all of you.

Instance Customization FAQ and Guidelines

What are the best practices for customization?

Do you agree with their best practices and guidelines? Do you have any other best practise on instance customization on your instances?

[scott barnard1]

Hi Sebastian

For years ServiceNow themselves recommended that you don't touch out of the box and if you need to then create a copy, mark the ootb inactive, and customize away.

There is a strong reason for this in that if you mark the ootb inactive you will still get the updates to it on upgrade either via a patch or a version update.

I appreciate that SN now believe that its better to review each and every customisation every upgrade. This way there is a systemic approach to reviewing all your customisation's.

If you have a lightly customised or nearly new instance this is probably a good idea.

However if your instance is heavily customised and of an age where it will have had deprecated features in it then when you come to upgrade you see thousands of records to review. This will act as a barrier to your decision to stay up to date.

Also it ignores the issues around patching. With SN committed to an aggressive upgrade cycle of twice a year there are advantages of new features but the disadvantage of the core tech guys focused on the n+2 level before the current RTM is released. This leads to more and more feature patching after the release. 

Patching like upgrades relies on the object being ootb. So you will need to review all your customisation's on every patch.

This is not a bad thing.

For me if your instance is new and there is little customisation. Go for it.

If it's old or has had an active set of dev's on it for a while then no.

Just my opinion. I do feel like SN are trying to suggest you shouldn't customise the tool. However the biggest feature that is attractive about SN is that it's possible to customise.

[LaurentChicoine]

I'm happy to see that this is now the officially documented good practice. Scripts in ServiceNow are often dependent on each other therefore if the OOTB record is disabled and other configuration/script assumes the OOTB record is in place the upgrade might break the functionality. Reviewing the modifications of OOTB records allows to avoid this and also validate that the customization is still in place. I remember a few customization we did that were made to fix bugs and eventually the bug fix was included in a release and we could revert to OOTB. Making a copy would have made this process harder and less automatic (we review every skipped update on every upgrade/patch).

The process of reviewing skipped upgrades has been improved a lot in the last few versions, I remember having to go through hundreds of skipped upgrades because even records that were not updated on a given version were still marked as skipped upgrades.

I hope to see this best practice reflected in OOTB configuration. Currently there is a lot of Script Include with a read-only protected version and a customizable version in which you can override the class methods. However, this does not allow an easy review when the OOTB method you customized has been modified in the protected script include.

You can also see that people are requesting a tool to be able to compare the cloned Service Portal widget with their original version to ensure these are staying up to date: https://community.servicenow.com/community?id=view_idea&sysparm_idea_id=182962b9db680010f7fca851ca96...

I think the best practice of modifying the OOTB should also be extended to Service Portal widget.
I have a clear example for that, in early versions of the Service Portal, the approval widget was not secured, the Server script was not validating who was approving the record. Therefore a forged request could allow to approve any approval record even if the user did not have the ACL to do so. Service Portal server script actually creates a REST endpoint that can be consumed from any user session if you forge a request, the widget does not have to be applied on any page.
With this kind of security issue that can be present in OOTB widgets, it becomes important to get these security updates to the widget code. If you made a clone of that widget to make small modifications and keep using that widget without reviewing the updated widgets, you might have a security hole (that has been fixed OOTB) in your cloned widgets.

[mhaak]

The whole thing would be substantially easier to manage if ServiceNow would just provide a simple indicator for which objects are unmodified OOTB, modified OOTB, and totally custom. For modified OOTB, there should be a way to compare the object to the current unmodified version of it, for whatever version your instance is on.