Reclassify Tag based application service as Service instance

[vkachineni]

I have a Service that is wrongly classified as "Tag-Based Application Service" in the table "cmdb_ci_service_by_tags". I would like to move it back to Service Instance under "cmdb_ci_service_auto" table.

What is the best way to remove all the Service mapping related things so I can reclassify at a later time?

Are there any Scripting methods or reclassification methods. Please let me know.

Thank you,

Vinod

[vaishali231]

Hey @vkachineni 

You can approach this by first identifying why the service is being classified as Tag-Based, rather than directly deleting records from cmdb_ci_service_by_tags.

If the intention is to move the existing service back to a Service Instance/Application Service, I would recommend the following approach.

1. Identify the Tag-Based configuration

Check:

Service Mapping → Administration → Tag-based Service Families

Find the Service Family associated with the service and review the tag criteria that are creating/populating the service.

This is important because even if you manually change the class, the tag-based configuration may recreate or repopulate the service.

2. Remove the Tag-Based criteria first

If the service was incorrectly created because of a tag configuration, remove or correct that configuration first.

I would not manually delete all records from cmdb_rel_ci or svc_ci_assoc just to clean up the service. Those relationships may be required by other CMDB/service records.

Take a backup of the service and review its relationships before making any changes.

3. Reclassify the existing service

If you need to preserve the existing service record and its sys_id, you can test changing the class from:

cmdb_ci_service_by_tags

to:

cmdb_ci_service_auto

For example, in a sub-production instance:

var service = new GlideRecord('cmdb_ci_service_by_tags');
if (service.get('PUT_SYS_ID_HERE')) {
    gs.info('Before: ' + service.sys_class_name);
    service.sys_class_name = 'cmdb_ci_service_auto';
    service.update();
    gs.info('After: ' + service.sys_class_name);

}

After this, verify the record and its related CI/service relationships.

4. Validate before doing this in Production

I would test the following in a lower instance:

Service is available under the expected class

Existing CI relationships are still correct

Service offerings are not impacted

Incident/Change references are intact

The tag-based configuration does not recreate the service

The service can be configured using the required Application Service/Service Instance method

One important point

If by Service Instance you specifically mean a Service Mapping-discovered service, verify the target class first. cmdb_ci_service_discovered extends cmdb_ci_service_auto, so simply changing to cmdb_ci_service_auto may not be the correct target for a Service Mapping use case.

Note 

I would not try to clean this up by deleting everything related to the service.

The safer sequence is:

Identify Tag-Based Service Family → remove/correct tag criteria → review relationships → reclassify in sub-prod → validate → move the change to Production.

Also, direct modification of sys_class_name should be treated as a controlled recovery/reclassification approach, not something I would run blindly in Production.

************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb