Best Practices in Updating OOTB functionalitis

[LOKESHKUMAR]

Hello All,

I would like to understand the ServiceNow best practices for modifying Out-of-the-Box (OOTB) functionality. For example, if there are OOTB Business Rules, Client Scripts, UI Actions, Script Includes, or other platform components that need to be updated to meet business requirements, what approach does ServiceNow recommend?

Is it considered a best practice to modify the OOTB components directly, or should we duplicate, extend, or override the OOTB functionality and implement customizations separately? I am particularly interested in understanding the recommended approach from a maintainability, upgrade, and supportability perspective.

Additionally, I have heard that ServiceNow is now recommending updating the OOTB functionality itself in certain scenarios rather than creating duplicate customizations. Is this accurate? If so, what is the current ServiceNow guidance, and in which situations would modifying OOTB records directly be preferred over extending or customizing them separately?

[Tejas Adhalrao]

hi @LOKESHKUMAR  ,

ServiceNow's general recommendation is to avoid modifying OOTB functionality unless absolutely necessary. The preferred approach is to extend, configure, or override the OOTB behavior using supported customization mechanisms. This minimizes upgrade conflicts and makes future maintenance much easier.

Some common best practices are:

• Business Rules: Create a new Business Rule with appropriate conditions/order instead of modifying the OOTB rule.
• Client Scripts: Create a custom Client Script or UI Policy rather than editing the OOTB script.
• Script Includes: Extend the OOTB Script Include (where supported) or create a wrapper/custom Script Include instead of modifying it directly.
• UI Actions: Create a new UI Action or override the behavior through conditions or scripting, rather than changing the OOTB action.
• Flows/Workflows: Prefer extending through Flow Designer or custom flows instead of editing baseline flows.

That said, ServiceNow has acknowledged that modifying an OOTB record may be acceptable in limited scenarios where the platform is explicitly designed for configuration (for example, updating notification content, UI policies, or certain configurable records), or where creating a duplicate would introduce unnecessary complexity. However, this should be the exception rather than the rule.

Before modifying any OOTB artifact, consider:

• Will this create upgrade conflicts (Skipped Records)?
• Can the requirement be achieved through configuration or extension?
• Is there a supported extension point provided by ServiceNow?

As a rule of thumb:

• Configure when possible.
• Extend/Override when configuration isn't sufficient.
• Modify OOTB directly only when there is no supported alternative and the impact is understood.

If you found my solution helpful, please mark it as Helpful and Accept Solution.

thanks,

tejas😊

[Tanushree Maiti]

Hi @LOKESHKUMAR 

ServiceNow's core philosophy is to keep your instance upgrade-safe.

The guiding principle is Configuration over Customization—use platform configuration capabilities whenever possible instead of modifying Out-of-the-Box (OOTB) functionality.

To safely modify baseline functionality, leverage the platform's supported extension mechanisms rather than editing OOTB records directly.

Core Modification Strategies

1. Logic and Backend (Business Rules, Script Includes, Flows)

Script Includes

• Avoid modifying OOTB Script Includes directly.
• When possible, extend existing Script Includes using inheritance (Object.extendsObject()) or create a new Script Include that calls the OOTB APIs.
• Override only the specific methods you need while preserving the baseline implementation.
• If inheritance isn't supported by the OOTB class, create a wrapper or separate Script Include instead of editing the baseline code.

Flows and Workflows

• Never modify OOTB Flows, Subflows, or legacy Workflows directly.
• Create a copy (or clone) of the baseline flow/workflow.
• Modify the copied version and update the triggering conditions or references so your custom version is executed.
• Deactivate the OOTB version only if appropriate. Some platform components expect the baseline flow to remain active, so evaluate dependencies before disabling it.

Business Rules

• Avoid calling current.update() inside a Business Rule because it can trigger recursive execution and negatively impact performance.
• Whenever possible, update the record naturally within the current transaction instead of forcing another database update.
• Use conditions and proper rule ordering to minimize unnecessary execution.

1. User Interface (Service Portal, UI Builder, Notifications)

Service Portal Widgets

• Do not edit OOTB widgets directly.
• Clone the widget, give it a meaningful name, and customize the cloned version.
• Replace the widget on the Service Portal page with the cloned widget.
• Do not deactivate the OOTB widget unless there is a specific business requirement. Keeping the original preserves the upgrade path and allows comparison after upgrades.

Notifications

• Avoid modifying OOTB notifications directly.
• Clone the notification when significant structural or logic changes are required.
• Disable the OOTB notification only if both versions would otherwise send duplicate emails.

1. Client-Side (UI Policies and Client Scripts)

• Prefer UI Policies whenever they can satisfy the requirement.
• UI Policies require little or no scripting, are easier to maintain, and are generally more upgrade-friendly.
• Use Client Scripts only when UI Policies cannot accomplish the required behavior.

Upgrade Best Practices

Document Customizations

• Document the business reason for every customization.
• Use consistent comments and naming conventions so custom code is easy to identify during future maintenance and upgrades.

Review Upgrade Conflicts

• During upgrades (Tokyo, Utah, Vancouver, Washington, Xanadu, Yokohama, etc.), ServiceNow identifies conflicts involving customized OOTB records.
• Use the Upgrade Center and Skipped Changes to Review (formerly Upgrade Monitor/Skipped Records) to evaluate each conflict.
• Decide whether to keep the customization, merge changes, or adopt the new OOTB version.

Run Instance Health

• Periodically run Instance Scan and HealthScan (available through ServiceNow) to identify:
• unnecessary customizations,
• technical debt,
• performance issues,
• deviations from ServiceNow best practices.

Additional Best Practices

• Prefer extension points over modifying baseline code.
• Avoid changing OOTB tables, dictionary entries, or ACLs unless absolutely necessary.
• Use System Update Sets or Source Control (Git) for change management.
• Follow Scoped Application development whenever possible to isolate customizations.
• Test all customizations after each family upgrade using Automated Test Framework (ATF).
• Minimize server-side scripting when declarative configuration can achieve the same result.

[Ankur Bawiskar]

@LOKESHKUMAR 

this KB has the info

Configuration, customization, and custom development guidelines for ServiceNow 

also check this

Business-smart customization 

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏