Neither Normal Change Templates nor Standard Change Approvals are OOB ServiceNow functionality. And having approvals on Standard Change fundamentally goes against ITIL's definition of Standard Change. But how do you implement a way to create routine maintenances that require approval and populate a Change with a template? It has to be one of those ways, but which one?
We are currently revamping our Change Management process, which lead me down the path of solving this problem. I will go over each, list the pros and cons, and reveal which route we decided to take.
Normal Change Templates
To replicate the Standard Change Template functionality on Normal Change you have to copy a lot of stuff. There are a handful of std_change_ tables you would have to create for Normal Change and implement the additional logic for each, or (and this is what I did) you can just piggyback off of these std_change_ tables for Normal Change and just know if you're querying Changes WHERE std_change_producer_version.std_change_producer IS $template you can't assume that that Change is a Standard Change anymore and have to also query by type. You also need to replicate how the Standard Change Template Library UI works and point the Normal Change interceptor to a Normal Change Template Library rather than $change_request.do. Making this change is all or nothing even in a domain separated environment because even if you added domain to interceptors there still wouldn't be an overrides functionality (unless you really, really wanted to figure that out). Even if you had this all setup, you are now having to manage two sets of Change templates and your users are going to have to know ahead of time whether or not the change they're creating requires approval or not to determine Normal or Standard Change. Now you could go the route of just using sys_template as denoted in https://www.servicenowguru.com/system-definition/advanced-templates/ but those templates do not go through the same Change Manager approval process, which is something my institution needs.
Pros: Normal templates are completely separated from Standard Templates, does not interfere with Standard Change and its policies.
Cons: Two sets of templates to manage (Normal and Standard), a lot of dev work, more for users to need to know.
Standard Change Approvals
Again, the idea of using approvals on Standard Change fundamentally goes against what a Standard Change is according to ITIL, but there is way less work that needs to go into making this happen than using Normal Change Templates and there is less for your users to maintain and know. First, add two True/False fields to the Template Management form for Requires Technical Approval and Requires Risk Approval. Then, add the approval logic from the Normal Change workflow into the Standard Change workflow and account for those two fields in the approval logic. That's it.
Pros: Less dev work to implement, manage templates in one place, easy to set whether or not a Change needs approvals AND is on a per template bases rather than all or nothing, easier for users to think "Does this Change have a template? Yes, Standard Change. No, Normal/Emergency Change."
Cons: Disrupts the standard Standard Change workflow adding approvals going against ITIL.
Based on my tone, you probably already guessed I decided to implement Standard Change Approvals over Normal Change Templates. Would love to hear others thoughts on this in general or if you've ran into this issue as well and how you went about resolving it.
Cheers!
