For those businesses whose processes fit within ServiceNow’s out-of-the-box (OOTB) capabilities, that functionality is absolutely the right way to go. And even if you don’t think your processes align, it may be worth reevaluating to better align to ServiceNow’s offering.
But just because you go with the OOTB option doesn’t mean it is smooth sailing. There is still a right and wrong way to configure ServiceNow, and I’m going to walk through the right way here.
If you leave this post with nothing else (please don’t do that), let it be this: add to the system, don’t modify what’s already there. When you modify fields or other areas of the platform – even changes that are seemingly very minor – it can impact tons of scripts, rules, flows, processes, and conditions behind the scenes that stretch much further than your seemingly small change.
Here’s a common use case. Say you have a field that you want renamed or wish to add drop-down values. By making that change, you now have a field that you are potentially using for a different purpose than ServiceNow intended, and there are reports, scripts, accesses, and more based on the original field name or values that is now considered completely different. The downstream ramifications can be massive, even coming from the smallest changes, especially if that field is shared to other areas of the platform.
More importantly, that modification then is registered in ServiceNow as a customer-updated element. Why is that a big deal? Well, when ServiceNow goes to upgrade or patch the platform, it won’t touch components listed as customer-updated, because the software doesn’t override what you have done to your platform.
ServiceNow updates its platforms twice per year, which means you are now taking on additional overhead to update those areas yourself. And if you have made hundreds of small modifications, it could take months each time just to upgrade what ServiceNow would have done for you.
Like upgrades and patches, support is included in your licensing agreement for your environment directly from ServiceNow. However, ServiceNow supports out-of-box functionality. If you alter things such as out-of-box fields, this becomes another layer of technical debt as you will be responsible for supporting the platform’s use of that data in correlation to enhancements ServiceNow will have over time with upgrades. Adopting new features and functionality can therefor become another set of challenges you will face.
Avoiding modifications doesn’t mean you’re just stuck with the OOTB functionality as is and cannot change so much as the name of a label. While Adding customizations to fields or areas is liable to cause headaches, adding entirely new fields can often be the right approach, and there are specific methods to use for re-labeling a field in a specific area of the platform to achieve the desired outcome without damaging the native design and taking on unnecessary technical debt. A ServiceNow partner with experienced resources, such as Veracity, can help you evaluate the implications and guide you through the evaluation of the desire and correct methods to utilize.
Completely new additions and overrides aren’t damaging to the system because these will not conflict with a ServiceNow upgrade or other downstream areas, while reducing your time to value in an implementation. The ability to override or add fields is a benefit of OOTB functionality and encouraged as a way to not just settle for less than you need to be successful.
If you’re reading this and panicking because modifications have already been made to your instance, don’t stress too much yet. While there are no cookie-cutter fixes, you can work with a ServiceNow partner who can run an evaluation to examine your environment, compare best practices, identify the most pressing issues, and develop a recommendation plan.
In the most extreme circumstances, it may also be that your company has made so many customizations that the best course of action is to completely reset and start again from scratch with a fresh implementation. While that feels daunting, it is going to be much less of a headache moving forward compared to dealing with the burden of managing and sustaining unsupported systems and Veracity is able to help you evaluate and conduct this approach as well.
About the Author
Isaac Torkelson is the Director of Delivery for Veracity's ServiceNow practice. Isaac has been working in the platform for more than a decade and leads Veracity's team of experts in delivering solutions across the ServiceNow ecosystem for clients in the commercial and government industries.