ServiceNow published the Common Service Data Model over seven years ago. Ever since, the ServiceNow community has been craving for CSDM examples and more details on how to implement the model in the real world.
In February 2019, I authored a blog post that analyzed the model from the Service Portfolio’s perspective and sought to interpret the whitepaper in a practical manner. Over the years, I have been updating this article with various versions of the CSDM. Once again, in the Spring of 2025, it is time to review and update the evolution of the CSDM.
You can read the original post here and see how things have changed, or have they?
The Evolution of CSDM
ServiceNow has updated its Common Service Data Model (CSDM) whitepaper a few times since the original publication in 2018:
- Version 1.0 introduced the model and split it into three different domains: Business, Service, and Application together with high-level data model diagrams and relationships.
- Version 2.0, released in 2019, updated the domains to Design, Manage Technical Services, and Sell / Consume. It also introduced the implementation phases Crawl, Walk, Run and Fly and emphasized the value of implementing each phase.
- Version 2.1 wasn’t really a new version of the whitepaper. It was rather a set of “Product views” or “Use cases” on how CSDM relates to other ServiceNow Products such as ITSM or Incident Management.
- Version 3.0 is was released in September 2020. This release introduced Foundation Data as a new domain and set some Key Principles. Product-wise, CSDM started to show as CSDM related features on the platform (e.g. dashboards, navigation, form views, etc).
- Version 4.0 draft, which wasn’t followed by any “final version” 4.0, was published in January 2022. This release introduced a new Build domain, relationship to Service Portfolio also from the Technical Services and some new elements and ideas related to Foundation data and Life Cycles.
- Version 5 was long overdue and was finally released in Knowledge 25. Mark’s presentation gained one of the biggest audiences in the Expo Area. The main evolution in version 5 is the expansion beyond ITSM and Applications.
We recently wrote about CSDM 4 vs 5: What’s New, What Endures, and Recommendations.
Over the years, we’ve also had a few webinars discussing the CSDM. I think we were fortunate to host one of the first webinars introducing the CSDM 3, featuring Mark Bodman. This webinar series attracted a large live audience and continued to gain popularity as a recording over the next two years. Our latest webinar with Mark Bodman focused more on data governance than the CSDM, and you can view the recording here.
All our previous webinars are available as recordings on our Webinars page. Please take a look.
Evolution of the Conceptual model from CSDM 1.0 to 4.0
Consistent Key Messages Across the Whitepaper Versions
Since 2018, updates to the whitepaper have continued to provide more details and CSDM examples while the overall idea and message have remained the same. Since 2018, updates to the whitepaper have continued to provide more details and CSDM examples while the overall idea and message have remained the same. Here are some of the key messages from different versions of the whitepaper:
- Service-related definitions span the ServiceNow product portfolio and the Now Platform. (CSDM 1-5)
- Customers should follow the model to utilize the platform to its full potential, realizing a full value chain alignment, improved quality, transparency, better insights, automation, and lower costs. (CSDM 1-5)
- ServiceNow products are standardizing their use of data from the CMDB. That standard is the CSDM. (CSDM 2-5)
- Without this data in prescribed tables, you may not receive the full value of the ServiceNow platform. (CSDM 2-5)
- CSDM should be used as a reference for mapping your IT services in ServiceNow (CSDM 1-4). And any services in version 5.
In the original post I talked about the lack of an actual data model. The whitepaper provided only a high-level conceptual model and a list of actual tables compared to the conceptual model, as well as a list of relationships to be used between the classes. Now, version 5 includes a promise of very detailed entity-relationship diagrams, which, unfortunately, are not available. At least, not yet.
We will talk more about the data models later, but here is a quick blast from the past, the CSDM Conceptual Model v1.0:
Conceptual data model from the CSDM 1.0 whitepaper 2018
Evolution Towards Tables
Later CSDM versions include more details in their still conceptual data model diagrams and, most importantly, differentiate between Technical and Business services. This evolves towards a model where these records would be managed in different tables instead of just using a Service Classification within a common Service CI Class.
Since CSDM 2.0, technical and business services belong to their own domains, and different stakeholders are identified for each. Version 4.0 introduced a new Build domain, but relationships to Services via Application Services still remained the same.
The picture below illustrates the services part of the 2.0 and 3.0 versions, which are identical in this regard. The same applies to 4.0, since the Build domain is optional between the Business Application and Application Service classes.
Simplified CSDM 3.0 for Services. Still valid according to versions 4 and 5, too, despite slight changes in the CI Class names.
Now, with the CSDM 5, the same trend continues for Application Services and Product Models. Application Services now have a newly renamed parent class, the “Service Instance”. Together with this relabeling, ServiceNow also introduced several new Service Instance types, including Data-, Operational Process-, Facility-, and Network Service Instances, among others. The Product Models now include separate tables for System Component Model, Service Model, and Service Offering Model, for example.
Ten base Product Models class model.
Application Focus – is still there, but not as dominant
CSDM has had a very heavy focus on Applications. This has been criticized quite a lot, also by me. Different customers are eager to see more common CSDM examples and use cases that do not necessarily involve Business Applications as prescribed.
4.0 version emphasizes applications even more with the Build domain that is only related to application-related services.
With version 5, this all has changed. The Application Service has evolved into a Service Instance, enabling ServiceNow customers to manage and model any services within the platform using the same conceptual model.
Previously, I felt that “Application Service” could be replaced with a “Configuration Item” where, depending on the service, any CI could be directly related to Service Offerings, also on the Sell / Consume domain. Now, we are seeing more “Service Instance types” that can represent various types of Configuration Items, and possibly other entities as well. So, this is no longer a problem.
More generic “Service Instance” can consist of any kind of Configuration Items
Previously, I used End User Services as an example: a single Workstation CI should be directly linked to the Business Service Offering that describes exactly how that Workstation is delivered to a consumer, and what Catalog Items, Service Levels and other commitments are related to the service.
Well, instead of directly connecting a single Workstation to a Business Service Offering, we can use a Dynamic CI Group that represents all Workstations with similar service qualities and relate that to an offering. One could already do that within previous CSDM versions, but even in version 5, the prescribed relationships from Dynamic CI Group only points to Technology Management Service Offerings, not their business-side siblings. Dynamic CI Group is an extension to a Service Instance, after all, so I might just use it with Business Service Offerings too.
Some of the relationships between CI classes according CSDM 5
Different types of Service Relationships
This also brings up the question of the relationship type used between the Business Service Offering and the Application Service: Depends on. This is a logical relationship type when a business service depends on an application (or any other CI) in its delivery. However, what about the CIs that are “Provided by” the service? Like the end-user devices in the earlier example.
Business Applications, such as Microsoft SCCM or Intune can relate to Workstations from the technical point-of-view. Different CIs managed under same Technical Service Offerings can still be packaged to end-users with different terms and commitments. In this sense, a “Standard Workstation” Business Service Offering can Depend on SCCM for example, but it also Provides or Delivers, or Supports the actual Workstation CIs.
This is something worth considering when implementing a service portfolio. An early draft of the CSDM 5 also included Install Base Items that would take of this part, but it didn’t end up into the final version. If you decide to use different relationship types for different use cases, then just stick with it. Only change if some out-of-the-box feature requires you to do so and you’re truly using that feature. In any case, it is easy to make changes to a data model once you have one and have been following it.
From Conceptual to Logical Data Models
The conceptual data model is a “ten-mile-high” view. This is great for conversations and communicating the overall model. I’ve heard that after CSDM 5, the conceptual model is no longer updated/available (not sure about this at all). Anyhow, we need more logical models in understanding the necessary details to actually follow the model. CSDM 5 is flashing an ERD-like data model diagram, but it’s blurry on purpose.
More detailed ER-diagram exists, but it's not public
The figures below show the actual tables and relationships in ServiceNow against the conceptual model described in the CSDM version 5. This is very useful information, but a diagram would be better.
Conceptual Model to Physical Model according to CSDM 5
Another figure from the white paper describes the relationships between different classes as shown below:
Prescribed CI Relationships according to CSDM 5
Few comments about these tables and relationships
To my knowledge, the Yokohama release should include all the tables and relationships described in the CSDM 5, but I found some inconsistencies. For example:
- Service Portfolio is described as service_portfolio table, but I could only find spm_service_portfolio table.
- Entity relation between Business Service and Business Service Offering has 1:1 cardinality and a label “Published as” while I could only find “Published item” and “Parent” references and I suppose it should be one-to-many type of relation.
- Entity relation between Business Service and Service Portfolio in my instance is called “Service Portfolio” while the white paper described it as “Is part of”
These conflicts might be because of missing or outdated plugins in my instance, so let me know, if you’re instance is already up-to-date with the white paper.
Anyways, this is already very helpful, but a logical model combining the conceptual model with these relationship types is something to look for.
CSDM Examples and Actual Data Models
As discussed, a logical data model, including actual table names, reference fields, and relationship types, would be very useful.
Despite ServiceNow’s intent to update the ITSM reference architecture with an ERD for CSDM (as outlined in the CSDM 2.0 whitepaper), the one included in the version 5 white paper is intentionally blurry. In the announcement presentation, Mark Bodman commented that they are still considering whether it’s okay to publish data model diagrams with so many details, as that could be considered confidential design documentation. I really hope, this information becomes available to ServiceNow customers and partners, if not to the whole World.
In any case, since CSDM version 3, we’ve been publishing “Blueprint Templates” that describe the logical data models for different domains within CSDM. We also plan to continue creating these templates according to CSDM 5. Currently, the CSDM 4 templates are available in our DCM Content Pack for CSDM.
I’m not planning to present all the templates here, but let’s look at some examples. As mentioned, we’ve split the CSDM into smaller pieces, utilizing Data Content Manager as the visual design tool. According to CSDM 5, and the dictionary included in the Yokohama instance, the data model for Business Service Offerings could look like this:
Business Service Offerings data model
This CSDM example data model has been drawn from the Business Service Offering’s point-of-view. A filter on the Service Offering table only includes Business Service Offerings, while another model is available for Technology Management Service Offerings.
The whitepaper does not really describe the exact relationships between Service Offerings and Request Catalog except that Request Catalog is the sc_catalog table. In the above example, this relationship is defined via Catalog Items that are made available for the subscribers of the Service Offering and belong to a particular Catalog.
More information about the Request Catalog relationships in our CSDM 4.0 webinar from November 2021, which is still valid for the most parts.
Adding Foundation Data to the CSDM Example Model
Since the CSDM version 3, there has been more focus on Foundation Data, but not even the latest version define how, exactly, Foundation Data should be related to the rest of the model. This part probably varies the most between organizations, depending on how they are structured and how responsibilities have been defined.
Below is an example, where I have simply added some User and Group references to the model to ensure that responsibilities are in place.
Business Service Offering data model with Foundation Data references
My Differing Opinions
A Service Portfolio can include many more details like SLA definitions and Service Commitments, Subscribers, and so on. One thing that still bothers me a bit in this model is the prescribed relationship between Business Service Offering and the Application Service/Service Instance classes.
Another detail, where I have a slightly different opinion, is the relationship between Services and Business Capabilities. I would put that relationship on the Service Offering level, instead of Service. The same Service can have multiple different offerings where some of them relate to a capability and some maybe to a different capability. Or some of the offerings are related to Production environments while some only to Non-Production environments that do not have any impact on the Business Capabilities.
Doing the relationship on a Service level means that you lose this flexibility in defining dependencies between different offerings of the service and the business capabilities that those offerings provide.
Final Service Portfolio Model
My final version of the CSDM example model (as seen below) adds the Dynamic CI Group next to the new Service Instance and includes the Service Commitment and Subscriber relationships as additional examples. I left the Business Capability relation to Service as defined by CSDM. Overall, I consider my changes to be additions or extensions to the model, and I’ve tried to keep it compliant with the original definitions.
More generic Business Service Offering data model with Dynamic CIs, Subscribers and Commitments
All the additional relationships shown in these examples are based on an out-of-the-box setup of the Yokohama release, but not all are described as part of the CSDM. I cannot guarantee that these relationships will ever be part of the official model. However, they are already available Out-of-the-Box.
If your implementation is already at this level, then congratulations! You are one of the few and you probably have quite a mature Service Portal also utilizing all these wonderful service details and related capabilities.
CSDM Examples, Blueprint Templates & CSDM Content Pack
We have created these types of data models and CSDM examples as blueprint templates in our CSDM Content Pack. The Content Pack is freely available from the ServiceNow Store. You do need to have the Data Content Manager application installed to view the models, but there is a Free Trial available.
The current version of the Content Pack includes ~30 different blueprint templates for the CI classes and Foundation Data tables mentioned in the CSDM whitepapers. They are organized according to the different implementation phases and domains. The templates can be used as CSDM examples and as starting points for tuning the model to your specific needs.
Implementation Phases for Services?
All in all, the CSDM example data models presented above are quite demanding and are indicative of a rather mature service portfolio model. Therefore, it’s advisable to approach this topic with small steps and ensure you are on the right track from the very beginning to the very end. Data Content Manager can be an extremely useful tool for this.
Business Services are introduced in the model only when you are already in the Run phase. However, in my opinion, you can implement each CI Class with a similar model where you start small and increase the complexity as your maturity to handle it grows. Related to this idea, you might also want to look at our 5 steps model for data management.
One way to “crawl” is also to limit the scope of data by selecting a subset of all your services before launching the model for everyone.
Crawl Phase Data Model for Services
In the beginning I showed a CSDM example data model for the Business Service Offerings in Fly phase of the CSDM. If your focus is Services (maybe related to Customer Service Management), you can also start crawling from the Sell / Consume domain. In that case, the model for Business Service Offerings could look like this:
Business Service Offerings data model for “crawling”
Just make sure that every Service Offering has a Parent Service and you have responsible persons or groups defined. Without clearly defined (and implemented) responsibilities there is no reason to move any further. You cannot succeed with CMDB (or Service Portfolio) without proper ownership.
Read more about establishing ownership from here.
More information
If you want to know more about how to enforce ownership and maintenance of different data models on the ServiceNow platform, please do not hesitate to ask. Book a meeting with me, and I will show you how Data Content Manager can help you on your journey towards CSDM compliance and a better return on your ServiceNow investment.
Regarding “CSDM Compliance” and how out-of-the-box tools like the “CSDM Data Foundations Dashboard” can help, you should read this comparison to DCM. We’ve also published more detailed articles that compare the OOB dashboards to DCM specifically related to the CSDM Crawl Phase and the CSDM Walk Phase.
You also may want to check out our CSDM Solution page, where we have compiled all of our CSDM-related things, including a short demo video on how DCM helps with CSDM. Also, check out our free CSDM Content Pack for DCM.
Last, but not least, get our free eBook: CSDM – The Recipe for Success!
Talk to Us
Book a meeting with us, and we will show you how Data Content Manager helps you on your CSDM journey – regardless of your maturity level.
