Application Service is being renamed to Service Instance. At the same time, new classes - Data Service Instance, Network Service Instance, Connection Service Instance, Operational Process Service Instance, and Facility Service Instance - have been introduced in the CMDB CI Class Models 1.64.0 (November 2024) store application release.

• What has happened to Application Services?
• Can I use the new Service Instance classes?
• Are there any limitations?
• What does the future hold?
• How can I be future-ready?

These five questions are the core of this article and highlight exactly what you can expect to learn. By exploring them, you will understand how and why Application Services are now called Service Instances, when and how to use the newly introduced classes, potential limitations to keep in mind, and practical steps to prepare for the future.

Why has the Application Service become a Service Instance?

Originally, the Application Service class represented a deployed application stack. But what if you need to represent network components? Are deployed network components also considered Application Services? And what about something like a cleaning service for a specific office?

The term “Application Service” focused on application deployments. Its name limited its broader use outside IT and application-stack scenarios.

By renaming it to Service Instance, we open up the possibility of modeling any kind of service - Application, Network, Connection, Data, AI, Facility, and many others - along with all the components it depends on.

The following diagram illustrates the Service Instance class and its key subclasses as defined in CMDB CI Class Model 1.69.0 (February 2025). Some elements are labeled “Coming soon” or “Coming later,” indicating planned features that may change in the future. They are included so you can understand the overall direction and future use of Service Instances.

Can I use the new Service Instance classes?

Yes, you can. However, there is currently one limitation: no Service Configuration Item Associations (records in the svc_ci_assoc table) are created for these new classes at this time. That means you can use the new Service Instance classes only if you do not need Service Configuration Item Associations.

Currently, the svc_ci_assoc table is only populated for these classes:

• Mapped Application Service
• Calculated Application Service
• Tag-Based Application Service
• OT System Service
• Dynamic CI Group

Why are Service Configuration Item Associations important?

The svc_ci_assoc table is used by several key processes:

• Event Management

Quickly identifies impacted Application Services based on the affected Configuration Item.

• Incident Management

Identifies impacted services and CIs by using records in the svc_ci_assoc table when the system property com.snc.incident.refresh_impacted.include_affected_cis is set to true.

• Change Management

Identifies impacted services and CIs by using records in the svc_ci_assoc table when the system property com.snc.change_request.refresh_impacted.include_affected_cis is set to true.

Because these processes rely on Service Configuration Item Associations, it’s important to know whether your Service Instance records require them. Therefore, if you do need these associations, you must use the Mapped Application Service or any class that extends it.

Will the new Service Instance classes support Service Configuration Item Associations?

Yes, they will. This feature is planned for future releases, as it involves significant complexity. Currently, population of the svc_ci_assoc table is tied to specific classes - for example, Mapped Application Service (using Service Mapping or manually based on CI relationships) and Calculated Application Service (automatically based on CI relationships).

In the future, the svc_ci_assoc population process will be decoupled from specific classes. Instead, any record in the Service Instance class or its subclasses will be able to have its own population method. These methods will be configured in a new Service Map Population Configuration table (working name). By separating population logic from the class, you can define various population methods - such as Service Mapping, relationship-based, tag-based, or filter-based - for each record, without needing to store them in today’s population-based classes.

What should I do now?

If you need Service Configuration Item Associations, do not migrate to the new classes yet. Wait until the Service Map Population Configuration and the necessary svc_ci_assoc population method become available. At that point, you can begin migrating your records to the relevant Service Instance classes.

To prepare for this future migration, review and adjust any custom references in your forms, scripts, workflows, related lists, etc. If these references currently point to Mapped Application Service or any of its subclasses, update them to reference Service Instance (cmdb_ci_service_auto) instead. If needed, you can use allowlisting or denylisting to control which classes are included.

Making these changes now ensures that, when the population method is ready, you will be able to migrate your service records to the new Service Instance classes without delay.

Summary

In this article, we explored how Application Service is being renamed to Service Instance to better accommodate a wider range of services, including network, data, facility, and more. We also discussed newly introduced Service Instance subclasses, limitations around Service Configuration Item Associations, and the future plans to decouple svc_ci_assoc population from specific classes.

For organizations that rely on Service Configuration Item Associations, we recommend waiting to migrate until these features and population methods are fully supported. In the meantime, you can prepare for future migration by updating custom references to Service Instance classes.

Stay tuned for further updates and deeper insights with the upcoming CSDM 5.0, where even more details about Service Instances and their role in the CMDB will be provided.