About this recording: This webinar was recorded in November 2021 and reflects the ServiceNow Rome release and CSDM 4.0 guidance available at the time.
Some terminology, class structures, and product capabilities have evolved since then. The recording is still useful as a practical example of how service and offering data can support a more data-driven portal experience, but current implementations should be checked against the latest ServiceNow CSDM guidance.
Your Questions, Our Answers
Q: Will slides be available after the presentation?
Yes, we are happy to share the slides upon request. So please get in touch if you would like to get them!
Q: What is the medium-term target for a dedicated “Application Service” table… Use the existing “Application Service (discovered) class, or will another be created? If so, when?
Application Service (cmdb_ci_service_auto) already includes extended classes for different use cases. And ServiceNow has provided some guidance on using each of them.
In case you are creating app services manually, here are some instructions related to that.
Here is one great article on ServiceNow Community on how to use them: LINK
And another one: LINK
And finally, the ServiceNow Product Documentation page about Application Services describes, for example, the different types of application services.
Q: When do you use a Blueprint and when the Content Planner?
A Blueprint is a visual representation of a data model. It includes tables, their relationships, and filters and conditions that define the type of data to be used.
The Content Planner is a data management tool within DCM to maintain data on top of a Blueprint. In the Content Planner, you work with the data, while a Blueprint defines the data model that you are supposed to use. The Content Planner overlays real data on top of the Blueprint so that data can be updated with a visual tool, minimizing the possibility of errors.
Please view a short introduction video on our product page that explains all DCM modules briefly.
Q: What does DCM cost, and what is the basis for licensing? Users, CI’s, Tasks?
Licensing is based on the number of active blueprints. There are no limits on users, tasks, or data that can be audited or maintained with DCM. Contact us to discuss the cost.
Q: We have an on-premise installation of ServiceNow. Can DCM be used in an on-premise instance?
Yes. By default, all ServiceNow store apps can be installed into on-premise instances. (More info about this here)
Q: Venni’s example and the following “data models” included subscribers and catalog items. Are those also part of the CSDM?
Yes, “Service Offering Subscribers” has been defined as part of Extended CSDM in the CSDM Process Guide.
For more info: Search for “CSDM Process Guide” after following this link.
Q: We have a mixture of everything in our (Business) Services table at the moment. How should we transform those into Business Applications, Application Services, Offerings, and Services?
This is a very typical scenario. Depending on the exact situation (including organizational structures, data volumes, available resources etc.), there are also several ways to address this.
With DCM, you can define simple models for each of the required classes and start auditing and guiding users on populating the missing records. By categorizing or grouping the existing Services, you can manage the transition and identify if a record is still to be processed or already a real Service, as defined by CSDM.
Tags or taxonomy nodes can be used over the transition without creating extra attributes.
This approach aims to ensure that all new records created in the Business App, App Service, and Offering tables are aligned with CSDM from the beginning. The original “Service records” act as a to-do list.
Auditing all of these models continuously will give you proper metrics to follow up on the progress and identify deviations against the plans.: Search for “CSDM Process Guide” after following this link.
Resources from ServiceNow
ServiceNow has a lot of useful content available regarding CSDM. We think it’s sometimes a little hard to find, so we curated a list here. Some of these resources may require you to log in with your ServiceNow credentials.
- CSDM @ ServiceNow community
- Already ongoing discussion about CSDM 4.0
- CSDM @ Product Docs
- We’d like to highlight Product Views
- CSDM @ Youtube
- Lots of videos hosted by ServiceNow experts addressing CSMD from different aspects
- CSDM @ Now Learning
- (Search for CSDM)
- CSDM @ Now Create
- (Search for CSDM or CMDB)
- Includes prescriptive presentations available for download
- We’d like to highlight the CSDM Value and delivery methodology (CSDM Process Guide)
- Customer Success Center
- Note: the Customer Success Center can be used to search across Servicenow resources
- CSDM whitepapers
- CSDM 4.0 draft version was published at NowCommunity in January 2022
- CSDM 3.0 final release available in this community post.
Next live session
See how to build trust in your ServiceNow data
In a one-hour live demo we show how Data Content Manager turns ServiceNow data quality from dashboards and manual follow-up into a continuous operational process: define what good data looks like, audit your actual data, engage the people who own it, and remediate the issues that matter.
What this CSDM 4.0 portal example still teaches us
The ServiceNow release and CSDM version shown in this webinar are now historical, but the central implementation idea remains useful:
A data-driven portal is only as reliable as the service, offering, relationship, and ownership data behind it.
A portal can be designed beautifully, but if the underlying ServiceNow data is incomplete or inconsistent, users will still see the wrong services, unclear options, or missing context.
That makes portal quality partly a data-modeling and governance problem.
Start with the services and offerings users actually consume
A useful portal experience depends on a clear distinction between the services an organization provides and the specific offerings available to different users.
ServiceNow continues to use Business Services and Business Service Offerings as part of its current CSDM model. Business Service Offerings represent variations in how a service is delivered, such as different availability, geography, capability, packaging, or service commitments.
For portal design, that means teams should be clear about:
- Which services should be visible to users
- Which offerings belong to those services
- Which users or groups should see each offering
- Which catalog items or requests relate to the offering
- Which ownership and support information needs to be maintained
The portal experience becomes much easier to manage when those relationships are defined in the data rather than recreated manually in the user interface.
Use the data model to drive the portal instead of maintaining parallel content
A manually curated portal can work at small scale.
But as the number of services, offerings, users, regions, and business units grows, manual maintenance becomes harder to sustain.
A more scalable approach is to let the ServiceNow data model drive more of the experience.
For example:
- The service record defines what is being provided
- The offering defines how that service is consumed
- Subscription or audience data determines who can access it
- Relationships connect the service to supporting applications or technical services
This reduces the need to maintain the same information separately in multiple places.
Keep service and offering structures understandable
One challenge discussed in the webinar is what to do when an existing Business Services table contains a mixture of legacy records, technical concepts, and different service types.
That situation is common in long-running ServiceNow environments.
The important thing is not to force every legacy record into a new model immediately.
Instead:
- Identify which records support current user-facing or operational use cases.
- Separate legacy structures from the target model.
- Define which services and offerings should remain active.
- Move or remodel records progressively.
- Validate the relationships as the transition continues.
This reduces the risk of turning a CSDM migration into a large one-time data cleanup exercise.
Let portal use cases determine offering granularity
Service Offerings should be specific enough to represent meaningful differences for consumers, but not so granular that they become impossible to maintain.
Useful differences might include:
- Region
- Availability
- Service level
- Capability
- Packaging
- Business audience
The question should be:
Does this distinction help a user understand, choose, request, or manage the service?
If the answer is no, the extra offering may add complexity without improving the portal.
Current ServiceNow guidance still describes Business Service Offerings as a way to differentiate a Business Service by factors such as availability, localization, pricing, capability, and packaging.
Subscriptions and audiences need reliable source data
If the portal experience depends on showing specific services or offerings to specific users, then subscriber and audience information becomes part of the data-quality problem.
That may depend on:
- User data
- Groups
- Departments
- Companies
- Locations
- Other foundation data
If those references are stale or incomplete, the portal may show the wrong options or hide the right ones.
This is one reason foundation data and service data should not be governed separately from the user experience they support.
Use continuous audits during migration
Moving from a legacy service model toward a more structured CSDM model is not only a design exercise.
The live data needs to be checked as the migration progresses.
Audits can help answer questions such as:
- Which services are missing offerings?
- Which offerings have no valid owner?
- Which services are still using legacy relationships?
- Which user-facing records are missing required subscriber or audience information?
- Which new records do not follow the target model?
That turns the transition into a measurable process instead of relying on a one-time migration checklist.
Separate modeling from maintenance
The webinar also highlights an important distinction between designing the target structure and maintaining the live records.
The data model defines what should exist.
Operational tools and workspaces help people maintain the records according to that model.
Those responsibilities do not always belong to the same person.
Architects and platform teams may define:
- The service structure
- Required relationships
- Offering rules
- Ownership requirements
Service owners, application owners, and other data providers can then maintain the actual records.
That separation helps scale the model beyond the central ServiceNow team.
The evergreen lesson: user experience depends on data structure
The biggest takeaway from this historical CSDM 4.0 example is not a specific Rome-era configuration.
It is the principle that a portal becomes easier to scale when the user experience is driven by structured, governed ServiceNow data.
The better the underlying service and offering model, the easier it becomes to:
- Show relevant services to the right users
- Reduce manual portal maintenance
- Keep ownership visible
- Support consistent reporting
- Adapt the experience as the organization changes
For current CSDM implementation guidance, see our CSDM in ServiceNow: How to Align and Succeed guide.
For the latest model and terminology, refer to ServiceNow's current CSDM overview.
