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?

[Aditya_hublikar]

Hello @LOKESHKUMAR ,

 best practice is not to duplicate or deactivate Out-of-the-Box (OOTB) components by default. Instead, you should first use configuration options such as UI Policies, Flow Designer, ACLs, or System Properties whenever possible.  The main exception is components like Service Portal widgets, which are designed to be cloned before customization. 

Best practice

If this helps you then mark it as helpful and accept as solution.