---

The following is a summary of my presentation Customization Calamity – Mistakes to avoid when extending OOB apps given at Knowledge24 in Las Vegas.

What is customization?

There are a few official definitions of customization in the ServiceNow ecosystem.

Business demands for custom functionality; changing baseline business rules or developing new applications from extensions

Business Smart Customization 2023

Any change to code that is part of the baseline install of a ServiceNow instance

Customization vs configuration | FAQ and guidelines 2023

Extending out of the box applications for complex business requirements

Deliberate Customization, Certified Technical Architect 2023

Outside of North America, Customization is spelt with a ‘s’. I use my own definition of Customisation (with an S) when working with clients, which I define as

• Changing the way a feature works contrary to documentation/intent
• Making a platform change that increases time to upgrade
• Making a platform change that may creates technical debt

Leading Practices

ServiceNow recommends applying “Business smart” customization, which means evaluating if the business value outweighs the development and maintenance cost.

Business Smart Customization Leading Practices

The top 6 leading practices below were based on the 2021 best practices and are as follows:

1. Avoid copying object*
2. Add before edit
3. Use the ServiceNow no and low-code capabilities
4. Use scoped applications
5. Document all customizations
6. Use Healthscan

*Except for items designed to be re-used, such as Service Portal widgets and flows

ServiceNow updated its guide in April 2023, which can be found here. The guide includes guidance on evaluating customization.

When I evaluate proposed customizations, I consider the following:

• Does it change the intent
• Will it contradict vendor documentation
• How often is object changed by upgrades
• Priority of changed object
• Can object be merged
• Support overhead of making change
• Could it be replaced by OOB capability in future

Customization Examples

Lets consider to customization examples and look at the pros and cons.

UI Action

Application: Global (ITSM, SOW)

Scenario: We need to map the type field from interaction to incident. The mapping is done in the OOB UI Action on the interaction table.

Let’s look at some different development options we have:

Development approach	Leading Practice	Pro	Con
Update Create Incident UI Action	Avoid copying object	Code changes made with similar code	Customized object may increase time to upgrade
Create new business rule to map extra fields	Add before edit	No impact on upgrades	Logic for field mapping in different places makes solution harder to support
Create new Flow	Use low code capabilities	Flows are easier for no/low code users to understand	Logic for field mapping in different places makes solution harder to support

Customizing a Flow

Application: Certificate Inventory Management

Scenario: We need to set the impact/urgency of the incident based on the customer’s priority matrix. This is done in an OOB Flow.

Let’s look at the different development approaches we have:

Development approach	Leading Practice	Pro	Con
Update the flow	Avoid copying object (except re-usable components)	Logic change is made where it is expected to be	Flow is now customised. Future changes by vendor cannot be merged.
Create new business rule to correct priority	Add before edit	No impact on upgrades	Logic for priority mapping in different places makes solution harder to support
Create new Flow	Use low code capabilities	Flows are easier for no/low code users to understand	Logic for priority mapping in different places makes solution harder to support
Update customisation subflow	Intended place for customisations	No impact on upgrades	Incident is already raised as incorrect priority triggering workflows by the time correct priority is applied

Mistakes to avoid when extending OOB Apps

The right solution to a customization problem can depend on several factors and is not always clear-cut. As with most things, the answer is “It depends”.

That being said, there are three apparent mistakes to avoid that we discover that comes from this thought exercise:

1. Thinking customization is always a bad thing
2. Not agreeing on a definition of “customization”
3. Over-engineering solutions to avoid customization