The ServiceNow Nerd

The musings of a ServiceNow platform developer and enthusiast

The SN Nerd

Mistakes to avoid when customizing out-of-the-box apps

by snnerd
299 views

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.

OOB Field mappings between Interaction and Incident shown in red
Field mapping code from Create Incident UI Action

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

Development approachLeading PracticeProCon
Update Create Incident UI ActionAvoid copying objectCode changes made with similar codeCustomized object may increase time to upgrade
Create new business rule to map extra fieldsAdd before editNo impact on upgradesLogic for field mapping in different places makes solution harder to support
Create new FlowUse low code capabilitiesFlows are easier for no/low code users to understandLogic for field mapping in different places makes solution harder to support
Development approaches for updating a UI Action

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.

The incident is raised for an expired certificate with priority based on renewal tracking. Mapping is based on the OOB priority matrix, which does not match the customers.
Impact and urgency is set in the Update Incident Record flow action. Note there is a Customisation subflow.

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

Development approachLeading PracticeProCon
Update the flowAvoid copying object (except re-usable components)Logic change is made where it is expected to beFlow is now customised. Future changes by vendor cannot be merged.
Create new business rule to correct priorityAdd before editNo impact on upgradesLogic for priority mapping in different places makes solution harder to support
Create new FlowUse low code capabilitiesFlows are easier for no/low code users to understandLogic for priority mapping in different places makes solution harder to support
Update customisation subflowIntended place for customisationsNo impact on upgradesIncident is already raised as incorrect priority triggering workflows by the time correct priority is applied
Development solutions for updating a Flow

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

Related Posts

Leave a Comment

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More