Often customer hire me and soon they say “our instance has some hiccups now and then” — or I try to develop something and stumble over hard to reproduce bugs. As I dig deeper, I find a strange behaviours or parts of the system… I call them the quirks of ServiceNow®.
ServiceNow, Inc. employees sometimes don’t stick to their own pattern
ServiceNow doesn’t cease to amaze me… when you thought, you already know the system, things like this come across…
We already have a Due date? Nah, let’s make another one — one that isn’t recognized as such in scripts…
sys_ or sys?
Who doesn’t know them… the exceptions from the actual rule. Basically, sys_ is the prefix currently used for system base tables. Except:
- sysapproval_approver
- sysauto
- sysevent
- syslog
And due to the rules of normalization a prominent example of how not to name a table:
- sys_properties
Please do better
Whenever you design a solution, please plan ahead and develop a pattern — there’s nothing uglier than “organically grown” solutions where the next iteration is glued to the existing solution.
Having a naming convention in place and a plan on paper (not just in your mind! it needs to be documented!) really much helps you, to stay clean as you are not just trying while implementing!
If you need to try out something: try it on your personal developer instance, go ahead an implement, then re-implement on your actual corporate development environment. Re-implementing avoids taking over non-funcational parts that are just there because you tried and also allows easier “refactoring” e.g. when creating fields that need to be promoted to the base table…
Any further quirks?
You have encounters of the third kind as well? Just contact me at hello@cbc-faruhn.com so that we can share them here.