Updated on July 21st, 2025
INTRODUCTION
Service Mapping is very important for a successful CMDB rollout. One of the greatest advantages of a well-populated CMDB with configuration items mapped to Application Services, or Service Instances as they are now called, is that you can confidently walk into your data center and point to any machine on any rack and get an answer to one of the following questions:
“Why does this device exist? How does it serve our business?”
“What would happen to the business if I turned it off?”
“How urgent would an Incident be it if this machine stopped working?”
ServiceNow customers have been creating Application Services/Service Instances in their CMDB almost since ServiceNow began. We’ve called them “Business Services”, “Application Services”, “Services” and now “Service Instances”. The goal is the same. A complex set of application components (web server, application server, database, etc.) are running in the Data Center and we need them mapped to an Application Service. And we need this mapping done automatically. Manual mapping is not reliable as things change.
There are several types of Service Instances. For review, I’ve listed them here before I describe the problem we are looking to solve in this article.
DIFFERENT SERVICE INSTANCE TYPES
Service Instance (cmdb_ci_service_auto): This is a basic record of a Service Instance that has no automation population method set to it. It needs no conversion and can be populated with any mechanism.
Mapped Application Service (cmdb_ci_service_discovered): These Application Services are populated via a top-down process that starts from an entry point (usually a URL). The process identifies the servers and running applications referred to from the entry point and brings them into the Service Map automatically. CIs can also be added manually to the map as an entry point.
Calculated Application Service (cmdb_ci_service_calculated): These are Application Services created via a process where CIs with infrastructure relationships from the CI Relationship (cmdb_rel_ci) table are converted into mapped application services.
Dynamic CI Group (cmdb_ci_query_based_service): This is an application Service where the CIs mapped to it come from some query of the existing CMDB data. The query can be using the CMDB Query Builder or a simple Query that is attached to a CMDB Group. It can also be a manual set of CIs selected to be part of the map.
Tag-Based Application Service (cmdb_ci_service_by_tags): This Application Service type is probably the most useful for mapping lots of application services. It involves mapping CIs that are referred to from the Key Value (cmdb_key_value) table of tags and their values. It is usually for public cloud-based applications since those are most likely to have tagged components. Although any tagged resources can be mapped this way.
The problem that exists today is that once you create a Service Instance/Application Service with a Service Classification (Calculated Application Service or Mapped Application Service), it keeps that Service Classification forever and the user cannot change it. Over time when the organization is ready to map configuration items to the service using some automated mechanism like Tag-Based Service Mapping or Top-Down Mapping they cannot. You can’t change the Service Classification. This is a problem since this Service has been used for years with different Use cases such as ITSM, Event Management, Portfolio Management and more. We need a way to reset the Application Service for future automated Service Mapping while it keeps its original System Id (SYS ID). Otherwise, there will be duplicates and that is a mess. Let’s save the SYS ID!
WHY IS IT IMPORTANT TO CONVERT MY APPLICATION SERVICE?
Consider the scenario that someone has created many application services manually of one type of service classification. But the company has now moved applications into Public Cloud and now the application services can be mapped automatically using all the tagged components. If you can’t convert your Application Service from the old type (calculated) to a Tag-Based Application Service, then you have to create a new Application Service. Then, you would have duplicate services that you have to remediate.
Each Application Service has a unique System Identifier (sys_id). This sys_id is used by other documents in ServiceNow to reference your application Service. For example, if there are probably Incident Records referencing your Service Instance via the Configuration Item field. If you create a duplicate, you need to remediate the duplicate from EVERY SERVICENOW DOCUMENT that may point to it. That’s a lot of work and you don’t want to do that. It is better to just convert the service.
WHAT’S THE DIFFERENCE BETWEEN AN APPLICATION SERVICE AND A SERVICE INSTANCE CLASS
You may have noticed that I’m using the terms “Service Instance” and “Application Service” interchangeably. Starting in 2025, ServiceNow, as part of the new CSDM specification version 5, renamed the term Application Service to Service Instance. It is just a display name change, and the underlying class names are still the same. You will see in the navigator for your ServiceNow instance Yokohama version and higher that it will have a link to “Service Instance” and no longer a link to “Application Service”. This is something we all need to adjust to. There is no reason why you can’t use the term “Application Service” and “Service Instance” interchangeably.
IMPORTANT NOTE: Once you convert your application service, you will lose any mappings that already exist between the configuration items and the application service.
For your convenience, I created a simple ServiceNow application that I attached to this Blog Entry to convert the application service. It gives a nice user interface. The code examples below are useful to convert many application services.
CONVERTING YOUR APPLICATION SERVICE TO A TAG-BASED APPLICATION SERVICE
Now let’s talk about the meat of this article. How can we convert our existing Application Service back to a generic Service Instance that can be populated with another mechanism. Here is how to do it.
- Get the System ID (sys_id) for the particular application service.
- Put the Sys ID into the following Code on the first line assigned to serviceId within the double quotes:
var serviceId = "1b1f4a459f42e6904aab3709bd49165d";
var tags = [{}];
// Clear all existing CIs from the service
new SNC.BusinessServiceManager().clear(serviceId, true);
// Change the class name to cmdb_ci_service_by_tags
var serviceGr = new GlideRecord('cmdb_ci_service');
serviceGr.get(serviceId);
serviceGr.setValue('sys_class_name', 'cmdb_ci_service_by_tags');
serviceGr.update();
// Update the fields for tag-based service
var metadata = {"category_values": tags,"checksum":"WAITING_FOR_UPDATING"};
var metadata = '';
serviceGr = new GlideRecord('cmdb_ci_service_by_tags');
serviceGr.get(serviceId);
serviceGr.setValue("populator_status", 1);
serviceGr.setValue("service_populator", "cae02879c3b23300daa79624a1d3ae2f"); //tag-based service populator
serviceGr.setValue("metadata", JSON.stringify(metadata));
serviceGr.setValue("type", 4); //tag-based
serviceGr.update();
// Populate the service
serviceGr = new GlideRecord('cmdb_ci_service_by_tags');
serviceGr.get(serviceId);
var servicePopulatorRunner = new SNC.ServicePopulatorRunner('INTERACTIVE');
servicePopulatorRunner.run(serviceGr);
NOTE THAT THIS WILL CREATE A TAG BASED SERVICE MAP WITH NO TAG DATA. YOU CAN HAVE THE SCRIPT MAP THE DATA BASED ON TAGS. YOU DO THIS BY REPLACING LINE 2 FROM THE EMPTY JSON:
var tags = [{}];
to
var tags = [{"application service":"App","value":"adobe experience manager"}, {"application service":"Environment","value":"prod"}];
This would map the CIs that are tagged with the
Tag-based service family: "application service" with the tag categories "App" and "Environment"
and the values: "adobe experience manager" and "prod" respectively
3. Execute the code in a background script and the service is now converted.
4. When you open your application service, you will find that the Service Population Method is now a Simple Tag List and you can immediately start populating this application service with configuration items from tagged data.
CONVERTING YOUR CALCULATED APPLICATION SERVICE TO A MAPPED APPLICATION SERVICE
You may want to map the application using Top-down (ML-Based) mapping from an entry point. The steps are the same but the code is slightly different.
- Get the System ID (sys_id) for the particular application service.
- Put the Sys ID into the following Code on the first line assigned to serviceId within the double quotes:
var serviceId = "b20dc27a47722a90de3e9b22736d43a1";
var serviceGr = new GlideRecord('cmdb_ci_service');
serviceGr.get(serviceId);
serviceGr.setValue('sys_class_name', 'cmdb_ci_service_discovered');
serviceGr.update();
3. Execute the code in a background script and the service is now converted.
4. When you open your application service, you will find that the Service Population Method is now a manual Application Service. You can click Add Method and start Top-Down Discovery.
3 Comments
