CSDM Service Modeling — Building the Service Map in Practice
You now understand CSDM's four domains conceptually. This topic focuses on
the practical implementation: how do you actually build the service model?
How do Application Services get populated? How do Business Applications link to them?
How does change impact analysis use the service model? And what are the common
modeling mistakes that make CSDM fail to deliver value?
📋 9 sections⏱ ~35 min read🎯 ~11% exam weight (CSDM domain)🏷 Application Service · Service Mapping · Business Impact · Owned By
Section 1
Two Ways to Build Application Service Maps
An Application Service record in CSDM is the container for all CIs that make
an application work. There are two primary ways to populate it:
Approach 1: Service Mapping (Automated — Recommended)
Service Mapping (covered in Part 3 Topic 4) discovers application dependencies
automatically by starting from an Entry Point (URL or IP) and tracing all
connected infrastructure. The output is automatically written as an Application
Service CI with all discovered CIs linked as members.
Advantages:
Accurate — reflects actual runtime dependencies, not assumed ones
Auto-updates when the infrastructure changes (new servers added, services moved)
Doesn't require IT staff to manually document what "supports" what
Approach 2: Manual Service Modeling
An administrator manually creates an Application Service CI and manually relates
individual CIs to it using the CI relationships editor. Used when:
Service Mapping can't reach the application (air-gapped environment, non-HTTP entry point)
The application uses protocols Service Mapping doesn't support
A quick approximation is needed before Service Mapping is configured
Disadvantage: manual models drift — as infrastructure changes, someone must remember
to update the model. Service Mapping keeps it current automatically.
⚠
Exam Pattern — Service Mapping = Preferred CSDM Population Method
When an exam question asks "how should an Application Service in CSDM be populated
for an enterprise web application?", the answer is Service Mapping — because it
automates the discovery and keeps the model current. Manual modeling is only
acceptable when Service Mapping is not applicable.
Section 2
Linking Business Applications to Application Services
Once Application Services are populated (either by Service Mapping or manual modeling),
the next step is connecting them to Business Applications. This creates the CSDM
Domain 1 ↔ Domain 2 link — the connection between the business perspective and the
technical implementation.
How to Create the Link
ServiceNow provides two ways:
From the Business Application CI: Open the Business Application record
(cmdb_ci_business_app). In the related lists at the bottom,
find "Supported by Services" and add the relevant Application Service records.
From the Application Service CI: Open the Application Service record.
Use the "Supports Business Applications" related list to link to Business Applications.
Both approaches create the same underlying relationship. The relationship type is
"Provided by" — the Application Service is provided by (i.e., supports) the Business Application.
One Business Application Can Have Multiple Application Services
Real enterprise applications often run as multiple services:
Business Application: "HR Self-Service" (cmdb_ci_business_app)
All three Application Services are linked to the same Business Application.
If any one fails, the Business Application is impacted.
💡
Key Concept — The Impact Propagation Chain
Once the full CSDM chain is built: CI → Application Service → Business Application →
Business Capability, ServiceNow can automatically propagate impact. An incident on a
server CI automatically shows which Application Services are affected, which Business
Applications those services support, and which Business Capabilities are at risk.
This is the core value proposition of CSDM.
Section 3
Ownership Fields in CSDM — Accountability Chain
CSDM is only useful if someone is accountable for each layer. ServiceNow CSDM
defines ownership fields at multiple levels:
CSDM Object
Ownership Field
Who Should Own It
Business Capability
Business owner
VP or Director of the business unit that depends on this capability
Business Application
Application owner + IT owner
Business: the department head. IT: the application manager or product owner
Application Service
Support group + Managed by
The IT operations team responsible for this service's availability
Technical Service
Managed by
The platform or infrastructure team owning the shared service
Infrastructure CI (Domain 4)
Owned by + Managed by
Owned by: the cost center / department. Managed by: the ops team
These ownership fields enable:
Incident routing: Incidents auto-assign to the support group of the affected Application Service
Change approval: Change requests automatically notify the Business Application owner for impact assessment
Accountability reporting: "Show me all Business Applications where the IT owner field is blank" — CMDB governance gap
💡
Tip — "Managed by" vs "Owned by" in CSDM
"Owned by" typically means business/financial ownership — who pays for it and is accountable for the business outcome.
"Managed by" typically means operational responsibility — who maintains, supports, and monitors it.
For a server CI: Owned by = Finance department (they allocated the budget), Managed by = Infrastructure team (they do patching and monitoring). Both fields should be populated for complete CSDM data.
Section 4
Change Impact Analysis — CSDM in Action
One of the most tangible benefits of a complete CSDM model is automated
Change Impact Analysis. When a Change Request is created in ServiceNow for a CI,
the system can automatically determine which Business Applications will be affected.
How Change Impact Analysis Works with CSDM
↓
Trigger
Change Request Created
CHG12345 is opened: "Patch server DB-PROD-01 on Saturday 2am." The technician links the CI DB-PROD-01 (cmdb_ci_db_instance) to the Change Request.
1
CSDM Relationship Lookup
CI → Application Service
ServiceNow traverses cmdb_rel_ci: DB-PROD-01 is a member of Application Service "HR Database". This relationship was built by Service Mapping.
2
CSDM Traversal
Application Service → Business Application
Application Service "HR Database" is linked to Business Application "HR Self-Service". This is the Domain 2 → Domain 3 CSDM link that connects technical services to business-recognizable applications.
3
Ownership Lookup
Business Application Owner Identified
Business Application "HR Self-Service" has VP of HR assigned as the business owner. ServiceNow now knows who to notify about this change — no manual lookup required.
4
Automatic Impact Communication
Stakeholder Notified + Change Calendar Updated
The system automatically notifies the VP of HR: "Your application 'HR Self-Service' is affected by Change CHG12345 on Saturday 2am — approval needed." The Change Calendar marks HR Self-Service as impacted during the maintenance window.
Without CSDM, this chain of reasoning requires manual investigation.
With CSDM, it happens automatically every time a Change Request references a CI.
⚠
Exam Pattern — CSDM Enables Automated Business Impact in Change Management
Expect exam questions asking "what is required for ServiceNow to automatically identify
which business applications are affected by a change to an infrastructure CI?"
The answer is: a complete CSDM model — specifically, the CI must be linked to an
Application Service, which must be linked to a Business Application. Without these
relationships, impact analysis is only manual.
Section 5
Incident Management with CSDM Context
CSDM also enhances Incident Management by providing business context to every incident:
Automatic business service detection: When an alert fires for a CI,
the incident is automatically associated with all Application Services that CI belongs to,
and all Business Applications those services support
Priority enrichment: An incident against a CI supporting a "Critical"
Business Application can automatically receive a higher priority than one against a
"Low" business criticality service
Stakeholder notifications: Business Application owners are automatically
notified when incidents affect their application
SLA selection: The correct SLA applies based on the affected Application
Service's Service Offering and Service Commitment
The Business Criticality Field
The business_criticality field on Application Service
and Business Application records (scale: 1-Critical, 2-High, 3-Medium, 4-Low) is used
by ITSM workflows to make automated priority decisions. Keeping this field accurate
requires ongoing governance — it doesn't auto-populate from Discovery.
Section 6
Common CSDM Modeling Mistakes
Organizations that rush into CSDM without understanding the framework often
create models that look complete but don't provide real value. Here are the
most common mistakes:
Mistake 1: Modeling at the Wrong Level
Creating one Business Application called "All Production Systems" and linking every
CI to it. This defeats the purpose — impact analysis says "all production systems are
affected" for every incident, which is useless.
Fix: Each distinct application (Salesforce, SAP, Custom Billing App)
should have its own Business Application record.
Mistake 2: Skipping Application Services
Linking CIs directly to Business Applications without Application Services.
This creates a flat model that can't distinguish which CIs support which aspect
of a multi-tier application.
Fix: Always use the Application Service as the intermediate layer.
CIs → Application Service → Business Application. Never skip layers.
Mistake 3: Stale Ownership Fields
Populating Business Application owners once and never reviewing them. After
reorganizations, staff changes, or departmental mergers, the ownership fields
become wrong. Automated notifications and approvals go to the wrong people.
Fix: Include Business Application ownership review in quarterly
CMDB governance reviews (covered in Part 6).
Mistake 4: Manual Service Models Without Refresh
Creating manual Application Service models and never updating them as infrastructure
changes. After 6 months, the model shows 3 servers supporting the application
when the actual infrastructure has grown to 12.
Fix: Use Service Mapping wherever possible. For manual models,
schedule a regular review (quarterly minimum) to verify CI membership.
⚠
Warning — Incomplete CSDM Is Worse Than No CSDM
An incomplete CSDM model (some applications linked, most not) creates a false sense
of security. When an incident fires, the impact shows "no Business Applications affected"
— because the impacted application's links were never configured. Operations teams
lose trust in the system and stop using it. Either commit to maintaining the model
or don't deploy it — a half-built CSDM model is actively misleading.
Section 7
Key Relationship Types in CSDM
CSDM uses specific relationship types from the cmdb_rel_type
table to connect CIs across domains. Understanding these relationship types matters
because they control how impact propagates through the model.
From (Child)
Relationship Type
To (Parent/Target)
Business Application
Uses::Used by
Application Service
Application Service
Depends on::Used by
Infrastructure CI (server, database, network device)
Application Service
Depends on::Used by
Technical Service
Technical Service
Depends on::Used by
Infrastructure CI
Business Application
Supports::Supported by
Business Capability
⚠
Exam Tip — Direction Matters for Impact Propagation
Impact propagates upward in the hierarchy. When a CI fails, the impact flows:
CI → Application Service (depends on CI) → Business Application (uses Application Service).
Relationship direction affects which way impact flows — if relationships are
created in the wrong direction, impact analysis won't work correctly.
Always verify: the CI is the "used by" side, the Application Service is the "depends on" side.
Section 8
CSDM Completeness in CMDB Health Scoring
ServiceNow's CMDB Health framework (covered in depth in Part 6) includes CSDM
completeness as a scoring dimension. CIs and Business Applications are evaluated
for:
Required fields populated: Are Business Application owner, support_group, business_criticality set?
Relationship completeness: Does each Application Service have at least one CI linked? Does each Business Application have at least one Application Service linked?
Ownership populated: Is the "owned by" field set for each CI class that CSDM requires it for?
Classification accuracy: Are CIs in the correct CMDB classes per CSDM guidance?
These CMDB Health scores for CSDM completeness help organizations identify gaps
in their service model and prioritize which applications need relationship data filled in.
Exam Quick Reference
CSDM Service Modeling — Key Facts
Application Services populated by Service Mapping (preferred) or manual modeling (fallback).
Service Mapping keeps Application Services current automatically. Manual models drift as infrastructure changes.
Link: Business Application → Application Service → CI. Never skip layers. Never link CIs directly to Business Applications.
One Business Application can have multiple Application Services. Each tier (web, app, data) can be a separate service.
Business criticality field on Application Service and Business Application drives automated incident priority decisions.
Change Impact Analysis requires full CSDM chain: CI → Application Service → Business Application. Without links, no automated impact.
Impact propagates upward: CI failure → Application Service impact → Business Application impact.
CMDB Health scores CSDM completeness: missing owners, empty links, wrong classes all count against CMDB health.
Term Grid
Change Impact Analysis
Automatic determination of which Business Applications are affected by a change to an infrastructure CI. Requires complete CSDM CI → Application Service → Business Application chain.
Business Criticality
Field on Application Service and Business Application (1=Critical to 4=Low). Used by ITSM workflows to set automatic incident priority and determine change approval requirements.
Impact Propagation
The automatic upstream flow of impact from a failing CI to all higher-level CSDM objects (Application Services, Business Applications, Business Capabilities) that depend on it.
Service Model (CSDM)
The complete map of relationships from Business Applications down through Application Services to infrastructure CIs. Built via Service Mapping and/or manual configuration.
Managed by vs Owned by
Managed by = operational responsibility (IT ops team). Owned by = business/financial accountability (cost center or department). Both needed for complete CSDM accountability chain.
CSDM Completeness Score
CMDB Health dimension measuring how fully CSDM relationships, ownership fields, and CI classifications are populated. Low score indicates missing service model data.
Exam Checkpoint
Practice Questions
Click any question to reveal the answer and explanation.
1. A company wants to use ServiceNow to automatically determine which Business Applications are affected when a specific Linux server CI goes down. The CMDB has accurate CI data. What additional configuration is required?
A) Configure SNMP monitoring on the Linux server
B) Create CSDM relationships: link the Linux server to an Application Service, and link that Application Service to the relevant Business Applications
C) Add the Linux server to a Static CI Group named "Impact Analysis Group"
D) Set the Linux server's priority field to "Critical"
💡 What's the chain that connects a CI to business applications in CSDM?
Answer: B — Automatic business impact determination requires the CSDM relationship chain: CI → Application Service → Business Application. The Linux server must be linked as a member of an Application Service (ideally populated by Service Mapping), and that Application Service must be linked to the affected Business Applications. Without this chain, ServiceNow has no way to traverse from an infrastructure CI to the business applications it supports.
2. An administrator has used Service Mapping to populate an Application Service for the company's e-commerce platform. Six months later, the platform added 3 new application servers. What happens to the Application Service model without manual intervention?
A) The Application Service model remains unchanged — manual update required
B) Service Mapping automatically discovers and adds the new servers to the Application Service on its next run
C) IRE automatically adds new servers to the Application Service when Discovery creates their CIs
D) The new servers appear as "Unassigned CIs" requiring a separate assignment process
💡 What does Service Mapping do automatically that manual modeling can't?
Answer: B — Service Mapping reruns periodically (based on schedule) and automatically detects changes to the application's infrastructure. When new servers are added to the application tier, Service Mapping discovers them through its dependency traversal process and updates the Application Service membership. This is the primary advantage of Service Mapping over manual modeling — the service map stays current without administrative intervention.
3. A Change Request is submitted to patch a database server. ServiceNow shows no Business Applications affected in the Impact Assessment section. The CMDB has the database server CI accurately populated. What is the most likely reason no Business Applications are shown?
A) Database servers are not included in Change Impact Analysis by design
B) The database server CI is not linked to any Application Service, or the Application Service is not linked to any Business Application
C) The Change Request type is incorrect — use "Emergency Change" to trigger impact analysis
D) Business Application impact is only shown for network device CIs, not servers
💡 What does Change Impact Analysis traverse to find Business Applications?
Answer: B — Change Impact Analysis follows the CSDM relationship chain: CI → Application Service → Business Application. If the database server is not a member of any Application Service, or if the Application Service has no Business Application linked, the traversal finds no Business Applications to report as affected. The CI data accuracy (which is fine) is irrelevant — it's the CSDM relationships that are missing.
4. A company has CSDM implemented. When an incident fires against a server, it should automatically receive a higher priority because the server supports a Critical business application. This is NOT happening. All incidents against this server get Medium priority. What field is most likely missing or incorrect?
A) The server's ip_address field is null
B) The Business Application's business_criticality field is not set (or set to a lower value than expected)
C) The incident's category field is blank
D) The Application Service's support_group field is blank
💡 Which field drives automatic incident priority enrichment in CSDM?
Answer: B — Automatic incident priority enrichment based on business application criticality depends on the business_criticality field being correctly set on the Business Application (or Application Service). If it's blank or set to "Low"/"Medium," the ITSM workflow uses those values for priority calculation. The support_group (D) affects routing, not priority. The server's ip_address (A) has no bearing on priority calculation.
5. An organization's CMDB Health report shows a low "CSDM Completeness" score specifically for the "Application Service to Business Application" dimension. What does this mean and what should the administrator do?
A) There are too many CIs in each Application Service — reduce the number of CIs per service
B) Most Application Services in the CMDB are not linked to any Business Application record — the administrator should create Business Application records and link them to the existing Application Services
C) The Application Services are missing support_group assignments — the administrator should assign support groups
D) Application Services have duplicate records — run a deduplication scan
💡 "Application Service to Business Application" dimension measures the relationship links between Domain 2 and Domain 1.
Answer: B — A low score on the "Application Service to Business Application" dimension specifically means that Application Service records exist (Domain 2) but are not linked upward to Business Application records (Domain 1). This is a CSDM relationship gap — the service model stops at the technical service layer and doesn't connect to the business layer. The fix is to create Business Application records for each application the organization runs and link them to the corresponding Application Services using the "Supported by Services" relationship.
Exam Checkpoint
Practice Questions
4 questions · Select an answer to see the explanation immediately.
CSDM Service Modeling Quiz1 / 4
A Change Request for a database server shows no Business Applications in the Impact Assessment section, even though the server supports the company's main e-commerce platform. What is the most likely cause?
💡 Explanation
B is correct. Change Impact Analysis traverses the CSDM chain: CI → Application Service → Business Application. If the database server is not a member of any Application Service, or if the Application Service has no Business Application linked, the traversal finds nothing to display. Accurate CI data alone is insufficient — the CSDM relationship chain must be complete. Service Mapping populates the CI-to-Application Service link; Business Application records must be created and linked separately.
An organization manually created Application Service models 12 months ago for all major applications. Six months ago, each application's infrastructure doubled in size. The CSDM Health score shows low completeness. What is Service Mapping's advantage over manual modeling in this scenario?
💡 Explanation
B is correct. Service Mapping automatically discovers application dependencies by following live network connections. On each scheduled run, it detects new servers added to the application tier and updates the Application Service membership. Manual models require an administrator to manually add new CIs whenever infrastructure changes — after 6 months of growth, manual models are typically stale and incomplete. Service Mapping is the preferred approach precisely because it keeps the service model current automatically.
Incidents against a server that supports a "Critical" Business Application are getting Medium priority automatically. The CSDM chain is complete (CI → Application Service → Business Application). What field is most likely incorrect?
💡 Explanation
B is correct. Automatic incident priority enrichment based on business application criticality reads the business_criticality field (scale: 1=Critical, 2=High, 3=Medium, 4=Low) on the Business Application or Application Service. If this field is blank or set to Medium/Low, the ITSM workflow calculates a medium priority even for a business-critical service. Setting business_criticality=1 (Critical) on the Business Application enables the automatic High/Critical priority assignment for incidents affecting it.
An organization creates one Business Application called "All Production Systems" and links every CI to it. What problem does this CSDM anti-pattern create?
💡 Explanation
B is correct. Grouping all CIs under one "catch-all" Business Application defeats the purpose of CSDM. When an incident fires, impact analysis says "All Production Systems affected" — which is true but useless. It can't distinguish which specific application is impacted, which business owner to notify, or what priority the incident should receive. Each distinct application (Salesforce, SAP, Custom Billing) should have its own Business Application record so impact analysis provides precise, actionable information.