This is your ServiceNow platform when following prescriptive guidance blindly.
In one hundred meters, say 'to heck with it' and drive your car into the lake.
- that sounds about right.
ServiceNow is an excellent partner, as it actively tries to give every customer what it needs in terms of free resources and training. What really differentiates the company is the fact that they provide prescriptive guidance.
That is extremely valuable, as a platform's implementation and continual improvement leave much guesswork about good practice.
An unfortunate tendency of the human mind is that it shuts off as soon as someone in authority tells it what to do.
For example, these three articles reporting on people who drove into lakes because their GPS told them to.
That was just a subset of the first Google page.
Keep in mind that I am not saying that you shouldn't take the advise of ServiceNow to heart. I am saying that you should consider what the advise means to your specific context.
Never Hardcode a sys_id
We all know about this one.
Easy fix, we create a property referenced via gs.getProperty('best_practice_property');.
There - the issue is fixed!
Technically, yes. Practically, not at all.
Instead of just following the guidance, let's think a moment about it.
-
It makes sense not to have a hardcoded sys_id in your code, as the record it refers to may be subjected to operations that would change the code's functionality. It is a liability.
-
It makes sense to have the sys_id stored in a property, as that scopes our code. We only need to change the property should we need it in the future.
All good, though:
-
How will we know that we need to change the property?
-
Who will be notified?
-
How will they be notified?
-
What is the business impact if the record being referenced by the property changes?
-
How will we be able to find the property in the future if we are not happy about trawling through the endless sys_properties table?
Always remember that a business context exists besides technical governance. Sure, you should never hardcode sys_ids, though the alternative of storing it in a property must be thought through.
You might want to set up notifications that trigger on operations that would imply a need to change the sys_id of the property, as well as where to find it.
Depending on the supported business criticality you could even consider making an automated incident if a mismatch would occur between the sys_id of the property and the script. (e.g. a group for 1st line support, referenced in the property, is changed or recreated and now your escalation script does not work anymore as it refers to a deprecated group).
You might want to include the new property in an existing property page, or create a new page entirely.
In summary: ServiceNow provides excellent prescriptive guidance. IT must be carefully considered and followed, though you need to follow it in a mindful manner; drive around the lake to get to your destination not into it.
