Enhance a Discovery Pattern: Modify An Existing Pattern vs. Create A Duplicate

[Tom Rausch]

What is the preferred method to enhance a Discovery Pattern?

• Modify an existing pattern
• Create a duplicate of an existing pattern and modify the newly created duplicate

Here are some considerations.

• Modifying an existing pattern will generate skipped changes during system patches and new releases. These skipped changes have to be addressed in perpetuity.
• Creating a duplicate pattern can require much more immediate configuration work
  • Add pattern extensions
  • Include the duplicate pattern in the Pre/Post scripts
  • Configure the actions related to CI lifecyles
  • The YouTube video Discovery - Replicating Out-of-the-Box Patterns gives a procedure for creating a duplicate Discovery Pattern.
• A duplicate pattern will not include future enhancements in updated out-of-the-box patterns. The duplicate pattern will have to be reviewed each time the base out-of-the-box pattern is updated.

Opinions on the best practice differ.

• The ServiceNow Community article ServiceNow Best Practises on Instance Customization from February, 2020, advises "Customizations should be made to baseline objects where necessary" and "avoid copying base objects."

Customizations should be made to baseline objects where necessary, so that conflict resolution 
and decision making can be appropriately recorded in the updates. Hidden customizations may cause 
administrators to overlook updates in future assessments in case reverts or merges are necessary.

Avoid copying objects. Instead, update objects in place wherever possible, except for Service Portal 
widgets and other items designed to be reused

• The Knowledge Base article KB0553407 Customization vs configuration | FAQ and guidelines from October, 2025, gives the same recommendations.
• The ServiceNow Success Playbook Essentials for ServiceNow implementation success advises, "Prioritize OOTB options."

• The ServiceNow White Paper Business-smart customization and associated PowerPoint presentation "What Are The Best Practices For Customization?", both from August, 2024, generally advise a cautious, measured approach to implementing customizations.
• In August, 2023, SPOC advised customizations can lead to ServiceNow Customization Horror Stories.
• A undated document "ServiceNow Overall Best Practices" by Haviesh Kosuru advises, "Never modify OOTB scripts, rules, or configurations directly." Rather, clone the item and modidy the cloned item.

@doug_schulze may be able to comment on this post.

[Christopher Hub]

This is a complicated question because it starts with WHY you need to customize a specific pattern.  In my experience, most customizations I review could have been handled with an extension.  Certainly not all, but most.  So, the process begins with an experienced CMDB architect reviewing the pattern and requirements.  If you use an extension, then you solve the problem up front.  It's possible in more places than most people thing.

Assuming that there is no way around customizing a pattern, you need mature governance because you will need to manage that customization. I recommend that customers maintain a configuration registry design to track governed (authorized) changes which create skips.  This would also identify the business justification, and the criteria for deprecation to allow review against future release notes.

So, the customization is required, and you have a governance structure in place.  I suggest duplicating the pattern to create a local version of it.  Typically you would prefix the pattern with your company's abbreviation or ticker symbol, but make sure you have a naming convention. You'd next need to replumb Discovery to launch your custom pattern in place of the baseline pattern.

Lastly, ensure your update process includes review EVERY TIME of the newly updated patterns, and a merge of your customization to ensure that you stay in sync with the main branch.