cmdb_ci_service vs cmdb_ci_business_app — correct usage boundary

[Majdsalim]

Hello Dears

I am currently working on a ServiceNow implementation that includes the following modules:

• ITSM (Incident, Change, Problem, Request)
• ITOM (Discovery + Service Mapping)
• SAM Pro (Software Asset Management)
• SPM (Demand Management)

As part of the CMDB design, we are trying to build our implementation following ServiceNow best practices and align our approach with the CSDM framework. We would appreciate clarification on the following:

1. cmdb_ci_service vs cmdb_ci_business_app — correct usage boundary

My current understanding is:

• cmdb_ci_service represents operational services consumed by end users and is the correct CI class to associate with ITSM records (Incidents, Changes, Problems, Requests). It is also can be auto-populated by Service Mapping.
• cmdb_ci_business_app represents business applications from an organizational/portfolio perspective, lives in the Design domain of CSDM, and is more relevant to APM and SPM rather than ITSM ticket association.

Is this understanding, correct? And what is the recommended CSDM relationship between these two classes — specifically in a context where Service Mapping is active and populating Services how will these services be classified as Application Services, Business Services or Technology Management Service — following best practices? In addition, if we have a Business Application that can be considered a Service as well what will the best practices in defining the name for it as a Business Application and as s Service?

2. Mapping Business Applications to Software Entitlements in SAM

Given that cmdb_ci_business_app will be used as the anchor for Demand Management in SPM — is it a supported and recommended best practice to link Business Applications to their underlying software entitlements in SAM Pro?
#CMDB 

[ayushraj7012933 · Accepted solution]

Hi @Majdsalim ,

Your understanding is generally correct and aligns well with CSDM principles.

For cmdb_ci_business_app, think of it as the logical representation of an application from a business, portfolio, and architecture perspective. It is primarily used for ownership, lifecycle management, investment planning, and SPM/APM use cases.

For operational processes such as Incident, Change, Problem, Event Management, Discovery, and Service Mapping, the recommended CSDM approach is to use Application Services and Business Services rather than the Business Application record itself.

When Service Mapping is enabled, the discovered services are typically created as Application Services, which represent the running application and its supporting infrastructure. These Application Services can then support one or more Business Services that represent the business capability consumed by users.

A simplified relationship model would be:

Business Service → Application Service → Infrastructure CIs

and

Business Application → Application Service

This provides traceability between the portfolio view and the operational view while maintaining CSDM alignment.

Regarding naming, if the Business Application and Service represent the same business capability, it is common to keep the business name on the Business Application (e.g., "SAP ERP") and use environment- or operation-specific names for Application Services (e.g., "SAP ERP Production", "SAP ERP UAT").

For your second question, associating Business Applications with software products/models used by the application is a common practice and provides valuable insights for SAM, APM, and SPM reporting. However, entitlement compliance calculations should continue to be driven by Software Models, Installations, Entitlements, and Contracts. The Business Application should be treated as a consumer or owner context rather than the licensing source of truth.

Following this model keeps ITSM, ITOM, SAM Pro, and SPM aligned with CSDM while maintaining clear separation between business architecture, operational services, and software licensing.

Hope this helps.

[ayushraj7012933 · Accepted solution]

Hi @Majdsalim ,

Your understanding is generally correct and aligns well with CSDM principles.

For cmdb_ci_business_app, think of it as the logical representation of an application from a business, portfolio, and architecture perspective. It is primarily used for ownership, lifecycle management, investment planning, and SPM/APM use cases.

For operational processes such as Incident, Change, Problem, Event Management, Discovery, and Service Mapping, the recommended CSDM approach is to use Application Services and Business Services rather than the Business Application record itself.

When Service Mapping is enabled, the discovered services are typically created as Application Services, which represent the running application and its supporting infrastructure. These Application Services can then support one or more Business Services that represent the business capability consumed by users.

A simplified relationship model would be:

Business Service → Application Service → Infrastructure CIs

and

Business Application → Application Service

This provides traceability between the portfolio view and the operational view while maintaining CSDM alignment.

Regarding naming, if the Business Application and Service represent the same business capability, it is common to keep the business name on the Business Application (e.g., "SAP ERP") and use environment- or operation-specific names for Application Services (e.g., "SAP ERP Production", "SAP ERP UAT").

For your second question, associating Business Applications with software products/models used by the application is a common practice and provides valuable insights for SAM, APM, and SPM reporting. However, entitlement compliance calculations should continue to be driven by Software Models, Installations, Entitlements, and Contracts. The Business Application should be treated as a consumer or owner context rather than the licensing source of truth.

Following this model keeps ITSM, ITOM, SAM Pro, and SPM aligned with CSDM while maintaining clear separation between business architecture, operational services, and software licensing.

Hope this helps.

[jasonjohns5 · Accepted solution]

Yes, your understanding is generally correct and aligns with CSDM best practices. In CSDM, cmdb_ci_business_app represents the logical/business-facing application from a portfolio and ownership perspective, mainly used in APM/SPM and business planning. On the other hand, cmdb_ci_service (more specifically Application Services under CSDM) represents the operational service consumed by users and is the recommended CI to associate with ITSM processes such as Incidents, Changes, Problems, and Requests. With Service Mapping enabled, discovered services are usually classified as Application Services because they represent running operational services supported by infrastructure. The best-practice relationship is typically: Business Application → supports/provided by → Application Service. If the same application is also exposed as a service, use different naming conventions to avoid confusion — for example, “SAP ERP” as the Business Application and “SAP ERP Production Service” as the Application Service.

Regarding SAM Pro, yes — linking Business Applications to software entitlements is both supported and recommended. In mature CSDM-aligned environments, the Business Application acts as the governance and planning anchor, while SAM tracks software usage, licenses, and entitlements underneath it. This relationship provides better visibility for cost, ownership, compliance, lifecycle management, and Demand Management within SPM.