Introduction

In the expansive world of ServiceNow, structure and clarity are key. ServiceNow’s Common Service Data Model (CSDM) offers a recommended framework to bring order to IT ecosystems. While the CSDM is sound, it leaves considerable room for interpretation—making consistent application across an enterprise crucial for achieving meaningful results. Based on best practices and experience, here’s a guide to ServiceNow modeling for services, assets, and configuration items.


Best Practices in ServiceNow Modeling

1) Understand Products vs. Instances

A Product (often called a baseline, model, service, or portfolio item) fundamentally differs from an instance (also known as a Configuration Item or CI). For example, a Volvo V70 as a model is a Product—it doesn’t “break.” However, the Volvo V70 with a specific license plate is an instance that can break, change, or cause problems. Products serve as templates for instances but products are no collections of instances; (meanwhile, Dynamic CI groups, which we discuss below, are collections of instances.)

2) Dynamic CI Groups for Targeted Management

When it’s necessary to manage several Configuration Items (CIs) as a single entity, ServiceNow offers Dynamic CI Groups. These groups can encompass multiple CIs based on specific criteria, such as “All Netherlands-based computers running Windows” or “All SQL Server 2016 instances in Data Center X.” A Dynamic CI Group is a collection of instances, but is not a managed Product.

3) Business Applications and Their Lifecycle

A Business Application is a software product owned by the enterprise, often deployed on servers/cloud, with deployments governed by formal change management. Only applications providing a Business Capability are considered Business Applications. Applications without a capability, or those not owned by the enterprise, should not be classified as Business Applications.

4) Platform-Integrated Software

Software integral to a Platform (e.g. an application on a platform) may be registered as a independent Business Application that is part of a known Platform Host. If one register the module as a Business Application, one needs to adhere to all rules that apply to a business applications; e.g. periodic review of status/lifecycle, appliation specific compliance/risk/security activities (penetration testing, role based access). Friendly advise: Only register Business Application Modules if you can justify the extra time that this will require your company on managing it. Furthermore, please note that those modules must be linked to a platform host, so that they can be hidden from Enterprise wide Business Application Reports (e.g. ServiceNow consist of hundreds of applications in a dozen application families; if an company has thousand business applications, and all would consist of a dozen “application” then the company needs to manage twelve thousand application products; undoable).

5) IT Management Software in IT4IT Domain

IT-specific management software, even if used indirectly to support business functions, should be classified as a Business Application in the IT4IT domain, as it provides indirect Business Capabilities e.g. to end-users. Examples are JIRA, GITLAB, INTUNE, AZURE, AWS, MS-DEVOPS, ASANA, SLACK, SERVICENOW,

6) Solution Components on Platforms

Solution/Application Components, like plugins, or portals can be registered as Business Applications within a Platform if they provide Business Capabilities and have independent lifecycle management. However, smaller components such as scripts, APIs, and microservices should be registered as SDLC components, not as Business Applications. SDLC Components are seperately registered and related to the Product they belong to, Instances of SDLC components may optionally be registered as part of the Application Service Instance Stack. This only makes sense if these SDLC instances are actively used in the incident, event, problem or change management processes in ServiceNow. This information can also be used to link infrastructure instaces to the applications and offerings that are releated to the SDLC Component.

7) Service-Based Product Models

Products are often provided “as a Service,” ranging from SaaS and PaaS to IaaS and more. A Service includes all necessary elements—for instance, SQL Server as PaaS includes the server, OS, and network it depends on. This differs from Business Application instances, which are individually managed/changed.

8) SaaS Lifecycle Management

For SaaS products not directly managed by the enterprise, it’s essential to govern their lifecycle and integrate them within the IT landscape. Some companies choose to register SaaS products as Business Applications. Those companies need to be mindfull that the companies does not implement changes to the SAAS instances (the vendor does that). Also the vendor, not the customer, is accountable for the lifecycle of the SAAS instance. Registering a SAAS product (that you don’t own or manage) in your own Business Application Portfolio, will impact life-cycle planning and compliance management. Having this said: it makes perfect sense to register the SAAS “as a Service”, especilly if tickets on such services are automatically routed to the party/parties that provides support on/for it.

9) Managing SaaS, PaaS, IaaS, and Other Services

Generally, avoid registering components of SaaS, PaaS, or IaaS solutions managed by a vendor. Instead, enterprises should mark the point of service consumption and set local or regional service level agreements for that boundary. Register Service Instances for these agreements rather than the components themselves.

10) End-User Devices incl. what is in/on it.

The deployment of (Software on) individual End-User Devices is hardly ever authorized via Change Management. The software/hardware entitlements are often authorized and provided via a corporate policy or with group memberships. Device managers such as JAMF, INTUNE and TANIUM, deploy the entitlements and discover the software if/when it is installed on the End-user device. The device (incl. what is in/on it, and incl. its primary user) typically is federated from the Device Manager into ServiceNow. Some enterprise deploy agent on end user devices, that can feed additional info into CMDB (directly or indirectly, on near-real-time basis) and that may be used to remotely operate the device. The End-User software that is discovered and federated, are not a business application. It is recommended to register incidents on the End-user device CI itself, not on what is in/on it.

11) End-user software in the cloud

End-User Software Suites running in the Cloud are single SAAS applications that are often used by multiple users. For End-User Suites such as Microsoft 365, Google, Adobe, etc., it is recommended to register each Suite as a Business Application and/or SAAS Service rather than registering the dozens of individual apps that typically are included in that Suite. Shared Collaboration apps that run in the cloud, such as Zoom, MS-Teams, MS-Exchange, MS-SharePoint, etc. are recommended to be registered as individual Business Applications and/or SAAS Services and must be managed accordingly (i.e. via Incident, Problem and Change Mngt). When it is decided that the end-user suites must be registered as Business Applications, its instances/tenants of those must also be registered as Application Service Instances.


The Complexity of Modern IT Landscapes

Managing ServiceNow configurations effectively requires understanding specific deployment nuances:

  • Business Application Instances: Multiple instances of the same application may have different capabilities or lifecycles, such as separate instances for HR and IT.
  • Mergers and Acquisitions: Large enterprises often have duplicate IT solutions, with various subsidiaries using distinct ServiceNow instances.
  • Cloud and On-Premises Deployment: Business Applications or SaaS components might be deployed on servers or in diverse cloud environments (public, private, or hybrid).
  • Outsourcing IT Solutions: In outsourced IT arrangements, an enterprise may maintain ownership, with the Managed Service Provider (MSP) handling maintenance.

Looking Ahead: ServiceNow’s Roadmap (2024–2026)

The next four ServiceNow releases will introduce a more generic Product Portfolio model covering any Product, including software, platforms, and services. This evolution aligns with IT4IT 3.0, culminating in CSDM Version 5.0:

  • Product Definition in “Build” and “Architecture & Design” Domains: Governed by architects and analysts, products will fall under these domains.
  • Stacked Product Components: Product components will be stackable, supporting instances of various product types like software, cloud, platform, or service.
  • Technical and Business Service Offerings: Stacks will support service offerings, with incidents, changes, and cases linked to both the stack instance and the related service.
  • Service Delivery Governance: Delivered items (assets) will be managed under local or regional Service Offerings, with CI groups supporting associated Dynamic CI groups.

Achieving a “Zero-Touch” CMDB with Automation

To support automated decision-making, enterprises should structure their ServiceNow data in the following categories:

  1. Digital Product Portfolio: Consists of enterprise-owned items requiring lifecycle management, which can be tracked in ServiceNow or federated from architecture tools.
  2. Infrastructure Instances: Automatically detected and registered in the CMDB through IP discovery or agent collectors.
  3. Product Instances: Created automatically in the CMDB following catalog orders, with ordered items pushing data to ServiceNow.
  4. Provisioned Items: Fine-grain components linked to digital products and infrastructure, enabling automated alert routing and support assignment.

With automated discovery and federation, enterprises can maintain an accurate, real-time CMDB with minimal manual updates.


With these practices, your ServiceNow environment can become a streamlined, automated platform that evolves alongside emerging frameworks like IT4IT 3.0, ensuring a clear and consistent structure for service, asset, and configuration management.