Thinking (ServiceNow) "Out-of-the-Box"

Solana Beach, CA. | Mar 17th 2020

For a couple years now, I’ve seen different parties in the ServiceNow ecosystem advocating that customers revert their applications to “Out-of-the-Box (OOB)”. I’ve always felt this message is not very and I haven't seen much discussion of this double-edged-sword of instance hygiene. Maybe everyone already gets everything that follows below but just in case anyone out there doesn’t, here is my take on the topic of “Reverting to out-of-the-box” OOB:

The Good

Reverting customizations to their out of the box state will help minimize issues when you upgrade. Every time you do an upgrade ServiceNow is performing a merge of your changes with the latest out-of-the-box changes. Very specifically, if you change a record that ships out of the box then, “you own it”. You will not get the latest version of an out-of-the-box record if you have customized it. This methodology is great for making sure that your customizations are not overwritten but it doesn’t guarantee your applications still work post-upgrade. Meta-data records often have dependencies on other meta-data and when you lock in an old version you risk that they are not compatible with the newest versions of their dependencies.

The Bad

My biggest fear with the messaging around adhering to out-of-the-box is that I feel like it's often delivered without any nuance and so what people are actually hearing is that you shouldn’t do anything custom on ServiceNow. The end-result becomes something close to: “You shouldn’t take your car out of the garage because you’ll have to take it in for maintenance”. ServiceNow is a powerful platform. I would argue (full disclosure I am super biassed) that ServiceNow is the best software development platform available for enterprise applications. I hate to think that people buy it and then don’t ever do anything to customize it!

The Better

At the end of the day, all the reverting to out-of-the-box advice is a bit of a distraction from the better option that everyone can be doing to get through their upgrades more smoothly. What is this better option? Automate your testing! The fact is that even if you get rid of all your customizations that appear in your skip list you’d still be foolish to upgrade without testing. So, while there are insane customizations that you should never do (updating OOB UI Macros comes to mind) a focus on better testing through automation is going to get you more bang for your buck and without having to sacrifice, an instance that actually works to the specifications of your business.

Check out my previous blog post about Automated testing in ServiceNow for more information about automated testing and why its a game changer for how customers upgrade and test their update sets. DotWalk provides an AI powered solution, Bootstrap, that can immediately automate testing of hundreds of use cases on your instance with the click-of-a-button. Tests run natively in ServiceNow’s automated testing framework. What makes Bootstrap different from any other automated testing framework out there is that our software will write the tests for you!

Reach out and we’ll show you how, with the click of a button, you can transform how you do your upgrades!

Final Takeaways

1. You are only creating risk if you are customizing something that ships out-of-the-box not if you’re adding net-new business rules etc.
2. Even if you are customizing something that ships out-of-the-box the risk is minimal if the thing doesn’t have any dependencies.
3. You really, really, shouldn’t customize things that ship out of the box if they have dependencies and you’re doing anything more than just shutting that function or feature off. If you’re unclear what is meant by “has dependencies” then you can just read this as metadata records that have code.
4. Please don’t let irrational fear prevent you from getting the most of your ServiceNow instance where you feel like you can’t do simple, safe customizations like creating new business rules or worse stop you from creating custom applications. This really has nothing to do with the problem that reverting to out-of-the-box aims to fix
5. If you have any high risk customizations and they are in your skip list then strongly consider reverting them to OOB. But don’t waste too much time or money worrying about this. You’re better off investing in automating your testing as a solution to difficult upgrades.