---

Customisation Case Study Series

Welcome to my blog series focused on customizing ServiceNow! Drawing from real-world case studies based on my daily experiences, I’ll delve deep into the intricacies of ServiceNow customization. We’ll journey through the thought processes, decisions, and steps in actual customization projects. Along the way, we’ll weigh the pros and cons of various customization alternatives. Each post promises to offer insights into best practices and potential pitfalls. Whether you’re a seasoned ServiceNow pro or just starting out, this series aims to enhance your understanding and approach to customization. Join me as we explore the dynamic world of ServiceNow through a hands-on lens.

For this article, we will use the following definition of customisation – the modification of any configuration record (anything captured by an Update Set) created by the vendor (from the store, plugin, or family release) that may be updated in future.

In this case study, we will look at the ServiceNow store application Certificate and Inventory Management and how to extend its functionality to solve a specific problem around incident prioritisation of expired certificates.

Certificate Inventory and Management

This isn’t a blog about Certificate Inventory and Management (CIM). However, we need to set some context to get to the problem.

What is Certificate Inventory and Management

ServiceNow’s CIM application offers a streamlined solution for managing your TLS certificates. Paired with Discovery, this tool automatically discovers and inventories all your certificates, ensuring you never lose track. It proactively alerts you to upcoming expirations, facilitating timely renewals and reducing the risk of unforeseen outages. Expired certificates trigger incident creation, ensuring prompt attention. The application’s various discovery methods highlight Its versatility, ensuring no certificate goes unnoticed. With its commitment to regular updates and seamless integration, you’re equipped with a robust solution to safeguard your IT operations.

Generating Incidents

Incidents get created for expired certificates based on the renewal policy set on the impacted certificate.

However, Incident priority gets set based on Impact and Urgency. To set the priority based on what is specified on the Certificate, some assumptions must be made on what Impact and Urgency sets the given Priority.

Priority Problem

		Urgency
		1	2	3
Impact	1	1	2	3
	2	2	3	4
	3	3	4	5

In the OOB priority matrix, there is only one way to set a priority 1. For priority 3, there are three different combinations that can set this value. In CIM, the assumption is that you are using the OOB priority matrix, and that an impact and urgency of 2 is a priority 3. In my ten+ years of ServiceNow consulting, I have never seen a customer adopt the OOB priority matrix verbatim. Consider a different priority matrix, with four levels of impact/urgency:

		Urgency
		1	2	3	4
Impact	1	1	1	2	3
	2	1	2	3	4
	3	2	3	4	5
	4	3	4	5	5

In this matrix, the impact and urgency of 2 results in a priority 2.

Now Imagine if the wrong priority makes every generated incident that was supposed to be a P3 incident into a major incident (P2), and there are hundreds of expired certificates. It is very typical for major incidents to trigger SMS to on-call teams, emails to managers, and SLAs with financial implications.

We are going to need to fix this…

Customisation Calamity

Let’s take a look at how priority is set in CIM.

The Incident Priority, set in Subflow ‘Certificate Notification’, is responsible for creating renewal tasks and incidents for at-risk and expired certificates.

The Script Include Certificate Notifier that calls the above Subflow is read-only, and the flow name is hard coded in that script.

var flowOutput = sn_fd.FlowAPI.executeSubflow('sn_disco_certmgmt.certificate_notification', inputs);

A Scheduled job runs the notify() method, which calls the triggerSubFlowSynchronously() function.

Looks like we might have customise the subflow!

Customising Store Applications

The CIM solution is a ServiceNow Store application.

When updating a store application, ServiceNow employs a strategy that aims to preserve customizations while integrating new features or improvements. Customized objects within are preserved during an update to ensure user changes aren’t overwritten. ServiceNow uses the “Skip” pattern for updates, meaning that if an object has been customised, the update will skip over it, leaving the customization intact. Any new features or changes in the update are added around these customisations. However, this can sometimes result in missing out on certain updated functionalities.

After the app is upgraded, ServiceNow administrators can review skipped upgrades and merge in changes as required. While this is the process for family upgrades, it is often forgotten when upgrading Store apps with a monthly upgrade cycle. For this reason, extra caution is advised when customising a Store application, especially if a robust process for updating Store application is not in place.

Customising Flows

When customizing Subflows in ServiceNow, it’s essential to be aware of potential challenges with future system updates. Once a Subflow is altered, any forthcoming upgrades targeting that flow will be skipped, ensuring your modifications remain intact but potentially causing you to miss out on new features or optimizations. Moreover, merging customized objects can be complex due to intricate dependencies and varied configurations, often leading to unforeseen complications. Merging Subflows isn’t feasible and poses excessive challenges.

Extending the application

There are many ways to extend an application. In the more binary sense, there are only two options – customise; or not.

Extension by design

The designers of the CIM application have considered extensibility within their design. The last Action of the Subflow calls another Subflow called Certificate Notification Customisation, where extra functionality can be added. OOB, the Subflow does nothing except write the system log.

For this example, we will not consider updating this Sublfow as a customisation since it was intended for that purpose and will never be updated by ServiceNow (in theory).

Weighing up the options

Updating the Certificate Notification Customisation may seem the best alternative to customising the ‘Create Notification Customisation’ Flow.

But is it?

I was faced with this decision. Rather than taking the designer’s intended path, I weighed all my options, including customisation, and assessed the pros and cons of each option. I have listed my final considerations below, in no particular order:

Option	Pros	Cons
Update the Customisation Subflow to set the correct priority	Upgradability: Future changes to Subflow will be passed on. Support: The solution uses no-code configuration and is easier to support	Poor performance: The incident is updated twice. Wrong Process: The incident may already be set to incorrect priority, setting off the major incident workflow. Higher Coupling: Logic to update priority is in two places, making the solution more complex
Create a before Business rule on update to change the priority of the incident to the correct impact and urgency	Correct Process: Priority is correctly set the first time, preventing the major incident process from starting	Higher coupling: The solution now uses a combination of flow and business rules, making it harder to maintain.
Copy the Subflow and modify the logic to raise the correct priority. Create a new Script include to override the OOB method and copy code using your new Flow instead.	Correct Process: Priority is correctly set the first time, preventing the major incident process from starting Support: The solution uses no-code configuration and is easier to support	Poor Upgradability: Future upgrades to Flow or Script include will not be incorporated into the application. Solution has now deviated from OOB.
Customise the original Sublow and change the impact and urgency.	Lower coupling: Incident generation logic is in one place Support: The solution uses no-code configuration and is easier to support Correct Process: Priority is correctly set the first time, preventing the major incident process from starting	Poor Supportability: Future upgrades to Flow or Script include will not be incorporated into the application.

What would you do?

Which option would you pick? Is there an option I didn’t consider? Or is there a case for business smart customisation?

I’m not going to tell you which option I picked. Not yet, at least. That isn’t the point of this post. The point is to enhance your understanding and approach to customization by exploring a case study. And maybe you learned a little about the CIM application as a bonus.

Post your preferred option on my LinkedIn poll, and post any other alternative options you can choose!