How should I customise the ServiceNow baseline functionality?

Daniel Pettet · ‎05-28-2021

Go back 3 decisions, you screwed up

If you've made it here then you're either brave, desperate or confused. There is an overwhelming set of documentation online pointing out how important it is NOT to customise the baseline. It points out upgrade issues and maintenance costs and even loss of support from ServiceNow.

This article tries to handle that difficult and surprisingly common decision of how to actually make an informed decision when customising the baseline.

What is the best practice to support smooth upgrades?

TL;DR version...

Cleanest to least clean approach:

Solve via property or data changes first if possible.
Use an extension concept (if supported for that config type). See also "Compliment" below.
Change baseline version or create a new record. See "Modify" and "Replace" options below.

The long version + ugly truth...

Interestingly, the best practice is BOTH to not modify the baseline AND modify the baseline (if you have to). No wonder everyone is confused! Let me explain; modifying the baseline increases maintenance effort. There will be more testing and time spent reconciling and merging new updates during a patch or upgrade should there be an update to the component that was modified.

Previously (~pre 2015) there was a recommendation to NOT modify the baseline and instead de-activate the record in question and create a new custom record with the desired logic. This was great in terms of making upgrades "quick" but it essentially just encouraged upgrade teams to ignore reconciliation and merging practices for their custom records because they (per default) where not highlighted as a "todo" (or conflict) in the upgrade system. This created hidden technical upgrade debt which later often showed up in ServiceNow support tickets as the root cause for something not working as expected.

RCA = Upgrades not applied properly

Modifying the baseline record simply helps make it more transparent that there is a conflict between "custom" and "baseline". The impact however is insignificant if upgrade teams do not properly review the conflicts which sadly is the default behaviour. Teams generally review ONLY the new conflicts for the current upgrade and ASSUME that all previous customisations and conflicts remain valid. In other words, they only tackle the "upgrade conflict delta" and not the entire set of updates.

In summary, it doesn't matter what you do SO LONG AS teams are correctly tracking and reconciling updates with existing customisations (baseline or otherwise).

In the future, ServiceNow could support better tracking of cases where config was "branched off" into a new direction to help with upgrade and reconciliation effort. Customers could already implement this enhancement on their own if desired. The ultimate goal is to just make life easier.

Technical governing principles for customisation

Before changing the baseline, be aware of your governing technical principles and guidelines for your team, company and ServiceNow. Below is a simple list that can help.

The process and requirements should fit first with ServiceNow and second with business requirements. Not the other way around. Avoid porting ageing processes into ServiceNow aka "the tool swap". Updating the process or way of working will unlock more value from ServiceNow.
Property & Data changes are preferred to configuration record changes.
Configuration record no-code changes are preferred to low/pro code changes (eg, scripting).
Changes to the baseline are preferred to de-activating the baseline and creating a new record. Upgrade activities will be more complex or most likely skipped in these cases. See above section.

Get an expert opinion and CYA with approvals

As with most (sometimes risky) things, the review process is critical to get the right feedback. It's tempting to make decisions on one's own for the sake of speed but it can be comforting to have the team behind your decision and this will promote a healthy culture of "trying to be the best" as opposed to "trying to not annoy others and just be fast". Ensure first that review systems are in place throughout the requirements analysis, development and release process. Below is a guide that can help.

Ensure "baseline" is well defined. Any changes to fields, tables and configuration records need to be considered in a technical review process.
Encourage the use of technical reviews in at least the phases of refining requirements (Sprint refinements), during development and peer reviews. See also "Defining Story Requirements with Templates" to ensure easier reviews.
Deviations from the baseline standard MUST be thoroughly challenged and vetted. If the change significantly effects the way ServiceNow works then involve an Architectural Review body. Such questions like "Give me 3 reasons why we can't use this OOTB/baseline table?" will help challenge the team to make the right decision.
Once approved, the approach to customise the baseline setup should be highlighted in the peer review process and sprint review. This will help catch any gaps that couldn't have been anticipated before development start.

The complexity of choice for customising the baseline

By now you must have a solid reason that has been challenged. Unfortunately there is no "1 rule" approach to how to customise the baseline that applies across the platform. Given ServiceNow has many different capabilities, the approach to customising them is also multi-facetted. There is little documentation that explains per record type AND context what to do. An experienced consultant/developer should be able to talk about options for script includes and business rules but what about API rest end points, service portal widgets or ACLs?

The whole discussion can be shortened by analysing the long list of Architectural principles for customisation:

Make maintenance easy
Support minimal effort, scalable and re-usable design patterns

Yep, that's it.... at least on a high level. It includes the ability to upgrade easily (a part of maintenance) and the ability to scale up or adapt the solution to cover future requirements.

Let's say you know you need to configure a business rule to validate that an updated record has the correct data set. There may be a baseline (aka OOTB) business rule that has validation that is in conflict with the requirements. In this scenario, you can either:

Bail.
The baseline functionality makes sense and is more important than the new requirements. Educate and challenge the product owner and/or requestor.
Compliment.
Similar to above BUT support the additional, "missing" validation in a new business rule.
Replace.
De-activate the baseline business rule (it is no longer valid) and create a new business rule for the solution.
Modify.
Change the baseline rule to include the new requirements.

If our goal is to reduce technical complexity then "Bail" would be the best choice.

If our goal is to have "smooth upgrades" then "Compliment" would be advised as it has no upgrade review impact.

If our goal is to retire logic in the baseline application with the view that we will never want to leverage it (or cannot due to compliance reasons) then "Replace" is suitable.

If we are willing to bite the "upgrade maintenance" bullet, invest in (automated) regression testing and MUST fulfil the provided requirements then we must "Modify" the baseline.

All options are valid and will have to be assessed on a case by case basis. In most cases, those 4 options will apply across the platform. Below are some examples where that is not true:

REST end points
The URL is fixed so it's not possible to "Compliment" the logic with a new record. Potentially there is a lower level script include that can be modified/extended but this much closer to "Modify" type changes.
Service Portal Widgets
Some are read-only and cannot be modified. This is usually the case when the widget is provided as part of a specific mini-portal/solution OR the widget is used across multiple portals. They must be replaced for each individual page where they are in use.
UI Actions
It is not possible to compliment the baseline behaviour. Perhaps indirectly possible via a business rule checking for the action that was clicked but this will give you a very bad score on the "make maintenance easy" test.
ACLs
Due to the nature of ACLs, it is common to compliment the baseline setup OR replace it completely. Security based access requirements are not so easy to "bail" on.

Document and track

If either Replace or Modify approaches are chosen then consider what documentation and regression testing needs to be in place. In some cases the change to the baseline may result in a rather significant "Deviation" which should be documented with the process that it affects. Eg, modifying the "assigned to" field to not be influenced by the chosen assignment group for the task table would significantly affect how baseline behaviour works across multiple processes. This "Deviation from standard" should be tracked and a planned deprecation or steps to deprecate and return to baseline behaviour should be reviewed prior to releasing the functionality.

Good documentation will also serve as excellent onboarding material for developers, architects, product owners etc. that need to better understand the context to the customisations including what was considered but perhaps not appropriate/approved at the time.

Summing up

Clearly define and educate the team on both architectural and technical guiding principles and best practices. The above lists can help.
Leverage technical review boards and get approvals for changes both before development and before release to confirm impact.
Consider the options of "Bailing", "Complimenting", "Replacing" or "Modifying" configuration to solve the challenge where to "Bail" should always be the first choice of action.
Document significant customisations (aka "Deviations") and plan their deprecation.

The attached document "Customisation decision flow" can also serve as a guide for specific cases.

Artur Makowski · ‎06-01-2022

Hi,

Good reading, thanks!

As part of some presentations given by ServiceNow some time back, I have seen the "pyramid of customisation impact". It was visualising the possible impact / risk associated with adding own and customising different types of objects (as examples - UI Poicies at top, meanig low risk, ACL near the bottom, meanig highly risky and generally not advised to touch).

I'm trying to find it now through the docs and community but with no success. Maybe anyone could help in finding it?

To me this belongs to the thread here - how to judge and decide on impact of attemted customisation and which objects to prefer for updates (typically there are some technical alternatives for the solution)

With Regards,

Artur

Dan Covic2 · ‎06-08-2025

Great insights, much appreciated!