CSDM CI Alignment — Mapping Discovered CIs Into the CSDM Framework
The final piece of the CSDM puzzle: how do discovered CIs from different sources
(Discovery, SGC, Import Sets) get properly aligned to CSDM's prescribed classes
and roles? What happens when Discovery creates CIs in the wrong classes?
How do CSDM alignment rules validate your data model? This topic brings together
everything from Parts 2-5.
📋 8 sections⏱ ~30 min read🎯 ~11% exam weight (CSDM domain)🏷 CSDM Alignment · CI Class Mapping · Class Rules · CMDB 360
Section 1
Why CI Alignment to CSDM Classes Matters
Discovery and SGCs create CIs in specific CMDB classes based on what the scan or
API finds. In a perfect world, every discovered server becomes a
cmdb_ci_linux_server or
cmdb_ci_win_server, every cloud VM becomes a
cmdb_ci_vm_instance, and so on.
In practice, alignment problems occur frequently:
A Discovery pattern creates a Linux server as cmdb_ci_computer (generic) instead of cmdb_ci_linux_server
An Import Set creates application records in cmdb_ci_appl when CSDM expects them in cmdb_ci_business_app
A legacy integration creates all services as cmdb_ci_service without the correct service_type field set
When CIs are in the wrong classes, CSDM model-building fails: Service Mapping can't
identify them as supported CIs, Identification Rules for the correct class don't apply,
and CMDB Health shows class mismatches.
🗂️
Analogy — Wrong Class as Filing in the Wrong Drawer
Imagine a hospital filing records. A patient's X-ray report is filed in the
"Prescription Records" drawer instead of "Radiology." The record exists, it's accurate,
but no one looking for radiology records finds it. Similarly, a Linux server CI in
the generic "computer" class won't be found by queries targeting Linux servers,
won't match Linux-specific Identification Rules, and won't appear in
"Linux server capacity" reports.
Section 2
CSDM's Prescribed Classes — What Goes Where
CSDM specifies exactly which CI classes should be used for each type of IT entity.
Deviating from these prescriptions breaks the CSDM model. Key prescriptions:
IT Entity Type
CSDM-Prescribed Class
Common Misuse
Business Application (named app)
cmdb_ci_business_app
Using cmdb_ci_service or creating in cmdb_ci_appl
Application Service (technical map)
cmdb_ci_service_auto (CSDM 5: "Service Instance")
Using base cmdb_ci_service without subclass, or confusing with Business Service
Business Service
cmdb_ci_service_business
Confusing with Application Service; using base cmdb_ci_service without subclass
Technical Service
cmdb_ci_service_technical
Creating as a generic cmdb_ci_service without the correct subclass
Physical server
cmdb_ci_server → specific subclass (Linux, Windows, etc.)
Leaving in cmdb_ci_computer (too generic)
Cloud VM
cmdb_ci_vm_instance or cloud-specific class
Treating as a physical server; wrong CSDM domain placement
Conflating software instance with product; missing the product record
Business Capability
cmdb_ci_business_capability
Modeling as a Business Application; missing the capability layer entirely
💡
Key Concept — service_type Field on cmdb_ci_service Is Critical
All three CSDM service types (Application Service, Business Service, Technical Service)
use the same underlying table (cmdb_ci_service). The
service_type field distinguishes them. If this field is blank or
wrong, CSDM workflows, impact analysis, and CMDB Health checks cannot correctly
classify the service. Always verify service_type when creating or reviewing service CI records.
Section 3
Reclassifying Misaligned CIs
When you discover CIs in the wrong classes, you need to move them to the correct
class. This is called reclassification.
Reclassification is not a simple update — changing a CI's class has implications:
The CI must be "moved" from one CMDB table to another (the tables are physically different for different classes)
Fields that exist on the old class but not the new class may be lost
Fields that exist on the new class but not the old class start as null
Existing relationships (incidents, changes, cmdb_rel_ci) must be re-pointed
IRE Identification Rules for the new class will now apply on the next Discovery/SGC run
How to Reclassify a CI
ServiceNow provides a "Reclassify CI" action on CI records:
Open the misclassified CI record
Click the "Reclassify" button (available based on roles)
Select the new CI class
Review field mapping: which fields transfer, which are lost, which start empty
Confirm — the CI is moved to the new table and relationships are re-pointed
⚠
Warning — Fix the Source, Not Just the Symptom
Reclassifying a CI manually corrects it today. But if the underlying Discovery
pattern or SGC configuration still sends data with the wrong class, the CI will
be reclassified back to the wrong class on the next run (IRE will create a new CI
of the wrong class or update the existing one to wrong attributes).
Always fix the Discovery pattern or SGC class mapping BEFORE reclassifying CIs.
Otherwise you'll repeat the reclassification after every scan.
Section 4
Controlling CI Class from Discovery Patterns
Discovery Patterns (covered in Part 3 Topic 3) control which CMDB class is assigned
to discovered CIs. Getting this right is critical for CSDM alignment.
How Patterns Assign Classes
In a Discovery Pattern, each CI that the pattern creates or updates has a
CI class defined in the pattern steps. The pattern might have logic like:
If OS type = "Linux" → create as cmdb_ci_linux_server
If OS type = "Windows" → create as cmdb_ci_win_server
If device type = "Cisco IOS" → create as cmdb_ci_netgear_router (example)
In Pattern Designer (the UI for creating patterns), each CI output step lets you
configure the target class. If this is wrong or too generic
(cmdb_ci_computer instead of the specific OS class),
every CI created by this pattern will be misaligned.
💡
Tip — Audit Pattern Class Assignments After CSDM Rollout
When CSDM is being implemented in an organization, one of the first technical audits
should be reviewing all Discovery patterns and SGC class mappings to verify they
create CIs in CSDM-prescribed classes. This audit prevents the need for mass
reclassification later.
Section 5
SGC Class Mapping for CSDM Alignment
Service Graph Connectors map cloud/third-party API data to CMDB CI classes.
The mapping is configured in the SGC's "Data Mapping" section in ServiceNow.
Cloud-Specific Classes and CSDM
Cloud resources have specific CSDM-aligned classes:
AWS EC2 → cmdb_ci_vm_instance or cmdb_ci_ec2_instance (more specific, SGC-provided class)
AWS Lambda → cmdb_ci_aws_lambda_function
Azure VM → cmdb_ci_azure_virtual_machine
Kubernetes Pod → cmdb_ci_kubernetes_pod
ServiceNow-published SGC plugins define these classes and their CSDM alignment automatically.
Custom SGCs require manual configuration of class mappings.
When SGC Data Needs Business Application Mapping
SGCs are excellent at creating Domain 4 infrastructure CIs. However, SGCs generally
don't create Business Applications (Domain 1) — that requires business context that
cloud APIs don't provide. The typical workflow is:
Service Mapping discovers how they connect and creates Application Services (Domain 2)
Administrators manually create Business Applications and link to Application Services
Optionally: tagging strategies (Part 3 Topic 4 — tag-based service mapping) can automate some Domain 2-to-1 linking
⚠
Exam Pattern — SGC Creates Infrastructure CIs, Not Business Applications
SGCs are domain 4 tools — they populate infrastructure CIs. They don't create
Business Applications or Application Services automatically (unless specifically
configured to do so with custom mapping). The CSDM upper layers (Domains 1-2)
typically require human input to define the business context.
Section 6
Validating CSDM Alignment — Tools and Reports
ServiceNow provides tools to validate how well your CMDB aligns with CSDM prescriptions:
CSDM Alignment Report
Navigate to Configuration → CMDB → CSDM → CSDM Alignment Report.
This report shows:
Percentage of CIs in CSDM-prescribed classes vs. generic/incorrect classes
Business Applications without Application Services linked
Application Services without any CI members
CIs in Domain 4 not linked to any Application Service or Technical Service
"Orphan" CIs — existing in CMDB but not connected to any CSDM object
CMDB Health — CSDM Dimension
CMDB Health (Part 6) includes a CSDM dimension that scores how complete the CSDM
model is. Specific sub-scores include:
Business Application completeness: % of Business Applications with required fields populated and Application Services linked
Application Service completeness: % of Application Services with support_group, business_criticality, and CI members
Orphan CI percentage: % of CIs not connected to any CSDM service layer object
Section 7
CI Lifecycle Management Within CSDM
CSDM must reflect the actual lifecycle of IT services and infrastructure.
As CIs are provisioned, modified, and decommissioned, the CSDM model must stay current.
Key Lifecycle Events and CSDM Impact
Lifecycle Event
Required CSDM Action
New server provisioned
Discovery creates CI. Service Mapping adds it to Application Service. Business Application link already exists — no action needed for existing app.
New application deployed
Create Business Application record. Run Service Mapping to create Application Service. Link them. Assign owners and business_criticality.
Server decommissioned
CI operational_status set to Retired. Service Mapping removes it from Application Service on next run (if Service Mapping is active). Change must be reviewed for impact.
Application retired
Business Application and Application Service operational_status set to Retired. Remove from active service catalog. Retain for audit history.
Application migrated to cloud
New cloud CIs created by SGC. Service Mapping updated. Business Application linked to new Application Service. Old Application Service retired.
💡
Key Concept — CSDM Is Maintained, Not Set-and-Forgotten
CSDM is a living model. The full lifecycle of every application — from provisioning
to decommission — must be reflected in the CSDM structure. Service Mapping automates
the Domain 4 to Domain 2 updates. Humans must manage Domain 1 (Business Applications,
Business Capabilities) through the application lifecycle.
Exam Quick Reference
CSDM CI Alignment — Key Facts
CSDM prescribes specific CI classes for each type of IT entity. Wrong class = broken CSDM model.
Distinct subclasses distinguish service types: cmdb_ci_service_auto (Application Service / CSDM 5: Service Instance), cmdb_ci_service_business (Business Service), cmdb_ci_service_technical (Technical Service). Older deployments used a service_type field on the base cmdb_ci_service — both models exist, but current CSDM best practice uses subclasses.
Reclassification = moving a CI to the correct class. Must fix the source (pattern/SGC) first, or reclassification repeats after next scan.
Discovery patterns assign CI classes in pattern steps. Audit these for CSDM alignment when implementing CSDM.
SGC creates Domain 4 CIs (infrastructure). Doesn't automatically create Business Applications (Domain 1) — that needs human input.
Orphan CIs = CIs in CMDB with no CSDM service layer connections. High orphan count = low CSDM maturity.
CSDM Alignment Report shows class mismatches, missing links, orphan CIs. Starting point for CSDM gap analysis.
CMDB Health CSDM dimension scores Business Application completeness, Application Service completeness, orphan CI percentage.
Application lifecycle must be reflected in CSDM — provisioning, changes, and decommissions all require CSDM updates.
Term Grid
CSDM CI Alignment
The process of ensuring discovered/ingested CIs are in CSDM-prescribed CI classes and connected to the correct CSDM service layer objects. Required for CSDM-driven impact analysis to work.
Reclassification
Moving a CI from one CMDB class to another. Preserves relationships but may lose class-specific field data. Must be paired with fixing the discovery/ingestion source to prevent recurrence.
service_type Field
In older CSDM deployments, the service_type field on cmdb_ci_service distinguished service types. Current CSDM best practice uses distinct subclasses: cmdb_ci_service_auto (Application Service), cmdb_ci_service_business, cmdb_ci_service_technical.
Orphan CI
A CI in the CMDB not linked to any CSDM Application Service or Technical Service. It exists as raw infrastructure data with no business context. High orphan count indicates incomplete CSDM implementation.
CSDM Alignment Report
ServiceNow report showing gaps in CSDM implementation: misclassified CIs, missing Business Application links, empty Application Services, and orphan CIs. Used for CSDM gap analysis.
CI Lifecycle (CSDM)
The end-to-end management of CI data from provisioning through decommission within CSDM. Each lifecycle event (new app, migration, retirement) requires specific CSDM updates to keep the model current.
Exam Checkpoint
Practice Questions
Click any question to reveal the answer and explanation.
1. Discovery has been running for 6 months. A CSDM Alignment Report shows that 2,000 server CIs are in the cmdb_ci_computer class instead of cmdb_ci_linux_server or cmdb_ci_win_server. The admin reclassifies all 2,000 CIs manually. The next morning, the same 2,000 CIs are back in cmdb_ci_computer. What went wrong?
A) Reclassification is temporary — it always reverts after 24 hours
B) The Discovery patterns that create these CIs are still configured to use cmdb_ci_computer. IRE processed the next Discovery run and re-created them in the wrong class.
C) The CMDB Health job automatically reverts class changes to maintain consistency
D) The IRE Identification Rules require cmdb_ci_computer class for these CIs
💡 What creates these CIs? If the creator hasn't been fixed, what happens next time?
Answer: B — The Discovery patterns are still configured to create CIs as cmdb_ci_computer. When Discovery ran the next morning, it sent payloads with class=cmdb_ci_computer to IRE. IRE used the Identification Rules for cmdb_ci_computer, found (or didn't find) the existing CIs, and either updated them (in cmdb_ci_computer) or created new ones in that class. The manual reclassification was undone by the automated process. Correct sequence: fix the Discovery pattern class configuration first, THEN reclassify the existing misaligned CIs.
2. An administrator creates a new Application Service record for the company's ERP system in a CSDM 5 (Zurich+) instance. Which CI class should be used to correctly represent an Application Service?
A) cmdb_ci_service (with service_type=Application Service)
B) cmdb_ci_service_auto
C) cmdb_ci_business_app
D) cmdb_ci_appl
💡 CSDM 5 uses dedicated subclasses for each service type. Which subclass represents the technical service map?
Answer: B — In CSDM 5 (Zurich+), cmdb_ci_service_auto is the correct subclass for Application Services (also called "Service Instances" in CSDM 5). Older deployments (CSDM 3.x) used the base cmdb_ci_service table with a service_type field set to "Application Service" (option A). Both exist in modern instances, but the subclass approach (B) is the current best practice. cmdb_ci_business_app (C) is the Business Application (Domain 1 concept). cmdb_ci_appl (D) is a software installation CI in Domain 4.
3. An AWS SGC is running successfully and creating EC2 instance CIs. The CSDM Alignment Report shows these CIs as "Orphan CIs." What does this mean and what needs to be done?
A) The EC2 CIs have duplicate records that need to be merged
B) The EC2 instance CIs exist in the CMDB but are not linked to any Application Service or Technical Service — Service Mapping needs to run or manual service membership needs to be configured
C) The EC2 CIs are in the wrong class and need to be reclassified
D) The SGC is not properly authenticated and the CIs are incomplete
💡 "Orphan CI" means the CI exists but has no CSDM service layer connection. What provides that connection?
Answer: B — An Orphan CI is correctly classified and properly stored in the CMDB (the SGC is working fine), but it has no connection upward to any CSDM service layer object (Application Service or Technical Service). The EC2 instances exist as raw infrastructure data with no business context. The fix is to run Service Mapping to discover how these EC2 instances support applications (creating Application Service membership), or manually link them to Technical Services if they are shared infrastructure.
4. A company retires an on-premises application and migrates it to a cloud-native microservices architecture. From a CSDM perspective, what steps need to occur to keep the CSDM model accurate?
A) Delete the old Business Application and create a new one for the cloud version
B) Retire the old Application Service (domain 2), configure SGC for cloud CIs (domain 4), run Service Mapping to create a new Application Service for the cloud version, link the existing Business Application to the new Application Service, and retire the old on-premises CIs
C) Change the old Application Service's name to include "Cloud" and update the CI list manually
D) No CSDM changes needed — the Business Application record captures the business concept, which doesn't change
💡 A migration changes the infrastructure (Domain 4) and the technical implementation (Domain 2), but the business purpose (Domain 1) typically stays the same.
Answer: B — A cloud migration is a complex CSDM lifecycle event. The Business Application (Domain 1) represents the business function which doesn't change — keep it and re-link it. The old Application Service (Domain 2) should be retired (not deleted — preserve history). New cloud CIs are created by the cloud SGC (Domain 4). Service Mapping runs against the cloud entry points to create a new Application Service capturing the cloud architecture. Finally, the Business Application is re-linked from the old (retired) Application Service to the new one. This preserves business continuity in the CSDM model.
5. The CMDB Health report shows a "Business Application Completeness" score of 38% (critical threshold is 70%). The main driver is that 60% of Business Application records have the business_criticality and IT owner fields blank. What is the best approach to improve this score?
A) Run Discovery against Business Applications to auto-populate missing fields
B) Create a governance initiative: assign Business Application owners responsibility to populate required fields, track completion in CMDB Health, use targeted reporting to show applications with missing fields
C) Set a default value of "Medium" for business_criticality on all Business Applications
D) Delete Business Applications with incomplete fields and recreate them properly
💡 Who sets business_criticality and IT owner? Can automation do it?
Answer: B — Business Application fields like business_criticality and IT owner reflect business decisions that humans must make — Discovery cannot determine business criticality from a network scan. The correct approach is a governance initiative: identify Business Application owners, assign them responsibility for keeping their application's CSDM data current, use CMDB Health reporting to show gaps and progress, and potentially create tasks for owners with incomplete records. Option C (default "Medium") improves the score artificially without improving actual data quality — this defeats the purpose of CMDB Health.
Exam Checkpoint
Practice Questions
4 questions · Select an answer to see the explanation immediately.
CSDM CI Alignment Quiz1 / 4
Discovery patterns are creating server CIs in the cmdb_ci_computer class instead of cmdb_ci_linux_server. An admin manually reclassifies 2,000 CIs. The next morning, they are back in cmdb_ci_computer. What is the root cause?
💡 Explanation
B is correct. The Discovery patterns are still configured to send CI payloads with class=cmdb_ci_computer to IRE. When Discovery ran the next morning, it re-created or updated those CIs in cmdb_ci_computer. The manual reclassification was undone by the automated ingestion process. The correct sequence is: (1) fix the Discovery pattern to specify cmdb_ci_linux_server, (2) then reclassify the existing misaligned CIs. Without fixing the source, reclassification is perpetually undone by the next Discovery run.
The CSDM Alignment Report shows 3,000 AWS EC2 instance CIs labeled as "Orphan CIs." The SGC is running successfully. What does "Orphan CI" mean in this context?
💡 Explanation
B is correct. Orphan CIs are correctly classified and properly stored in the CMDB, but they have no upward connection to any CSDM service layer object (Application Service or Technical Service). The SGC is working fine — it created accurate Domain 4 CIs. The gap is in the CSDM model: no Service Mapping has run to link these EC2 instances to Application Services, and no manual service membership has been configured. High orphan count = low CSDM maturity.
When creating a new Application Service in CSDM 5 (Zurich+), which CI class correctly represents the technical service map (the set of CIs that make an application work)?
💡 Explanation
B is correct. cmdb_ci_service_auto is the correct subclass for Application Services in current CSDM best practice. In CSDM 5 (Zurich+), this concept was also renamed "Service Instance" but the table name remains cmdb_ci_service_auto. Option A (service_type approach on the base cmdb_ci_service table) was the legacy CSDM 3.x approach and still exists in many instances, but the subclass approach is preferred. CSDM distinguishes service types through dedicated subclasses: cmdb_ci_service_auto (Application Service/Service Instance), cmdb_ci_service_business (Business Service), cmdb_ci_service_technical (Technical Service).
An organization migrates an on-premises application to a cloud-native architecture. Which CSDM actions are needed to keep the model accurate?
💡 Explanation
B is correct. A cloud migration requires layered CSDM updates. The Business Application (Domain 1) represents the business function — keep it, don't delete it. Retire the old Application Service (preserve history). New cloud CIs are created by the SGC (Domain 4). Service Mapping creates a new Application Service from cloud infrastructure (Domain 2). Finally, re-link the Business Application from the retired old Application Service to the new cloud one. This preserves business continuity while accurately reflecting the new technical implementation.