The genesis of misconceptions, how they spread, and what to do about them
Introduction
I’ve written two previous articles about ServiceNow as a platform to-date, focusing on the vision of the founders of the company and how that translates to developing in and configuring it. While I focused on good practices and understanding what ServiceNow is at its core, I also touched on some of the misnomers that have spread throughout the ecosystem. As it has rapidly expanded in recent years, it seems these misnomers have become more pervasive and more ingrained. And unfortunately ServiceNow management and marketing don’t seem to do anything to dispel them; rather, I hear ServiceNow employees repeating the same misconceptions to customers.
In the interest of both education and truth-telling, I will spend some time going through these misnomers and dispelling the notions and explaining the realities.
A World of Misinformation
When I recently heard someone say “we don’t want to customize” or “stay out of the box” for the umpteenth time, I came up with this rebuttal:
Those who say “stay out of the box” are essentially saying “we do not trust ourselves to develop solutions on a platform designed for developing solutions, we only trust ServiceNow’s developers* to do it for us.”
* Which of course ServiceNow is more than happy to do, with a big, fat, and ever-increasing licensing cost.
Where do these misconceptions come from, and why do they become pervasive? In my experience, most of these come from people’s previous experiences with other tools and platforms. A “what was true in the past, must be true in the future” kind of thought process. Most IT leadership has been doing it for years, and have paid the price of customization, building versus buying, allowing “shadow IT”, etc. And most leadership is risk-averse. There is a whole discussion to be had around management philosophy and risk, but we’ll save this for your next MBA course. Suffice it to say that management’s focus is generally on reducing risk and cost. So around this mindset, IT leaders who are in the business of messaging and not of deep understanding are happy to lean on these tropes to justify it.
Ecosystem Examples
Let’s look at some specific misconceptions and pick them apart. We’ll start with the simple and more innocuous ones, and move to the ones that actually lead to poor decision-making.
“The So-and-So Module”
Everyone seems to call Incidents, Changes, Customer Service Case, and all the equivalent, “Modules”. These are actually Applications in ServiceNow nomenclature. Modules are the links in the left-hand navigation. For example, Incident is the application and the links to “Create new”, “Open”, “All” and “Dashboard” are modules. Not really sure how this happened, other than other platforms call them modules (I think?). But I wanted to specify this since I will be calling them Applications throughout the rest of the article.
“Stay Out of the Box”
We’re going to skip the part about ServiceNow not coming in a box – too easy. I think what is generally meant by this is don’t mess around with the applications that ServiceNow provides. Use them as designed by ServiceNow. I don’t think this is an inherently bad idea. It’s nice if you can get your company to adopt the product as-is. But it’s rare. And the cost of OCM may far outweigh a simple customization to a ServiceNow built application. And if ServiceNow is built as an extensible platform, what’s the harm? Well, this leads us to our next overused phrase.
“Configure, Don’t Customize”
I would challenge anyone who says this to define what exactly is meant by configure and what exactly is meant by customize. And then I’ll wait and watch them stumble around for answers. I think what folks tend to default to is anything that doesn’t require code is configuration, and anything that does is customization. This is a good thought, but it’s far too simplistic to encompass everything. More importantly, this is a concept everyone working on and managing needs to understand:
There are configurations that will get you into big trouble, and customizations that are completely innocuous.
If you take nothing else from this article, take this away.
When I speak of trouble and innocuous, I mean from an upgrade perspective. Know that some of the things that ServiceNow makes very easy to do can put your upgrades in trouble, and some of the things that are massively custom will not cause you any upgrade issues at all.
As usual, this is best illustrated with examples. So let’s look at a few.
Example 1: Adding, Modifying, Deleting a State
As you probably know, editing many drop-down choice lists in ServiceNow is as simple as right-clicking the field and having at it. Simple configuration right? Well, the action is simple, but the results can be quite problematic. If you’re working with a ServiceNow provided application, the out of box configuration likely has quite a bit of process logic built into it that involves the State field. Including an expectation that these values will not be changed. So changing these values (and note that “values” is an important distinction from “labels”) can cause the application lifecycle processes to break, or future upgrades to skip or fail. At the very least, you should be thoroughly analyzing the entire application configuration before making any changes to States; but you should start with “do no touch” as your baseline.
Example 2: Adding a New Field
I’ve found that leadership tends to get antsy about adding to the out of box database schema. But to dovetail with example 1, unless your new field injects itself into, and alters the designed lifecycle of an out of the box application, it really doesn’t matter all that much. By its nature it is marked as customer-created, and upgrades don’t care about it at all, and you will never have an upgrade conflict.
“Always Scope Your Applications”
If you do choose to create a completely new application, the prevailing wisdom is to create it in its own scope. I’m not going to go into a deep dive on whether to do this or not as I’ve written about it and my experiential knowledge of it in a previous article, but the reality is that using a scope is neither a requirement nor a path to save you from trouble. The rules for developing an application, much like doing anything on the platform, are if you contain it to the table(s) and its design elements (as the ServiceNow founders intended), you will be upgrade-safe and trouble-free regardless if you use a scope or not. (And there are plenty of benefits to not using a scope in my other article.)
Conclusion
As ecosystems grow in size and importance, there’s a tendency for catchphrases and concepts to “catch-on”, and over time become conventional wisdom. The ServiceNow ecosystem is no exception. Like these things in almost all aspects of life, upon deeper inspection and historical investigation, many can be proven to be not quite accurate, or worse, almost wholly false. It’s wise to keep your thinking cap on while listening to and absorbing these things.
Finally, consider this: The folks at ServiceNow aren’t better or smarter developers than you or I. They simply have more access to source code. As I like to tell people when they consider using out-of-box or developing on their own, “ServiceNow does not have a patent on the correct way to do things.”
Go forth and develop wisely…
