Recently I was with one of the clients. I will not be disclosing her name but for the sake of convenience let us call her Ms. Annie. We were in a discussion of a story related to ITSM implementation. Therefore, for that story, I told her this would be minor customization and we can easily achieve this. And as soon as she heard the word “CUSTOMIZATION” she was like:
Danger customization!!!.
If you could recollect this fictional character from lost in space who could feel a threat for Will Robinson. Her fear was correct because 90% of clients who went for unplanned modification they are struggling with their upgrades. But at the same time, we forgot that Servicenow main power is its platform. After all its platform of platforms. It's really important to understand the difference.
So, if you try to understand the image it’s not like if it is not OOB it is in danger zone. There is a region where the customization is not at all harmful. Important is to understand the thin line difference and this article will help you understand that.
Disclaimer 😆 This article is an amalgamation of my experience, some of the official ServiceNow documents, one of the amazing knowledge session by one and only Travis Toulson. Use it for reference but don’t consider it as something carved in stone.
Ok, let’s start with an understanding of some of the key terms i.e. customization, configuration and custom application development.
Customization--> A customization is any change to code that is part of the baseline install of a ServiceNow instance.
Configuration--> includes capabilities and/or features on the Now Platform® that enable organizations to deliver against “custom” business demands in a safe and supported way (such as modifications to forms or table extensions). While organizations should avoid over configuration—for example, by adding excessive forms or UI policies—they should still use configuration as a first or preferred option for meeting business demands.
Custom Application Development--> includes custom development on both ServiceNow applications as well as the development of new applications by changing baseline business rules or developing new applications from table extensions. Custom development is recommended only where configuration cannot meet business demands and should employ recommended tools and methods as well as be supported by clear governance.
So, now the question comes how to decide whether we should do this customization or not because excess customization can build up technical debt and lengthen your upgrade cycle, inhibiting your ability to take advantage of new features?
Strategy for verifying update if the update is valid:
Step 1-> Calculate Bscore
Bscore stands for the importance of customization from a business perspective. Its value ranges from 1-5.
|
Case |
Score |
|
Customization is required for regulatory and compliance purposes. |
5 |
|
Customization is a "must-have" to realize a business value objective and/or adoption requirements. |
4 |
|
Customization supports the realization of a business value objective and/or adoption, but workarounds are available. |
3 |
|
Customization supports service experience for service consumers, process users, and/or developers but does not necessarily promote a business value objective or adoption. |
2 |
|
Customization does not support improved service experience, value realization, or adoption. |
1 |
Step 2--> Validate your Bscore using this table where the case stands for the level of customization
|
Case |
Min. Bscore Required |
|
Extend an existing table in scope with some scripting |
3 |
|
Build a new scoped application |
4 |
|
Build a new global application |
4 |
|
Change baseline business rules |
5 |
|
Build complex, custom integration |
5 |
So, if your Bscore validates this table then the effort put in customization justifies the value involved.
Okie now it’s time for some:
- Avoid 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 the 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 out-of-the-box 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.
- UsetheServiceNow®no-and low-code capabilities wherever possible, including use of UI policies (before writing client scripts), Flow Designer (over business rule scripts), IntegrationHub (before writing custom integrations), and other capabilities.
- Use scoped applications as your default for any new custom development. Scoped apps are annoying but definitely protective!!
- Document all customizations. Add comments to explain why you customized (including business justification), and ensure you review all comments prior to upgrading, to determine if you can revert to out-of-box.
- Create tests for all customizations. You should ensure that you write Automated Test Framework (ATF)tests for all customizations where possible.
- Use HealthScan(Instance Scan – a feature from Quebec release can also be explored) regularly to identify unnecessary customizations.
How is customization going to affect upgrades? How to deal with this?
New records or changes to out-of-the-box records that stem from customization or configuration become "skipped changes" if ServiceNow updates the same records as part of a release, e.g., from Orlando to Paris. Upgrades do not overwrite changes that a customer has made, so customers need to review their skipped changes and determine whether to revert to base, merge, or keep their changes. This review can take time – meaning that the more customizations a customer has, the more time will be required to review skipped changes as part of the upgrade process.
ServiceNow upgrades will not overwrite customizations you have made but will mark them as skipped records in the ServiceNow Upgrade Monitor. To make sure they’re successfully ported to the upgraded instance, you must manually process the skipped changes.
Assuming you’ve documented all your customizations—including business justification—take your documented inventory and compare it with the skipped records identified in the Upgrade Monitor. After filtering out low-risk changes that have resulted in skipped records (e.g., field labels or form layouts), you’ll need to decide whether to:
- Retain each customization
- Revert to out-of-the-box
- Merge your customization with the base system to resolve conflict
Few more resources to consider:
How to review Skipped Changes?
Strategy for Implementing Integration
If you find the article helpful, please mark the article as helpful, and do remember to bookmark this article.
In case you need any help, please do connect with me. It will be my pleasure to help you.
Happy Learning Guys!!!
----->Dhruv Gupta
