As I recently had again a discussion about naming conventions for ServiceNow artifacts (any kind of application files you can create like Business Rules, Client Scripts, UI Actions, etc.) I decided to write down my thoughts on that topic. If you ever find yourself in a similar situation, all you have to do is referring to this post instead of engaging in heated debates.
This article is not about scope names or company codes. It is about setting values in the "Name" field or sometimes also "Short description".
What's the trigger?
Although I have not been able to find an official Internet source anywhere, I know from personal experience that ServiceNow recommends using the customer name (or an abbreviation) in combination with an underscore as a prefix for artifact names as often as possible.
For example, a custom Script Include "SparePartUtils" for the customer "ACME" would then have to be named "ACME_SparePartUtils".
As a reason for this naming convention it is always stated that in this way a better distinction from the self-created artifacts to the OOTB artifacts is possible.
And in the following chapters, I will show why this makes no sense in my opinion.
Customer or Vendor Prefix?
In my past projects, I was mostly engaged by customers who hired more than one vendor for ServiceNow development. I think a name prefix would only make sense here if the artifacts created were given the name prefix of the vendor. In this way, the platform owner would be able to distinguish very well between the deliverables of the individual vendors.
What happens when the name of the customer's company changes?
Okay, I admit it: This is quite a rare case. But if the company name actually changes, and you are asked to modify all name prefixes, it cannot be done just like that. Script Includes as well as UI Scripts are referenced by name, and you would have to replace all occurrences of the script name throughout the system. This can have unpredictable impacts and is therefore not worth the risk.
The problem with the underscore
For the name of Script Includes or UI Scripts no white spaces or dashes are allowed, and thus the underscore has been chosen as alternative. However, in this way, the naming convention for these artifact types is violated. Therefore, to meet the requirements, the name would have to be rewritten to "AcmeSparePartUtils". On the other hand, all other artifact types such as Business Rules or Client Scripts do not have the limitation of a character set and are specified in multiple space-separated words. Therefore, the name "Hide dates based on month" for a Client Script would look weird if you wrote it "ACME_Hide dates based on month"
A prefix cannot be added consistently
If you go through all artifact types, you will notice that quite often a prefix cannot be used. For example, the name of a catalog item is used one-to-one in the service catalog. While this is still a purely cosmetic issue, there are a few places in the system where a prefix breaks an existing functionality. I once had an SSO script causing me a few headaches, because I had provided the script with a customer prefix as required, but was unable to select it in the SSO provider record:
Having a look at the dictionary entry of the field "Single Sign-On Script" reveals the cause:
That means you cannot prefix the SSO Script name, as it wouldn't be possible anymore to select it.
Furthermore, there are some artifact types which don't have any individual name, and thus you cannot prefix them. ACLs are only one of the most prominent examples.
And finally, if you don't build a custom application but just modify OOTB artifacts, you will not change their names to minimize any unintended implications.
Redundancy is evil, but what is the solution?
In the IT industry, redundancy is always a sign of poor data design. In the field of databases, therefore, there is the concept of normalization, in which redundant values are swapped out into reference tables. That way, you only have to change a value in the reference table once, since the referencing tables contain only the reference to it instead of the value itself.
And by using name prefixes you have redundancy which is not necessary as there is a unique container for all custom created artifacts - the application. By prefixing the application name and enabling the application column in the list view, you have the same concept at the end but without redundancy:
| 🛈 |
If this post was helpful to you, I would appreciate it if you would mark it accordingly. If you want to read more from me, you can go to the list of all my articles. |
7 Comments
