Top 5 ServiceNow Mistakes: 
The Anecdotal Edition, Part One 

Introducing a new platform into your business requires a lot of training and knowledge transfer, and can even involve hiring a brand new team or outsourced resources. You might have the platform looking all pretty, but a few different areas that aren’t adding up...I’ve compiled a list of my favourite rookie mistakes that Unifii often see with our customers, and how you can easily overcome them.  

1. The curse of the 'Update Set'

Welcome to ServiceNow, where almost everything you do that will mean something to a customer (in terms of configuration) will eventually find its way into an Update Set.  

Let’s take a step back for analogy time. Have you ever done a supermarket shop and realised you need a lot more than you initially thought? Chances are you didn’t pick up a basket in the first place, and so you make your awkward way back to the front of the store to get one. Now, with your newly appointed carrying-contraption, you make your way through placing in your required items as needed.  

We can compare this to the traditional way of developing within ServiceNow. When developers receive a new requirement, they often want to buy everything in the store - i.e., configure the platform to their heart’s content. However, jumping the gun can mean they forget to pick up a basket – in SN terms, they’ve forgotten to create an Update Set for all their configuration changes.  

Making the above mistake will cause you more pain than it’s worth. Why? Because configuring without an Update Set is akin to scattering 500 tennis balls in different directions – after making your changes, you then have to pick up all those tennis balls (or collect all your updates into your Update Set). Incredibly time consuming, no?  

Within ServiceNow, you want to be following this guideline:  

1. Create an update set 

2. Make your configuration changes based on requirements  

3. Close the update set when finished   

4. Promote to QA for testing 

Sticking to the above ensures you always pick up the latest edit from each object in your Update Set. 

2. Sys ID? Tell me more...

Have you ever lost a suitcase you didn’t label with your name and address at an airport and then spend hours trying to get it back? You eventually find it, but clearly labelling the suitcase may well have saved valuable time. 

A Sys ID is a Globally Unique ID (GUID) that identifies each record in an instance. If we say our suitcase is a Sys ID within a SN script, the only way anyone can know anything about that Sys ID is if it has been labelled properly. Because unlabelled Sys IDs tell you nothing useful, they are impossible to understand based purely on their 32 alphanumeric characters. Using System Properties within SN is the equivalent of labelling – they should have well-defined names and a good description. Not doing so will cause you and your team more pain and misplaced suitcases than avoiding this best practice is worth. 

3. When two wrongs make a right

If your grandmother ask you to go out and pick up eggs and bread but you only come back with bread, does she give you that evil look that sets your nerves high and your chin low? Since you only brought back bread, you haven’t met her requirements. If your grandma asked you to go out and pick up eggs OR bread, you would have met her criteria.  

This time, she specifies she doesn’t want eggs OR bread, and you buy eggs along with a host of other items. You explain to her "you said you didn’t want eggs or bread.” In logical terms, we can take this to mean “I don’t want eggs OR I don’t want bread.” But there’s a flaw here: technically, the first request (“I don’t want bread”) can be interpreted as “get me anything except bread.” This then makes buying eggs valid. I can hear you thinking “...but what about the first criteria that said she doesn’t want eggs?!” Well, think back to the first request which we modified to meet her needs: “I want eggs OR bread" - either one will do to make her happy. We have an OR here: "No eggs OR no bread” - meaning that meeting either one will do. Therefore, if you buy eggs, you have satisfied the criteria. Of course, grandma is unlikely to see it that way so you may want to do a runner stat... 

Now to apply the above to ServiceNow. Let’s say I ask you to filter an incident list to give me anything except where the state is Closed or Cancelled. How would you achieve this, assuming we can’t use positive logic i.e., state IS <any state>? We also can’t use the ‘Filter Out’ option.  

The OR condition is the crucial thing here: you are requesting incidents which are not Closed (allowing for Cancelled incidents) OR you want incidents which are not Cancelled (allowing for Closed incidents). As we want to exclude both, we need to use the AND function in order to filter out both Closed AND Cancelled states. What should grandma have asked instead...? I’ll leave that to you to figure out and inform her - just do me a favour and let me know how that goes for you. 

Stay tuned for part two: a completed list of common ServiceNow mistakes and more of the most elite analogous stories you’ve come across!