Quick Start Guide for Service Mapping

[Syed Kazmi]

If you're just starting your Service Mapping journey, you've come to the right place. This guide will help you get up to speed on activating and realizing value from Service Mapping and is a great place to come back to as our products evolve over time.

Let's get started!

Overview

Here's an overview of the topics we will cover in the guide:

• Service Mapping overview
• What are the business outcomes you can expect
• Four main mapping approaches
• Which approach should you choose
• What to know before getting started
• Steps to quick success
• Other helpful resources

Service Mapping Overview

Service Mapping maps application services in your organization and builds a comprehensive map of the devices, applications, and configuration profiles used in these application services. It provides visibility into the IT infrastructure that makes up your application services, enabling you to identify the underlying causes of issues and reliably evaluate the business and service impacts of planned infrastructure changes.

Service Mapping creates accurate, automatically-updating maps stored in the ServiceNow Configuration Management Database (CMDB) that show dependencies and relationships between components for faster incident resolution, improved change routing, and end-to-end visibility across your IT environment.

What are the business outcomes you can expect from Service Mapping

Before you start to implement Service Mapping, it's critical to have a clear vision of what you want to accomplish. Service Mapping allows you to deliver several positive business outcomes, and you can achieve all this over time. However, by deciding which outcomes are most important for your organization and agreeing on them with your stakeholders, you can set clear expectations and tailor your initial implementation to realize these goals.

Service Mapping benefits:

• Reduce mean-time-to-resolve for incidents by quickly identifying root causes through dependency visualization and understanding service impact
• Improve change and incident routing by understanding which services are affected by infrastructure failures and which IT components deliver specific services
• Reduce risk and enable impact analysis of change by validating planned changes against your services and assessing business impact before implementation
• Prioritize high-impact and critical business services by focusing on services that matter most to your organization
• Enable automation across incident, problem, and change management processes with accurate service maps
• Achieve end-to-end visibility that bridges the gap between business services consumed by users and the technology services operated by IT
• Create a service-centric CMDB that provides an automated and accurate foundation for ITSM and ITOM processes

Four Main Mapping Approaches

Service Mapping offers four primary approaches to map your services. We recommend starting with the modern, automated approaches that deliver faster tie to value:

1. Tag-Based Service Mapping (Recommended)

Best for: Cloud-native applications, containerized workloads, and virtual machine environments

Why choose this approach:

• Fastest time to value - Map multiple application services quickly by leveraging existing cloud tags
• No additional credentials needed - Uses tags already discovered by cloud discovery
• Automatic updates - Services update automatically when tagged resources change
• Scales effortlessly - Perfect for dynamic cloud environments with frequent changes

Ideal use cases:

• AWS, Azure, GCP, OCI, Alibaba or IBM Cloud environments
• VMware vCenter virtual machines
• Nutanix hyperconverged infrastructure
• Any environment with an existing tagging strategy

2. ML-Based Service Mapping (Recommended)

Best for: Homegrown applications, custom applications, and COTS applications. Service Fingerprints (available via ITOM Content Services) enrich process groups with normalized publisher and product taxonomy, making it easier to identify which COTS application is represented in a suggested candidate.

Why choose this approach:

• Intelligent automation - Machine learning analyzes your CMDB data to automatically suggest service maps
• Single-click creation - Preview and create service maps with one click
• No entry points needed upfront - ML clustering automatically identifies services and calculates entry points
• Faster than Top-Down - Eliminates manual pattern creation for custom applications

Ideal use cases:

• Custom-built internal applications
• Commercial applications using non-standard ports
• Any application with running processes and network connections
• Environments where you want to quickly identify service candidates

Two ML approaches available:

• Application Fingerprinting + Process Connections - Analyzes running processes and network traffic
• CMDB-Based Mapping (Xanadu+) - Uses existing CMDB data from any source without requiring MID Server access

3. Top-Down Service Mapping

Best for: Legacy mission-critical on-premise applications requiring precise, granular mapping

Why use this approach:

• Precise mapping - Detailed, component-level relationship discovery
• Mature pattern library - Pre-built patterns for common commercial applications
• Granular control - Fine-tune discovery for complex architectures

Ideal use cases:

• Legacy on-premise applications
• COTS applications requiring granular component-level mapping beyond what ML-Based provides (e.g., Oracle, SAP with complex multi-tier architectures)
• Applications requiring detailed component relationships
• Environments where you need surgical precision in mapping

Note: This approach requires more effort (credentials, pattern customization, error resolution) and takes longer to implement than Tag-Based or ML-Based approaches.

4. Kubernetes Service Mapping via Kubernetes Visibility Agent (KVA)

Best for: Containerized workloads running in Kubernetes and OpenShift clusters, on-premises or in the cloud (EKS, AKS, GKE, OKE, Red Hat OpenShift, Rancher)

Why choose this approach:

• Purpose-built for Kubernetes - An agent (Informer pod) deploys directly inside each cluster, connecting to the Kubernetes API server to receive events in near real-time rather than polling on a schedule
• Comprehensive K8s resource discovery - Discovers namespaces, nodes, deployments, StatefulSets, DaemonSets, ReplicaSets, jobs, CronJobs, pods, services, Docker containers, images, and container repositories
• Dual service mapping support - Supports both Tag-based and Traffic-based (connection-based) Service Mapping for workloads running inside the cluster
• No MID Server credential scanning required - KVA uses a Kubernetes secret and ServiceNow Table API to push data directly; no host credentials or network scanning needed

Ideal use cases:

• Any Kubernetes cluster: Amazon EKS, Google GKE, Azure AKS, Oracle OKE, Red Hat OpenShift, Rancher, or on-premises clusters
• Environments where containerized workloads are highly dynamic (pods spin up/down frequently) and standard Discovery schedules would miss changes
• Organizations running microservices architectures who need full topology visibility from cluster to pod to container

Which Approach Should You Choose

Your Environment	Recommended Approach	Why
Cloud-native with tagging	Tag-Based	Fastest, leverages existing tags, automatic updates
Containers (OpenShift)	Kubernetes Visibility Agent (KVA)	Deploys an agent directly in the cluster for near real-time CMDB updates; recommended approach for Kubernetes/OpenShift environments
Homegrown applications	ML-Based (Automated Service Suggestions)	No patterns needed, intelligent automation
Mixed environments	Choose the best approach for each service based on its characteristics	Cover 80% of services quickly, then add precision mapping
Legacy on-premise only	Top-Down	Most precise for traditional infrastructure

Leading Practice: Most organizations succeed by starting with Tag-Based and ML-Based approaches to map 70-80% of services quickly, then using Top-Down mapping only for specific legacy applications that require it.

Before Getting Started

Since Service Mapping builds on ServiceNow Discovery to add business context to your infrastructure data, it is important to keep the following in mind:

Topic	Considerations
Licensing	Service Mapping is available under the ITOM Visibility subscription or any bundle that includes ITOM Visibility. Work with your ServiceNow account team to activate the Service Mapping plugin (com.snc.service-mapping) in your instance.
Discovery Prerequisite	ServiceNow Discovery must be activated, configured, and operational before starting Service Mapping. For Tag-Based mapping, ensure cloud discovery is running. For ML-Based mapping, ensure Discovery is discovering hosts, running processes, and TCP connections. For Top-Down mapping, ensure horizontal discovery is operational with validated MID Servers.
MID Server Requirements	For Tag-Based: MID Servers needed only for cloud discovery. For ML-Based: MID Servers needed for host discovery. For Top-Down: At least two MID Servers required in production for high-availability configuration and failover. Minimum requirements: Windows Server 2012+ or Linux (RedHat 6+, Ubuntu 14+), 8GB memory, 40GB storage, quad-core processor.
Credentials Configuration	For Tag-Based: Cloud provider credentials only (AWS, Azure, GCP, OCI, IBM Cloud) - no host credentials needed. For ML-Based: Host credentials for running process discovery. For Top-Down: Comprehensive credentials required including Windows local admin, SSH with sudo, SNMP, VMware, storage, and application credentials.
Cloud Tagging Strategy	For Tag-Based: Essential prerequisite. Review and normalize your cloud tagging strategy before starting. Ensure consistent tag keys across environments. Common tags include: Application, Environment, Owner, Cost Center. Use Tag Governance to maintain tag quality.
CMDB Readiness	Ensure Discovery is populating CMDB with CIs. For ML-Based mapping, ensure running processes and TCP connection data are being collected. For Tag-Based mapping, ensure cloud resources and their tags are being discovered. Review CMDB data quality and clean up duplicates.
User Roles	Assign appropriate roles: sm_admin (Service Mapping Administrator - setup and maintenance), sm_user (view maps for operational services), sm_app_owner (IT Application Service Owner - review and approve services). For Tag-Based and ML-Based approaches, minimal additional roles needed compared to Top-Down.
Resource Requirements	For Tag-Based & ML-Based: Part-time Service Mapping Administrator can manage ongoing operations. For Top-Down: Full-time administrator typically required for enterprise implementations. Resource should understand cloud tagging (for Tag-Based) or have application architecture knowledge (for ML-Based).
Training Requirements	Required: Service Mapping Administrator completes Service Mapping Fundamentals training. Recommended: Discovery Fundamentals for understanding how Discovery populates CMDB.
Key Resources	Identify and engage: Executive Sponsor, Project Manager, Application Owners (identify services to map, review and approve service maps), Cloud/DevOps SMEs (for Tag-Based - provide tagging strategy), Application Architects (for ML-Based - confirm connections), and Service/Process Owners (use maps within processes).

Steps to quick success

Step 1: Learn about Service Mapping

Learn about Service Mapping via our product documentation. Focus on understanding how Tag-Based and ML-Based approaches can help you achieve faster time to value with less manual effort than traditional Top-Down methods.

Step 2: Complete Prerequisites

For Tag-Based Service Mapping:

• Ensure cloud discovery is running (AWS, Azure, GCP, IBM Cloud, Kubernetes, VMware)
• Verify cloud resources and tags are being discovered and stored in [cmdb_key_value] table
• Review your organization's tagging strategy - identify tag keys used for applications, environments, owners
• Consider implementing Tag Governance to maintain tag quality

For ML-Based Service Mapping:

• Ensure Discovery is discovering hosts with running processes
• Verify TCP connection data is being collected (netstat data)
• Check that Application Fingerprinting is identifying applications
• Install Service Mapping Plus plugin (sn_sm_scoped_app) for Automated Service Suggestions
• Ensure Predictive Intelligence is installed and enabled in your instance (required dependency for ML-based service mapping; Application Fingerprinting and Connection Suggestion training jobs rely on Predictive Intelligence ML solutions)

For Top-Down Service Mapping (if needed):

• Build and validate MID Servers
• Gather comprehensive credentials for known device types
• Ensure horizontal discovery is operational

Step 3: Activate Service Mapping and Install Required Plugins

Work with your ServiceNow account team to activate the Service Mapping plugin (com.snc.service-mapping).

Essential plugins for modern approaches:

• Service Mapping Plus (sn_sm_scoped_app) - Required for ML-Based Automated Service Suggestions
• Discovery and Service Mapping Patterns - Download latest from ServiceNow Store
• CMDB CI Class Models - Download latest from ServiceNow Store

Optional plugins:

• Tag Governance - Highly recommended for Tag-Based mapping to maintain tag quality
• Performance Analytics Content Pack - Service Mapping - For service mapping metrics
• Event Management and Service Mapping Core - For service monitoring integration

Step 4: Select Services to Map

Identify your most critical application services to map first. Start with 1 to 3 services to prove value quickly.

• For Tag-Based approach: Identify cloud-native services with consistent tagging
• For ML-Based approach: Identify homegrown or custom applications with clear running processes
• For Top-Down approach: Identify legacy on-premise COTS applications

Work with IT Application Owners to determine critical services. Understand service priorities and which approach best fits each service's characteristics.

Tag-Based Service Mapping: Quick Start (Recommended)

Tag-Based Service Mapping is the fastest and easiest way to map cloud-native services. Follow these steps to get started:

Step 1: Review and Normalize Cloud Tags

1. Analyze discovered tags - Navigate to Configuration > CMDB Key Value to view all tags discovered from your cloud environments
2. Identify tag patterns - Look for tags that represent applications, environments, owners, or other service-related attributes
3. Install Tag Governance and review OOTB tag categories - Tag Governance includes OOTB tag categories with regex logic to match discovered tags. Navigate to Service Mapping Workspace > Tag-Based Mapping > Tag Categories to review OOTB categories and determine if additional custom categories are needed. Analyze where regex logic has matched to validate accuracy before proceeding.
   • Define tag category name (e.g., "Application")
   • Add all tag key variants that represent the same thing (e.g., "app", "application", "app_name", "ApplicationName")
   • This normalizes inconsistent tagging across teams

Example Tag Categories:

• Application: app (id), application (id), app_name, app_code, service_name
• Environment: env, environment, stage, tier
• Owner: owner, team, business_unit, cost_center

Step 2: Define Tag-Based Service Families

1. Navigate to Service Mapping > Tag-Based Mapping > Tag-Based Service Families
2. Click New to create a service family
3. Name your service family (e.g., "Production Applications")
4. Select tag categories that define this service family (e.g., Application + Environment)
5. Optional: Define specific tag values if needed to further filter services
6. Save the service family

What happens: ServiceNow will automatically identify all combinations of your selected tags and create service candidates.

Step 3: Create Service Maps from Candidates

1. Navigate to Service Mapping > Tag-Based Mapping > Service Candidates
2. Review the list of automatically identified service candidates
3. Select services to create - Choose candidates that represent real application services
4. Click "Create Services" - ServiceNow creates application service records with the tagged CI as the entry point
5. Service maps are automatically built based on traversal rules that determine parent-child relationships

Example: If you have cloud VMs tagged with "Application: OrderPortal" and "Environment: Production", ServiceNow creates a service candidate named "OrderPortal-Production" containing all VMs with those tags.

Step 4: Monitor and Maintain Tag-Based Services

1. Set Operational Status to "Operational" to activate monitoring
2. Service maps update automatically - Daily scheduled job recalculates services based on current tags
3. New tagged resources automatically added - When new cloud resources are discovered with matching tags, they're added to appropriate services
4. Monitor via Application Service Dashboard - Track service health and completeness

Leading Practice: Use Tag Governance to ensure teams maintain consistent tagging. Inconsistent tags lead to incomplete or fragmented service maps.

ML-Based Service Mapping: Quick Start (Recommended)

ML-Based Service Mapping uses machine learning to automatically identify services from your CMDB data. This is the fastest approach for homegrown applications:

Step 1: Run Service Mapping Readiness Check

1. Navigate to  Workspaces >Service Mapping > Application Service Readiness Dashboard
2. Click Check Readiness to validate prerequisites for ML-based mapping
3. The system checks:
   • Discovery is collecting running processes
   • TCP connection data is available
   • Application Fingerprinting is identifying applications
   • ML clustering capability is ready
4. Address any gaps before proceeding

Step 2: Review Application Service Candidates

1. Navigate to Workspace > Service Mapping > Application Service Candidates
2. Review ML-generated suggestions - Machine learning has analyzed your infrastructure and identified potential services
3. Preview each candidate:
   • Click on a candidate to see suggested service name (based on entry point header)
   • View number of resources ML identified to include (high-confidence connections)
   • Review the service map suggested candidate with the service owner before creating

What the ML does:

• Analyzes running processes and application fingerprints
• Examines network connections between applications
• Uses clustering algorithms to group related components
• Automatically calculates entry points for each service

Step 3: Create Application Services with One Click

1. From Application Service Candidates, select a candidate
2. Click Create Application Service
3. Provide basic information:
   • Service name (pre-populated by ML, can customize)
   • Service owner (IT Application Owner)
   • Application service group
4. Click Create - ServiceNow:
   • Creates the application service record
   • Automatically calculates and adds entry points
   • Creates a local connection rule for this service
   • Adds all high-confidence ML connections automatically

Step 4: Review Connection Suggestions and Discover

1. After initial creation, run discovery on the new service
2. Navigate to Service Map > Actions > Connection Suggestions
3. Review connection suggestions:
   • High-confidence connections already added automatically (marked "Added by rule")
   • Medium-confidence connections available for review
   • Select additional connections to add manually
4. Run discovery again after adding connections - map expands with new components
5. Connection rules automatically maintain the map - New connections matching criteria are added automatically

CMDB-Based Mapping Option (Xanadu+):

• If you have Service Graph Connectors or other CMDB data sources
• Enable system property: sa.topdown.enable_cmdb_based_mapping
• ML analyzes CMDB data to suggest services without requiring MID Server access
• Create service maps instantly from any CMDB source with running process and traffic data

Step 5: Activate and Monitor ML-Based Services

1. Send service for review to IT Application Owner (sm_app_owner)
2. Owner reviews and approves the service map
3. Set Operational Status to "Operational"
4. Connection rules continue to maintain the map - As new connections appear that match your rules, they're automatically added
5. Fine-tune connection rules - Adjust rules to add or exclude specific connection types

Top-Down Service Mapping: Quick Start (When You Need It)

Top-Down Service Mapping is usually the most complete and comprehensive method when it comes to on-premise and complex commercial applications that require high levels of granular, component-level relationship details. Consider Top-Down mapping when:

• You have legacy on-premise applications requiring surgical precision
• Commercial applications (Oracle, SAP, etc.) with complex architectures
• You need granular, component-level relationship mapping
• Tag-Based and ML-Based approaches don't provide sufficient detail

For Top-Down mapping guidance, see the full Service Mapping documentation which includes:

• Entry point configuration (URLs, TCP ports, database connections)
• Pattern customization and debugging
• Bulk error remediation
• Detailed credential requirements

Note: Top-Down mapping requires significantly more effort including comprehensive credentials, MID Server configuration, and extensive error handling. We recommend exhausting Tag-Based and ML-Based options first.

Step 1: Identify Entry Points

Entry points define where Service Mapping begins discovery for your application service.

1. Determine entry point type based on your application:

• URL-based entry points - For web applications (HTTP/HTTPS)
• TCP-based entry points - For applications accessible via specific TCP ports
• Database entry points - For database applications

2. Gather entry point details:

• For URLs: Full application URL (e.g., https://hr-portal.company.com)
• For TCP: IP address and port number (e.g., 10.1.1.50:8080)
• For databases: Database name, instance, and connection details

3. Verify connectivity:
   • Ensure MID Server can reach the entry point
   • Validate network access and firewall rules

Step 2: Select Application Pattern

ServiceNow provides extensive pre-built patterns for common applications.

1. Navigate to Service Mapping > Patterns
2. Search for patterns matching your application:

• Oracle (E-Business Suite, Database, WebLogic)
• SAP (ERP, HANA, NetWeaver)
• Microsoft (SQL Server, IIS, SharePoint)
• Java applications (Tomcat, JBoss, WebSphere)
• Custom applications (Generic patterns)

3. Review pattern description to verify it matches your application architecture
4. Note any specific credential requirements for the selected pattern

Step 3: Create Application Service

1. Navigate to Service Mapping > Services > Application Services
2. Click New to create a new application service
3. Provide service details:
   • Name: Descriptive name for your application service
   • Service owner: IT Application Owner (sm_app_owner role)
   • Operational status: Leave as "Development" during initial creation
   • Application service group: Logical grouping (optional)

4. Save the record

Step 4: Configure Entry Point

1. In the Application Service record, navigate to the **Entry Points** related list
2. Click New to add an entry point
3. Configure based on entry point type:

   For URL Entry Points:

• Type: URL
• URL: Full application URL
• Select pattern: Choose appropriate pattern from library

   For TCP Entry Points:

• Type: TCP
• IP Address: Target server IP
• Port: Application port number
• Select pattern: Choose appropriate pattern

For Database Entry Points:

• Type: Database
• Provide database connection details
• Select database pattern

4. **Save** the entry point configuration

Step 5: Run Service Mapping Discovery

1. From the Application Service record, click **Actions > Discover**
2. Select the MID Server to use for discovery
3. Start discovery and monitor progress:

• Navigate to Service Mapping > Discovery Status
• Watch for the discovery run to complete
• Review any errors or warnings in the discovery log

4. After discovery completes, view the service map:

• Click **View Map** from the Application Service record
• Review discovered configuration items (CIs)
• Verify relationships between components

Step 6: Review and Refine

1. Validate discovery results:

• Verify all expected application components were discovered
• Check for missing CIs that should be included
• Identify any unexpected CIs that should be excluded

2. Address discovery errors:

• Review error messages in discovery log
• Common issues:
• Credential failures - verify credentials and permissions
• Network connectivity - verify MID Server can reach targets
• Pattern mismatches - verify correct pattern for your application version

3. Add manual dependencies if needed:

• Some relationships may not be discovered automatically
• Use **Add Manual Dependency** to include known relationships

4. Re-run discovery:

• After addressing issues, run discovery again
• Service map automatically updates with new findings

Step 7: Send for Review and Approval

Once discovery is complete and the map is accurate, send it for review and approval by following the steps in the Review and Approval Process section of the guide.

Kubernetes Service Mapping: Quick Start 

The Kubernetes Visibility Agent (KVA) deploys an Informer pod directly inside each Kubernetes cluster, providing near real-time CMDB updates and supporting both Tag-based and Traffic-based Service Mapping. Follow these steps to get started. See also: Kubernetes Visibility Agent documentation.

Step 1: Install the Kubernetes Visibility Agent

1. Download Kubernetes Visibility Agent from the ServiceNow Store and install it on your instance
2. Create a ServiceNow user with at minimum the discovery_admin and mid_server roles. This user’s credentials will be used by the Informer pod to connect to your instance
3. In the Kubernetes cluster, create a dedicated namespace for the agent, for example:

kubectl create namespace k8s-informer

4. Create a Kubernetes secret containing the ServiceNow instance credentials:

kubectl create secret generic k8s-informer-cred-INSTANCE_NAME --from-literal=.user=USERNAME --from-literal=.password=PASSWORD -n NAMESPACE

5. Deploy the Informer pod using Helm (recommended) or the Kubernetes YAML file. For Helm:

helm install -n NAMESPACE --set acceptEula=Y \

  --set instance.name=INSTANCE_NAME \

  --set clusterName="CLUSTER_NAME" k8s-informer HELM_URL

The latest Helm URL is available in KB1564347 on the Now Support portal.

What happens: The Informer pod connects to the Kubernetes API server and begins streaming cluster events (pod creation, deletion, and updates) to your ServiceNow instance via the ECC Queue. CMDB tables for K8s resources — clusters, namespaces, nodes, deployments, pods, and services — populate in near real-time.

Step 2: Verify CMDB Population

1. Navigate to Configuration > Kubernetes Clusters to confirm your cluster appears and is populated with nodes, namespaces, and workloads
2. Check the ECC Queue (MID Server > ECC Queue) for any errors in inbound messages from the Informer. Resolve credential or connectivity issues if entries show an error state
3. Repeat for each additional cluster — one Informer pod is required per cluster

Step 3: Create Service Maps Using Tag-Based Mapping

KVA automatically discovers Kubernetes labels on resources and populates them into the CMDB. Once CMDB is populated, use Tag-Based Mapping to build service maps from those labels:

1. Review discovered tags on Kubernetes CIs in the CMDB — look for Kubernetes labels that identify application names, namespaces, or environments (e.g., app, app.kubernetes.io/name, environment)
2. Create tag categories — navigate to Service Mapping Workspace > Tag-Based Mapping > Tag Categories and map your Kubernetes label keys to categories (e.g., map app and app.kubernetes.io/name to an “Application” category)
3. Define Tag-Based Service Families — navigate to Service Mapping Workspace > Tag-Based Mapping > Tag-Based Service Families, click New, and select the tag categories that define a service (e.g., Application + Namespace). ServiceNow generates one service candidate per unique combination of tag values
4. Review service candidates — navigate to Service Mapping Workspace > Tag-Based Mapping > Service Candidates and click Create Services to generate application service records for the K8s workloads you want to map

Step 4: Enable Traffic-Based Mapping (Optional but Recommended)

KVA also collects traffic (connection) data between pods and services, enabling Traffic-based Service Mapping. This adds relationship lines between components, giving you dependency visibility beyond tag-based grouping:

1. Verify traffic collection is enabled in the KVA Helm configuration (enableTrafficCollection: true). See KB1648891 for advanced configuration options
2. Open an existing K8s application service map and navigate to Actions > Connection Suggestions to review traffic-based connections identified by KVA between workloads
3. Accept connections that represent real service dependencies. Connection rules will then automatically maintain these relationships as the cluster changes

Step 5: Send for Review and Approval

Send the service map for review to the IT Application Owner (sm_app_owner role) for approval — see the Review and Approval Process section of the guide.

1. Once approved, set Operational Status to “Operational” to activate the service for change impact analysis, incident routing, and Event Management integration
2. Service maps self-maintain — as KVA streams cluster changes, new pods and services matching your tag categories and connection rules are automatically added or removed from service maps

Leading Practice: Adopt standardized Kubernetes labeling conventions (e.g., the app.kubernetes.io/* recommended labels) across all workloads before deploying KVA. Consistent labels are the foundation of clean, accurate K8s service maps. Work with your DevOps and platform engineering teams to enforce these at deployment time via admission controllers or IaC templates.

Review and Approval Process (All Approaches)

Regardless of which mapping approach you use, all service maps should be reviewed and approved:

Step 1: Review and Approve Service Maps

1. Service Mapping Administrator sends map for review
2. IT Application Service Owner (sm_app_owner role) receives notification
3. Owner reviews the map and verifies:
   • All expected components are included
   • No unexpected or irrelevant CIs are present
   • Connections between CIs are accurate
   • Clusters and inclusions are reflected correctly
4. Owner approves or rejects with feedback
5. If rejected, administrator makes adjustments and resubmits

• For Tag-Based maps: Review typically focuses on tag accuracy and traversal rules
• For ML-Based maps: Review typically focuses on connection accuracy and completeness
• For Top-Down maps: Review typically focuses on comprehensive component discovery

Maps may go through multiple review iterations before approval. Use Organizational Change Management (OCM) to set expectations with Application Owners about review timelines.

Step 2: Activate and Monitor Services

Once approved:

1. Set Operational Status to "Operational" to activate the service
2. Service maps are now available for:
   • Change impact analysis
   • Incident root cause analysis
   • Integration with Event Management for monitoring
   • Dashboard reporting and KPIs
3. Monitor service health via Service Mapping Workspace and Application Service Dashboard
4. Expand iteratively - After success with initial services, map additional services using the appropriate approach

Automatic maintenance:

• Tag-Based services: Update automatically when tags change (daily scheduled job)
• ML-Based services: Connection rules automatically add new matching connections
• Top-Down services: Service re-calculation runs regularly to query CMDB for changes

Other helpful resources

• Service Mapping Overview product documentation
• Service Mapping Best Practices
• Service Mapping Plus for ML capabilities
• Tag-Based Service Mapping complete guide
• Tag Governance for maintaining tag quality
• Service Mapping Resource Page on Now Support
• Quick Start Guide for Discovery
• Quick Start Guide for ITOM Visibility
• Service Mapping Fundamentals training
• ServiceNow Community ITOM articles