Application Service and Service Instance: What is new in Yokohama and CSDM v.5

[David Skowronek]

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.

[Kevin Clark1]

I'm curious about the terms "allowlisting" and "denylisting".  I'm, not familiar with that in terms of reference fields on tables.  Can you point to anything which provides more context for that please?

[David Skowronek]

Hi, @Kevin Clark1 . Allowlisting means that you create e.g. property with classes you want to include. Denylisting is the opposite approach, where you exclude some classes in the e.g. reference qualifier.

[Bozidar Protuli]

Hi all, as much as I like new announcements. especially in CSDM/CMDB areas, this information has low actionable value - and I don't mean it in bad context, yes the value for future planning is there and it is very helpful - until  Service Configuration Item Associations hits the store we cannot lunch the rocket - but we can make architectural designs ready for future - thank you 🙂

[mcastoe]

Thanks David, for this great introduction.  In addition to the Incident, Event and Change usage of Service Configuration Item Associations [svc_ci_assoc], Enterprise Architecture's Technology Portfolio Management (TPM) requires entries in the table to identify the infrastructure CIs for software and hardware usage analysis.

[Johannes]

Great article @David Skowronek , and really looking forward to the Service Map Population Configuration table, which (if I understood what you wrote here correctly and what Mark Bodman told me) will enable a Service Instance record to be populated by multiple population methods simultaneously, allowing for greater flexibility.

Will this then allow for multiple different tag combinations, e.g. populate a Tag-based AS with both CIs tagged with "app"="x1" AND "env"="Prod" and then also "app"="x2" AND "env"="Prod"?

[David Skowronek]

Hi, @Johannes . I am glad that you like my article. Your comment is correct, the plan is to enable multiple population definition for a single Service Instance record, working as a "population strategy". But as the details are not finalized yet, I cannot comment it further.

[Marshall Parker]

Great primer David, a useful introduction to the new service instance types and some steps towards seeing CSDM 5.0 beginning to make it out into the platform.

For the new service instance types, i.e. Facility Service Instance or Network Service Instance, it sounds like we may be ready to start exploring these if our current utilization focuses on CI Relationships [cmdb_rel_ci] and not the CI Assocation [svc_ci_assoc] records, is that a correct understanding?

[CasperJT]

I am looking forward to seeing some more detail on these new classes. I suspect that the connection service may solve a topic that has been brought up in the forum quite a few times:

How do we document integrations in the best way in the CMDB?

A Connection Service Instance represents a network connection between two endpoints, crucial for end-to-end Service Delivery. It differs from Network Service Instances by representing the provisioned interconnection.

Are you able to share any more about the connection service instance or is it still too early?

//Casper

[David Skowronek]

Hi, @Marshall Parker . You are correct. If you do not need svc_ci_assoc records - and please note that ootb features described in my article depends on them - you may use the new classes without any limitations.

[David Skowronek]

Hi @CasperJT . I cannot provide more information about those 2 classes now, more details will be published as a part of the CSDM v.5 Draft that is suppose to happen at K25. You may also explore Digital Integration Management, described at https://www.servicenow.com/community/apm-articles/managing-digital-interfaces-and-integrations-in-ap....

[Damian3]

I was overjoyed to read this :

"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."

Trying to explain why the class we use depends on how we map objects to casual users of the CMDB has long been a painful exercise, I hope this makes it through to fruition in the next couple of releases.

[mev]

Classic SN.. Always release new stuff to replace existing product design, but it's not fully baked and is released before it can even be leveraged (no relationships/association??? isn't that the entire point of CSDM and CMDB?).. Thanks for the heads up i guess, but this shouldn't have been released until it's actually ready to be leveraged.

[David Skowronek]

Hello, @mev . Thank you for your response. I appreciate your perspective; however, it is important to note that some of our customers may already utilize the new classes. This could be due to their non-reliance on records in the svc_ci_assoc table or because they have implemented custom population methods. Additionally, introducing these new classes now provides an opportunity for careful future migration planning, detailed analysis, and the implementation of necessary changes, rather than a rushed "big-bang" approach that could be more stressful.

[apy]

Hi @David Skowronek. Once again thank you so much for a create article regarding Application Services.

Would you have or could you provide some practical, concrete examples of instances for the newly introduced instance tables? This would be really helpful. Meaning these:

• Data Service Instance (cmdb_ci_data_service_instance)
• Network Service Instance (cmdb_ci_network_service_instance)
• Connection Service Instance (cmdb_ci_connection_service_instance)
• Operational Process Instance (cmdb_ci_operational_process_service_instance)
• Facility Service Instance (cmdb_ci_facility_service_instance)

In addition, I've been wondering why the cmdb_ci_service_auto was relabeled as "Service Instance" and not "Application Instance", as "Application Service" has been defined as follows: "An application service is a logical representation of a deployed application stack. It is also often referred to as instances of a business application which are supported by an IT infrastructure."

[Vincent Messier]

We are still having a lot of challenges with services mapping in our business. Therefore I went through a lot of troubles building a list of applications services in cmdb_ci_service_auto and creating manually records in svc_ci_assoc  using the relationships UI and a custom flow.

What will happen to those if I upgrade since you are now saying this won't be supported anymore. They will just vanish from svc_ci_assoc ?

[Christopher Ca4]

Hi, David, any chance we can have a conversation about this with you or Scott (Lemm)?  Based on everything that I've read about the structure of the service records, Cleaning Services should be a Service Offering, closer to the top of the hierarchy (Business Service->Service Offering->CIs).  And there would never be a discoverable instance of it.  Non-discoverable things should not live in the same table as discoverable things. We have spent almost two years coding business rule and script include solutions to overcome the inequities of the SGO-Dynatrace ingestion tool, the poor quality of data coming in from Dynatrace, and to automatically connect those discovered records to corresponding Business Application records, where we track ownership and business criticality, among other things.  I talked with Scott about this structure, and he said that it made sense.  I think that the changes will not have a huge impact on our code, but I'm not sure.  We are planning on hiding most CIs from the CI column in Incidents and Change Requests, to only show Business Applications.  Now that all the software CIs from Dynatrace are connected to records with ownership, hiding the discovered CIs will make it easy for anyone to find exactly the thing that is broken or being updated.  We still could use a lot of help with the SGO-Dynatrace service graph connector.  Its weakness is that it only ingests mutable data in the form of Dynatrace tags, instead of immutable properties and attributes, and this makes the software data difficult to process, connect, or even to trust.

[Christopher Ca4]

Ah, your diagram makes it a little more clear. This change might  not break our 9,000 LOC business rule, but it seems to be duplicating what the Service Offering table does, just at a lower level.  It would still be helpful to get a better understanding of the impact.

[Christopher Ca4]

If Service Instance is going to have some sub classes that are non-discoverable, you might also consider one for "product features" or "application features."  Think menu items or workflows from the end user perspective, especially in larger monolithic or platform based applications.  Currently, we are putting those in the Business Apps table, but it's not elegant, right?  I had to add a custom column to track product types such as "program", "library", "feature", and now I'm thinking about adding another entry for non-discoverable code and call it "script" or "add-on", for source code that runs in other platforms like SSIS, ServiceNow, RPA, Automate Schedule, or Talend.  To me this feels like we are really overloading the Business Applications table, or incorrectly using it to track software ownership for our homegrown and COTS apps.

[Johannes]

Hi @Christopher Ca4 

You wrote

«Business Service->Service Offering->CIs»

Are you saying you are relating infrastructure CIs directly to your SOs, without an AS beteeen? And did Scott approve on this? That seems very strange, or did I maybe misunderstood?

Regarding the SGC for Dynatrace, I totally agree, it really messes up the CMDB when having other sources and trying to enforce CSDM, so I have given up on implementing it in our organization. 

[Christopher Ca4]

Hi, @Johannes , I mean Calculated Application Services, which live in the CI table.  I find that there is a lot of ambiguity between different "application services" classes, and the Dynatrace service graph connector populates Calculated App Svcs, so we connect that table directly to the SOs.  The Biz App record relates to them both so that you can click through to the owner from either record.  But the SO is like a parent to the Calc App Svcs.

[Christopher Ca4]

I probably should have shown Biz Svc->Svc Offering->Calc App Svc, but I presume that there are other CIs that might connect to Service Offerings.  For example, if we have a Svc Offering called "Access to Network", would it not connect to network switches or Cisco routers?  You would not want an application service for devices.  But the CSDM 5 change to Service Instance might help clear that up.

[Johannes]

Ok, yes, having the Calculated Application Services between the infrastructure CIs and the SOs alligns with CSDM. 

And you probably know it already, but SOs, BAs etc are actually also CIs (all extended from cmdb_ci), but I guess you define CIs based on what you can select as Configuration Item in the IPC forms etc.

[Miklos Palfi]

It would be fantastic, if service instances could be populated very easily from cloud service accounts (Azure subscriptions/resource groups and AWS accounts) For example by just creating a relation from the service instance to the cloud service account / resource group CI.

Neither manual mapping, tag based or DCIGs are perfect, there is too much "plumbing" needed currently.

[Miklos Palfi]

Is it somehow possible to take part in the development of the new service instance population function as a beta-tester? We are very much looking for this function, because it would simplify our assignment efforts if it implemented well.

[David Skowronek]

Hello, @Miklos Palfi . Thanks for your offer and interest. Unfortunately, we do not have a public beta-testing program. The best opportunity would be to opt-in for the Early Adopter program, where you can test the RPT version of the family release. If your company is not a member of this program yet, you may talk to your ServiceNow account executive.

[rodrip]

Hello, What was the decision behind not doing the Application Service Instance as part of the roll out?  Considering the Service Classification "Application Service" is the most impacted CI, would it not have made sense to do the Class change on all Services with the Service Classification of "Application Service" to Application Service Instance?

[Arno Reintjens]

Hi @David Skowronek, 

Thanks for all your articles, they are very useful to use when implementing AS/SI. 

Regarding the association table, as we are allowed to create parent and child application Services, I expect that the association table reflects all CIs that are in the Parent and Childs. Even if you combine Calculated with Dynamic CI group Application Services, but it won't. 

Is this depending on the new Service Mapping population Configuration method that is not yet deployed?

Which kind of AP/SI combination makes it possible to have a complete picture of all CIs of the Childs?

The background is that I am trying to have a complete picture of a hardware platform, on the one hand have all platform managed software as Calculated Application Services and Dynamic CI Groups for the infrastructure of the platform. 

Hope you can advise,

Cheers,

Arno

[David Skowronek]

Hello, @Arno Reintjens . Thanks for your feedback; I am happy that you find my article useful. Regarding your question, the CI Association table only contains the nearest parent Application and does not include direct information about nested Application Services. This is by design, as the table would become extremely large.

If you need to get information about nested Application Services, you may need to make recursive calls to this table. The first call finds the nearest Application Services, and you then use that list as input for another call to find their parent Application Services.

All the necessary data is in place; you simply cannot retrieve it in a single call.

[Mathew Hillyard]

Hi @David Skowronek 

What is the difference between the (coming soon) Application Service Instance and the existing (and unchanged) Application Service classes?

BR
Mat

[David Skowronek]

Hello, @Mathew Hillyard . As I explained in the article, the current classes are designed from the data population perspective. The new classes are designed as the rest of the CMDB, what type of records they host. You may have AI service stored in the AI Service Instance, data service in Data Service Instance classes etc., instead of having them all in the Calculated Application Service.