In part 1 and part 2 of my series on large teams, I talked a lot about scripting. There's one more item to cover on scripting and a couple other items to make you work easier in the months and years to come.
Naming standards
This could have been in the style guide post, and I recommend it be part of your style guide document. However, I thought it important enough to have its own article in the series.
Some of the things to consider in your naming standards are:
- Scripts
- Workflows
- Tables and fields
- Events
- Notifications
It sure makes it easy to figure out where your personal collection of change approval notifications are if you name them something like "Acme: Change Manager Approval" rather than just "Change Approval". It's amazing how fast something so obviously named, suddenly blends in to the list of 300 other notifications. If you search for all notifications that start with "Acme:", you can quickly filter out your scripts from the ServiceNow standard notifications. Of course this extends to script names too. How about naming your custom incident events "Acme: Incident Events" or "Incident Events - Acme"?
Be consistent in your table and field names. I recently wrote three similar business rules to maintain tables someone else had created. In each of the three tables, there was a reference field to cmdb_ci. In one table, the field was named "u_ci", in another "u_configuration_item", and in the third it was "u_cmdb_ci". It took me 20 minutes to figure out why my script wasn't creating any entries on the related list because of someone's inconsistency. It's easy to say to yourself "I'll know that. It's so obvious. To YOU perhaps - and perhaps now or for the next week, but not in a month or a year after you've taken your mind off it, and certainly not to someone else." You can always change the field labels to meet the user's display needs (see below), but changing field names is a little more of a chore.
Another place to define naming standards is Update Sets. As your team gets larger and you define what to include in an update set, how often you'll promote update sets, etc. things can get out of hand pretty quickly. Give some thought to a naming convention. Do you want to include a release number? Author's initials, bug/incident number, version (in case the first update set for a specific bug doesn't entirely resolve the bug/issue)? For example, R1_CHG_Bug_100_v01_CWT might indicate Release 1, Change, Bug #100, version 1, and my initials. Fairly informative, albeit lengthy, but that's not a huge concern when you're trying to dig through information on bug 100 to see if it's been promoted from test to production.
It's not hard to think how good names can extend to events, custom system properties, script include names, functions, and more. If your team is small today then this process goes quickly. As you grow, you'll have something to hand to the new team members to ensure they are compliant with your naming standards. If you're team is large and your ServiceNow instance well established, this may take a bit longer. Don't worry about going back to change legacy things. There's really not much value in the effort involved. Just stick to the new naming standards you've developed and over time you should see less and less frustration with the older development work.
Do yourself and your team a favor and agree on naming standards for tables, fields, and variables, functions, scripts, events, workflows, etc. Remember, your "future self" will thank you.
Learn to use Dictionary Overrides
On a couple recent large deployments, we discovered as soon as someone changed a reference qualifier on task.assginment_group, the impact was immediately noticed by the problem, change, and service request developers. The solution - dictionary overrides. To set one, go to the dictionary entry for that field and create an override specific to the table you are using.
If incident needs a reference qualifier on the Assignment Group field and nobody else does, open up dictionary entry for task.assignment_group, go to the "Dictionary Overrides" related list and create a new entry specific for incident.
BONUS: Learn to Use Field Label Overrides
The same was true for people changing the labels on fields. One minute my form says "Configuration Item", the next it says "CI". Who changed it?! Again, go to the dictionary entry for the field and create a new entry in the Labels related list. By putting dictionary overrides together with labels, you can use the same database field behind the scenes, and change the look and behavior of it for that application. Very powerful stuff when it comes to reporting.
1 Comment
