› CIS-DF Hub › Part 3: Discovery › Service Mapping
⬡ Part 3 · Topic 4

Service Mapping — Discovering How Applications Actually Run

Discovery finds individual CIs — servers, databases, network devices. But a business application like "Online Banking" runs across dozens of CIs connected in specific ways. Service Mapping discovers those connections automatically, building a live application service map that shows exactly which CIs deliver each business service and how they depend on each other.

📋 9 sections ⏱ ~30 min read 🎯 ~19% exam weight (INGEST domain) 🏷 Service Map · Application Service · Top-Down · Bottom-Up · Traffic-Based
Section 1

What Discovery Misses — The Application Layer

You now have Discovery running. It finds every server, switch, and network device on your network. Each one has a CI record in the CMDB with detailed OS, hardware, and software attributes. This is excellent infrastructure visibility.

But consider your change manager's actual question: "If I take the database server DB-PRD-01 down for maintenance tonight, which business applications will be affected?"

Discovery cannot answer this. It knows DB-PRD-01 exists and has Oracle 19c running. But it doesn't know which application servers are connecting to it, which application those connections belong to, or which business process depends on that application.

That's the gap Service Mapping fills. Instead of just finding what CIs exist, Service Mapping discovers how they connect to each other to form a running application service.

🗺️
Analogy — Discovery vs. Service Mapping Discovery is like a phone book — it lists every person (CI) in the city with their address and phone number. Service Mapping is like a social network graph — it shows who talks to whom, who depends on whom, and which conversation threads form a coherent group. You need both: the phone book to find people, and the social graph to understand relationships.
💡
Key Concept — Application Service In ServiceNow, an Application Service is a CI that represents a running application from end to end — including all the infrastructure CIs that support it and the relationships between them. It's stored in the cmdb_ci_service table. Service Mapping automatically discovers and maintains Application Services.
Section 2

The Three Service Mapping Approaches

ServiceNow offers three approaches to Service Mapping, each suited to different starting points and environments.

1. Top-Down Discovery (Entry Point Approach)

You tell Service Mapping: "Start from this entry point (a URL, load balancer IP, or specific server) and follow the connections outward to discover everything this service touches."

How it works:

  1. You define the entry point: "https://banking.yourcompany.com"
  2. Service Mapping connects to the web server at that URL
  3. It reads the web server's active connections and processes
  4. It follows each connection to the next tier (app servers, databases)
  5. It continues following connections until there are no more to follow
  6. The result is a map of all CIs involved in delivering that service

This is the most powerful approach and builds the most accurate maps. It requires credentials to connect to each tier.

2. Bottom-Up Discovery (CI-Centric Approach)

Instead of starting from a URL, you start from a specific CI and ask: "What services use this CI?" Service Mapping looks at a known CI (e.g., a database server) and traces which application servers connect to it.

When to use: You already know certain CIs are critical and want to understand all services that depend on them. Useful for existing CIs discovered by Discovery or imported via SGC.

3. Traffic-Based Discovery (Agentless Network Approach)

ServiceNow analyzes actual network traffic (using NetFlow data or SNMP traps from network devices) to infer connections between CIs without needing credentials to connect to each server.

Advantages:

  • Works for CIs where you can't install agents or have credentials
  • Discovers connections that credential-based mapping might miss
  • Can work for legacy or isolated systems

Limitations:

  • Less detailed than credential-based mapping
  • Requires network device data (NetFlow, SNMP)
  • Cannot follow application-level logic — only network connections
Approach Starting Point Credentials Required? Best For
Top-Down URL or entry point IP Yes — for each tier New service mapping; most accurate maps
Bottom-Up Known CI record Yes — for connected CIs Understanding impact on a specific CI
Traffic-Based Network flow data No — uses network data CIs without credentials; supplementary mapping
Section 3

Service Mapping Architecture Components

Service Mapping uses the same MID Server infrastructure as Discovery but adds additional components for tracking application-level connections.

Entry Points

An Entry Point is the starting URL or IP that Service Mapping begins from for top-down mapping. Entry points are configured in the Application Service record. You can have multiple entry points for applications with multiple front-ends (web, API, mobile).

Service Mapping Probes

Service Mapping uses specialized probes that focus on process connections rather than device attributes:

  • Connection probes: Read the network connections table of a server (netstat on Linux, netstat on Windows) to see which processes are connected to which remote addresses
  • Process probes: Identify which application process owns each connection
  • Application probes: Identify the specific application framework (Apache, Nginx, Tomcat, JBoss, etc.) from process data

The Application Service Map

The output of Service Mapping is a visual service map — a diagram showing all CIs involved in the service and the connections between them. The map has tiers:

Load Balancer
Entry point CI
›
Web Servers
Tier 1
›
App Servers
Tier 2
›
Database Server
Tier 3

Each node is a CI record in the CMDB. Each connection is a relationship row in cmdb_rel_ci.

The map is stored as relationships in the cmdb_rel_ci table, with the Application Service CI as the parent that "uses" all component CIs.

Section 4

Service Mapping Discovery — Step by Step

Let's trace a complete top-down Service Mapping run for "Online Banking":

  1. Entry Point configured: Admin defines entry point https://banking.company.com in the Application Service record.
  2. Mapping triggered: Admin clicks "Run Mapping" or the scheduled mapping runs. ServiceNow sends instructions to the MID Server.
  3. MID Server connects to entry point server: MID Server resolves banking.company.com to an IP (say, 10.0.5.10), connects via SSH, and reads the active process connections.
  4. Process connections discovered: netstat shows the web server (Nginx process) has established connections to 10.0.5.20:8080 (the app server) and 10.0.5.30:443 (a payment processing API).
  5. Tier 2 exploration: MID Server follows each discovered connection: connects to 10.0.5.20 (app server), reads its connections, finds 10.0.5.40:1521 (Oracle database).
  6. Tier 3 exploration: MID Server connects to 10.0.5.40 (Oracle DB server), reads its connections. No further outbound connections found — this is the end of the chain.
  7. Map assembled: ServiceNow creates CI records for each discovered component (using IRE) and creates cmdb_rel_ci records linking them under the Application Service.
  8. Application Service updated: The "Online Banking" Application Service CI now has a populated service map: Load Balancer → Nginx Web Server → Tomcat App Server → Oracle DB.
⚠
Exam Key — Service Mapping Creates Relationships, Not Just CIs Service Mapping's primary output is CI relationships in cmdb_rel_ci, not just CI records. Discovery creates CIs. Service Mapping connects them. An exam question might ask: "What does Service Mapping add to the CMDB that standard Discovery does not?" → Answer: Application service relationships (the dependency map).
Section 5

Tag-Based Service Mapping — Cloud-Native Discovery

In cloud environments (AWS, Azure, GCP), infrastructure is ephemeral — servers spin up and down dynamically. Traditional top-down mapping (which starts from a fixed entry point) struggles with this because the entry point changes.

Tag-Based Service Mapping solves this by using cloud resource tags to group CIs into a service automatically.

How it works:

  1. DevOps team tags all AWS resources belonging to "Online Banking" with the tag Service=OnlineBanking
  2. ServiceNow's SGC for AWS pulls all resources and their tags
  3. Tag-Based Service Mapping reads the tags and groups all CIs tagged Service=OnlineBanking into the "Online Banking" Application Service
  4. No connection tracing needed — the tag is the signal

Advantage: Works perfectly in auto-scaling environments where individual servers change constantly, because the tag persists even as individual instances are replaced.

💡
Key Concept — Two Flavors of Service Mapping Classic Service Mapping (top-down, credential-based) is best for on-premise and static cloud environments. Tag-Based Service Mapping is best for modern cloud-native and microservices environments where infrastructure is dynamic. Both produce Application Services in the CMDB — they just use different methods to discover the component CIs.
Section 6

Service Mapping and Discovery — How They Work Together

Service Mapping is not a replacement for Discovery — it builds on top of it. Here's how they complement each other:

  • Discovery creates the CI records. Before Service Mapping can connect "Web Server A" to "Database B," both CIs must exist in the CMDB. Discovery creates them with full infrastructure attributes.
  • Service Mapping creates the service relationships. It reads the running state of the application (live connections, active processes) and maps which CIs are connected right now.
  • Both update the CMDB through IRE. Both Discovery and Service Mapping route their data through IRE — the same Identity and Reconciliation Engine — ensuring consistent deduplication and field precedence rules.
  • Service Mapping enriches existing CI records. When Service Mapping finds that a web server CI (already in CMDB from Discovery) is running Nginx, it may enrich the CI with the Nginx version discovered through the connection-tracing probes.

Service Mapping vs. Discovery — Key Differences

Dimension Discovery Service Mapping
Primary question "What CIs exist and what are their attributes?" "Which CIs work together to deliver this application service?"
Starting point IP range sweep Application entry point (URL/IP) or CI record
Primary output CI records with detailed attributes Application service relationships (dependency map)
Runs on All IP ranges in a schedule Specific application services
Frequency Periodic (daily/weekly full scan) Continuous or scheduled (tracks live connections)
Uses MID Server? Yes Yes
Section 7

Keeping Service Maps Current

A service map that was accurate 6 months ago may not be accurate today — applications change, servers are added or removed, connections shift. Service Mapping provides several mechanisms to keep maps current.

Scheduled Remapping

Each Application Service has a scheduled mapping configuration. Options:

  • Continuous mapping: Service Mapping runs on a short interval (every 15–30 minutes) to catch connection changes quickly
  • Daily/weekly scheduled mapping: For stable applications that don't change frequently
  • Manual run: "Run Mapping Now" button on the Application Service record

CI Retirement and Map Cleanup

When Discovery no longer finds a CI (server decommissioned), that CI's operational_status is set to "Retired" and it's removed from active service maps on the next mapping run. This keeps maps current without manual cleanup.

Map Exceptions

Occasionally Service Mapping discovers connections to CIs that should NOT be in the service map — monitoring agents, backup agents, security scanners. You can define mapping exclusions to prevent specific CIs or connection types from being included in the map.

⚠
Warning — Service Maps Can Include Non-Application Traffic Service Mapping discovers ALL connections from servers, including monitoring agent connections, log shipping connections, backup connections. Without exclusions, your "Online Banking" service map might include your Splunk logging server, Veeam backup server, and Nagios monitoring server — making the map confusing and overcrowded. Configure mapping exclusions for infrastructure services that aren't actually part of the application.
Section 8

Service Mapping Powers Change Impact Analysis

Service Mapping's most important exam use case is change impact analysis. When a change is planned for any CI, ServiceNow can use the service map to automatically identify which Application Services will be affected.

Change Impact Analysis Flow

↓
Trigger
Change Request Created
A technician opens CHG12345: "Reboot DB-PRD-01 for patch on Saturday 2am." The CI DB-PRD-01 is referenced in the Change Request's CI field.
1
Relationship Lookup
ServiceNow Traverses the Service Map
ServiceNow queries cmdb_rel_ci to find all Application Services that DB-PRD-01 is a member of. This is only possible because Service Mapping built those relationships.
2
Impact Identified
Affected Services Found
The relationship query returns three Application Services that include DB-PRD-01 as a component CI: Online Banking, HR Portal, and Payroll Processing.
Online Banking HR Portal Payroll Processing
3
Approver Action
Blast Radius Visible Before Approval
The Change Request's Impact section is automatically populated with all 3 affected services. Change approvers see the full blast radius and can make an informed decision before approving the maintenance window.

Without an accurate service map, this impact analysis returns zero results or incomplete results. A change approver sees "no known impact" and approves — but in reality three critical business services go down.

⚠
Exam Pattern — Service Mapping Enables Accurate Change Impact A common exam scenario: "Change managers report that impact analysis for database maintenance windows consistently misses affected applications. What is the most likely root cause?" Answer: Application services are not mapped — Service Mapping hasn't been run, or the service maps are stale. Without service map relationships, change impact analysis has no data to work from.
Exam Quick Reference

Service Mapping — Key Facts

  • Service Mapping discovers relationships between CIs, not just CI attributes. Discovery finds CIs; Service Mapping connects them.
  • Application Service CI (cmdb_ci_service_auto) = the top-level CI representing an end-to-end business application. Called "Service Instance" in CSDM 5 (Zurich+).
  • Top-Down: Starts from URL/entry point, follows live connections tier by tier. Most accurate. Needs credentials per tier.
  • Bottom-Up: Starts from a known CI, discovers services that depend on it.
  • Traffic-Based: Uses NetFlow/SNMP network data to infer connections. No credentials needed. Less detailed.
  • Tag-Based: Groups cloud resources by tag. Best for dynamic cloud/microservices environments.
  • Output stored as cmdb_rel_ci records. Relationships are the primary artifact, not new CI records.
  • Use Case: Change Impact Analysis. Service maps tell change approvers which business services a maintenance window will affect.
  • Mapping exclusions prevent monitoring/backup agents from cluttering the service map.
  • Both Discovery and Service Mapping route through IRE.

Term Grid

Application Service
A CI in cmdb_ci_service that represents a complete running application, including all supporting CIs and relationships discovered by Service Mapping.
Entry Point
The starting URL or IP address for top-down Service Mapping. Service Mapping begins here and traces outward following live connections.
Top-Down Mapping
Credential-based Service Mapping that starts from an entry point and follows process connections across tiers to build a complete service map.
Tag-Based Service Mapping
Groups cloud resources into Application Services based on resource tags (e.g., Service=OnlineBanking). Best for dynamic cloud environments.
Service Map
Visual and data representation of all CIs and their relationships for a given Application Service. Stored as cmdb_rel_ci records.
Mapping Exclusion
Configuration that prevents specific CIs or connection types (monitoring agents, backup servers) from being included in a service map.
Exam Checkpoint

Practice Questions

Click any question to reveal the answer and explanation.

1. Discovery has successfully created CI records for all servers in the environment. Change impact analysis for server maintenance windows consistently shows zero affected services. What is the most likely cause?
A) Discovery is not routing through IRE
B) Service Mapping has not been configured to create Application Service relationships
C) The Change Management module is not installed
D) Server CIs are in the wrong CMDB table
💡 Change impact analysis requires service relationships, not just CI records.
Answer: B — Discovery creates CI records but doesn't create application service relationships. Change impact analysis depends on service map relationships (cmdb_rel_ci records linking servers to Application Services) to determine which business services are affected by a CI change. Without Service Mapping configured, there are no such relationships, so impact analysis always shows zero.
2. A company uses AWS with auto-scaling groups where web server instances are constantly being created and terminated. Which Service Mapping approach is best suited for this environment?
A) Top-Down mapping starting from the load balancer entry point
B) Tag-Based Service Mapping using AWS resource tags
C) Bottom-Up mapping starting from the database server
D) Traffic-Based mapping using NetFlow data
💡 Individual servers change constantly, but the service tag stays consistent.
Answer: B — In auto-scaling environments, individual server instances are ephemeral (created and deleted constantly). Top-down and bottom-up mapping would need to re-discover entry points constantly. Tag-Based Service Mapping works by grouping all resources with a specific tag (e.g., Service=WebApp) regardless of which individual instances exist — the tag persists even as instances change.
3. What is the primary data artifact that Service Mapping creates in the CMDB, beyond CI records?
A) Import Set rows (sys_import_set_row)
B) CI relationship records (cmdb_rel_ci)
C) Discovery Status records
D) Transform Map configurations
💡 Service Mapping's unique contribution is connections between CIs, not the CIs themselves.
Answer: B — Service Mapping's primary output is CI relationship records in cmdb_rel_ci — these describe which CIs are connected to which, how they relate (uses, depends on, connects to), and under which Application Service. Discovery creates the CI records. Service Mapping creates the relationship records that connect them into a service map.
4. Service Mapping for the "HR Portal" application shows hundreds of CIs including multiple Splunk forwarders, backup agents, and security scanners. This is causing confusion for change managers. What is the correct solution?
A) Delete the Splunk, backup, and security CI records from the CMDB
B) Set the Application Service to discovery status "Retired"
C) Configure mapping exclusions for the infrastructure service connections (Splunk, backup, security)
D) Reduce the Service Mapping scan frequency to weekly
💡 These CIs are real but shouldn't be in this application's service map.
Answer: C — Mapping exclusions allow you to specify CIs or connection types that should not be included in a service map. Splunk forwarders, backup agents, and security scanners are real CIs and should remain in the CMDB — you just don't want them in the HR Portal service map because they're not part of the application's functional delivery. Deleting them (A) is wrong — they're legitimate CIs.
5. Which Service Mapping approach would you use if you need to discover all services that depend on a specific Oracle database server that was just discovered by Discovery?
A) Top-Down mapping — start from the database's IP as an entry point
B) Bottom-Up mapping — start from the Oracle database CI and trace which application servers connect to it
C) Tag-Based mapping — tag the Oracle database CI and let Service Mapping group it
D) Traffic-Based mapping — analyze NetFlow to find all connections to the database
💡 You have a known CI and want to find all services that use it.
Answer: B — Bottom-Up mapping starts from a known CI and discovers which services depend on it. You start from the Oracle database CI and Service Mapping traces inbound connections to find which application servers connect to it, and from those finds which Application Services those app servers belong to. This is exactly the use case for bottom-up — you have a specific CI and want its upstream service dependencies.
Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Service Mapping Quiz 1 / 4

An Application Service called "ERP System" has been mapped by Service Mapping. What is the primary data artifact created in the CMDB that represents the component connections?

💡 Explanation

B is correct. Service Mapping's primary output is CI relationship records in cmdb_rel_ci. These records describe which CIs are connected, how they relate (Uses, Depends on, Runs on), and under which Application Service they operate. Discovery creates the CI records themselves; Service Mapping creates the relationship records that connect them into a service map. Import Set rows (A) are for data staging, not Service Mapping output.

A company uses AWS auto-scaling for its web tier — server instances are constantly created and terminated. Which Service Mapping approach handles this environment best?

💡 Explanation

C is correct. Tag-Based Service Mapping groups cloud resources into an Application Service based on their tags (e.g., Service=WebApp). In auto-scaling environments where individual instances are ephemeral, the tag persists even as instances are replaced. Top-Down (A) would struggle with constantly changing entry points. Traffic-Based (D) doesn't require credentials but lacks application-level detail. Tag-Based is the purpose-built solution for dynamic cloud environments.

Change impact analysis for database maintenance windows consistently shows zero affected services, even though databases support multiple critical applications. What is the most likely root cause?

💡 Explanation

B is correct. Change impact analysis reads cmdb_rel_ci to find which Application Services depend on a given CI. If Service Mapping has never run (or maps are stale), there are no relationship records linking database CIs to Application Services — impact analysis finds nothing. Discovery (C) creates CI records but does not create application service relationships. The fix is to configure and run Service Mapping to build the service dependency map.

Service Mapping for an application is including dozens of Splunk forwarders, backup agents, and security scanners in the service map, making it confusing. What is the correct resolution?

💡 Explanation

C is correct. Mapping exclusions tell Service Mapping to ignore specific CIs or connection types when building the service map. Splunk forwarders, backup agents, and security scanners are real CIs that should remain in the CMDB — they just don't belong in this application's service map. Deleting them (A) would remove legitimate CI records. Reducing frequency (B) doesn't fix which CIs are included. Mapping exclusions are the purpose-built feature for this exact scenario.

Score: 0 / 4
← Patterns, Probes & Credentials Agent Client Collector →