ServiceNow's CSDM 5 and the Future of Scalable Service Modeling

Introduction

The CSDM 5 white paper was released during Knowledge 2025, and we are all busy getting to grips with the changes and understanding their potential implications. Changes to the model can have a range of implications on how we manage and maintain data within our current implementations and our current and future alignments to the model. What started as an attempt to distil many of the changes into one article quickly changed into the idea of a series of shorter articles (mainly due to the scale of changes), that help highlight some of the key changes that are going to be most impactful and visible to customers. This article represents the first of such articles, where we look at the renaming of Application Services to Service Instances. We will look at the updated model and any potential implications that you should look out for in your own or your customer's instances.

What are Service Instances?

One of the of the biggest changes that many will notice is the renaming of Application Services, to Service Instances. On the surface, this may look like a trivial renaming. However, this is more of a re-alignment of the concept of instantiated services to better support the platform and cater to additional use cases and contexts. Historically, the focus has been solely on IT when representing instantiated services with the CSDM, with little room out of the box to represent service instantiations from other use cases and industries (such as utility, manufacturing, retail, and transportation). As this was the only service instance concept provided by the ServiceNow data model customers wanting to map services outside of IT would have had to create their own tables and model to represent additional instantiated service concepts outside of IT. The re-alignment we see in CSDM 5 appears to be an attempt to begin to rectify exactly that. This change is also in service (pardon the pun) of the broader themes within the CSDM 5 which represent a focus on scalability, being future-looking, and being more explicit and less abstract.

As of CSDM 5 the notion of only being able to represent service instantiations in a single way (OOTB) changes, and several new Service Instance classifications have been introduced. But before we get to those, we need to understand that the base Service Instance table represents the previously named Application Services table, and our actual Application Services should instead be represented in the appropriate classification tables depending on the method of creation. We can understand how the Application Services will be classified within the model in the following table.

We can use that table to ensure that we are classifying our Service Instances, that are Application Services, appropriately. The good news is that the classification will be done automatically for you when creating a net new Application Service using the stated methods. However, if you are an older customer, have made changes, or are not classifying the Application Services appropriately today, then now is a good time to think about cleaning up and/or reclassifying that data before products become more reliant on this new model.

With the Service Instance table now acting as the base table for service instantiations, the following new child tables have been introduced in CSDM 5:

·       Data and AI Service Instance

·       Operational Process Service Instance

·       Facility Service Instance

·       Connection Service Instance

·       Network Service Instance

For more specific definitions for each of the new Service Instances, you can refer to the CSDM 5 white paper. Pulling all these concepts together, the CSDM white paper helps us visualize the changes clearly.

Wrapping Up

So where does this leave us, and what things do we have to be cognizant of going forward? At this stage, the new concepts are what we need to be mostly aware of right now, keeping them in our minds when mapping out Service Instances. On the data maintenance side, our immediate concern should be ensuring that we are classifying our Application Services appropriately within the context of the new model. In terms of impact on your existing deployment and classification of Application Services, you may want to move anything generic that you previously captured in cmdb_ci_service_auto or other tables into the correct Application Service classification table within the CMDB, a practice that applies regardless of the new additions. In general, the use case for representing a Service Instance in the cmdb_ci_service_auto table instead of a more specific child table should be limited at this time, and the new model should help promote the creation of CIs in the appropriate child Service Instance classes in the CMDB when required.

Before jumping into creating any data in the new Service Instance classes, however, there are some important things to be aware of, as called out in the ServiceNow Community article linked below. Historically, before this expansion, and since we created records in the Mapped Application Service table and its children, the system would automatically create svc_ci_assoc records when mapping out the service. This is still the case. However, now that we have expanded the use cases beyond IT, this isn’t the case for all the other base Service Instance tables within the model. As of right now, this does not occur within the base Service Instance table, or the newly introduced tables. If you rely on records in this table being populated, then you should likely hold off migrating data to the Service Instance table and the new additions called out in this article until there is more clarity on when this will be resolved. There seem to be plans in the future to remedy this, but there are no timelines yet as to when.  Please read the linked article for further details on this topic.

For more information on the potential impacts of migrating to using the new Service Instance tables, read the following article.

For more detailed information on what is discussed in this article please check out the recently published CSDM 5 white paper that was used as the basis for this article.