Besides Technical Best Practices there are a few things to keep your instance clean and tidy. In this short post I will collect a few best practices that go beyond ServiceNow’s Technical Best Practices.
Organizational Guidelines
Following suggestions are a kind of organizational best practices when implementing Solutions in ServiceNow.
- No complex* solution without options and a clear decision
Before a solution is implemented, there have to be at least two different approaches to the problem solution which can be evaluated and decided on; the evaluation and the decision need to be part of the documentation; the customer decides after understanding the implications of all available options. Options and decisions (with rationale) need to be part of the documentation.*Complex = integrations (per se / always) or solutions that require more than two entities to be involved (e.g. a functionality that requires a ui action, a business rule and a change to / the creation of a script include) - Peer Reviews
Share your solution designs with a team member (preferably the Architect / Lead Developer) and discuss it before you move it to the next environmental stage - Code Reviews
Do a code review at least before you move to the next environmental stage; use existing tools (e.g. ServiceNow ACE Reports) for that. - No changes to Prod without an update set
Well never ever do changes to productive environments, except you commit them via an update set. Any exception to that rule needs to have a clear definition (and a plan to re-sync Prods and Non-Prods). Basically, there shouldn’t be any exception to this rule. If you think you have an exception, challenge yourself to find another solution design — do this at least three times. If this is then still your exception then, consult someone externally. - Debugging on Test: Changes to Test need to be revoked if done for debugging
Sometimes you need to do changes to the test environment to do a root cause analysis (e.g. temporarily deactivate Business Rules for cross-diagnosis).What ever changes you make, make them temporarily! All changes needed to find the root-cause of a bug / misbehaviour need to be revoked to allow independant testing of implemented bugfixes
Besides these best practices it is advised to assigned (and live) following roles within the ServiceNow implementation team:
- Developer
(what a no-brainer) - Architect / Lead Developer to act as the main peer
(ideally sourced externally and independently from the developer(s) to act as an quality assurance instance) - Product Owner
(Customer’s representative)
Coding Guidelines to be highlighted
Although the Technical Best Practices published by ServiceNow, Inc. (https://developer.servicenow.com/app.do#!/catlist/technical_best_practices) are very good already, I want to stress a few that I stumbled over far to often to not mention them again, and again, and again… even, if they actually are common sense.
- Stick to your provider-internal developer guidelines
- Use descriptive, specific names for variables and functions
- Use code-indention and blocks (e.g. separated by blank lines) on purpose
(… to visualize different parts / “stages” with different functionality) - Make useful comments
While sometimes a small Business Rule really explains itself (e.g. one line of code, non-code Conditions, descriptive title), there are huge monsters of code out there. Useful comments are meaning to me to answer the following questions:- What (abstractly) does the following block of code do?
- why does it do that? (e.g. decision of a customer with date and time or to prepare data for further processing)
This not only applies to complex algorithms but also to e.g. hard-coded values — basically anything, that isn’t obvious in the first place! (and no: numbers, like states from a state field, are not obvious in their interpretation)