Customization vs configuration | FAQ and guidelinesIssue The information below outlines the differences between customizations and configurations and provides information and guidelines about each. For further details about ServiceNow customization best practices, see the link to Now Create at the bottom of the page. What is a customization? ServiceNow uses customization to refer to business demands for any form of custom functionality. What is a configuration? Configuration includes capabilities and/or features on the Now Platform that allow you to deliver against custom business demands safely and supportable, such as through modifications to forms or table extensions. While you should avoid over-configuration—for example, by adding excessive forms or UI policies—you should still use configuration as your first or preferred option to meet business demands. What is custom development? This includes custom development on both ServiceNow applications and new applications you develop by changing baseline business rules or developing new applications from table extensions. Custom development is recommended when configuration can’t meet new business demands; it should employ consistent, recommended tools and methods and be overseen by clear, effective governance. Examples: Configuration vs Custom Development Example of a configuration: Before an Incident is promoted to a Major Incident, the Business impact must be a mandatory field. If it is not provided, the record should not be updated.A UI Policy, one of the many tools within the platform for tailoring specific functionality to meet specific requirements, can be used to meet this requirement. Example of custom development: You are in the process of implementing the Service Catalog and have a requirement to add additional fields to gather data on the catalog checkout page.The catalog checkout page is a Service Portal Widget that is part of the baseline installation of an instance. A change to this code would be considered custom development.Someone builds a new "custom" feature into the product (e.g. custom applications, 3rd party widgets, etc.). ServiceNow support will provide troubleshooting guidance, but the customer is responsible for ownership of maintaining and fixing the feature.FactsWhat if you decide to customize code that is part of a baseline installation? Since the code is part of the baseline installation and has been customized, the following would occur: You would need to maintain that code going forwardYou would be responsible for making sure that functionality still works after an upgrade Can you still receive support on a customization? Yes, you can still receive support on a customization; however, if it is determined during a support call that the customization that was made is the cause of the issue, the support team would advise you to revert back to the code that was part of the baseline installation so that the support team can assist you. What are the ramifications of performing a customization? The ServiceNow platform is extremely flexible and can fulfill a wide range of requirements. However, the ServiceNow platform uses a framework that supports these different applications in how they process tasks, how forms are rendered in multiple browsers and the overall user experience. ServiceNow relies on the framework's integrity in order to develop and provide support in a consistent manner. If you have requirements and ideas for enhancements, you can submit an Enhancement Request to the ServiceNow development team. Each request is evaluated and, if approved, will be incorporated into a future release.ReleaseThis asset is not specific to a release.ResolutionIt is critical to understand what a customization is, and how it can impact before deciding to carry it forward. 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. If it is essential that a customization be made, you should adhere to the following process: Establish the Business-smart customization approach (linked below) to ensure customizations are limited and clearly linked to business valueAvoid copying objects – Instead, update objects in place wherever possible, except for Service Portal widgets and other items designed to be reused.Default to add before edit – This means that you should, for example, add fields to forms rather than change the type of an existing field. When adding, avoid using the same names as OOTB objects, methods, or classes. Keep the number of fields you add to a minimum—the more fields you have on a form, the longer it may take to load.Use scoped applications as your default for any new custom development.Cleary document what has been customized and for what reason - this will make future maintenance significantly easier. Administrators are responsible for verifying that their customizations work after an upgrade, and for keeping track of what customizations were made.Related LinksA PDF guide on ServiceNow customization best practices can be found on Now Create: Business-smart customization This document focuses on business-smart customization for ServiceNow, emphasizing the importance of evaluating customization value against risks and technical debt. It provides a comprehensive guide on implementing customization in a value-driven manner, ensuring upgrades and platform performance are not adversely affected.