CIS-SM Study Guide — ServiceNow Certified Implementation Specialist: Service Mapping

ServiceNow, Service Mapping, Discovery, CMDB, CSDM, Event Management, Now Create, and related product names are trademarks of ServiceNow, Inc. This is an independent, original commercial study aid and is not affiliated with, endorsed by, or sponsored by ServiceNow, Inc. All content is original prose written for exam preparation; verify against official ServiceNow documentation for your specific release.

This guide is organized by exam weight, heaviest domain first. Spend your study time proportionally: the first two domains alone are half the exam.

#	Domain	Weight
1	Service Mapping Pattern Design	30%
2	Service Mapping Configuration	20%
3	Discovery Configuration	15%
5	Configuration Management Database	15%
4	Event Management	10%
6	Service Mapping Engagement Readiness	10%

Domain 1 — Service Mapping Pattern Design (30%)

This is the single largest domain and the area where the CIS-SM exam goes deepest. Pattern design is the engineering core of Service Mapping: it is how you teach the platform to walk from one configuration item (CI) to the next so that an application service map reflects reality.

Why patterns exist

Service Mapping must answer one repeating question at every node in a map: given this host or process, what does it connect to, and what is on the other end? A pattern is the reusable set of instructions that answers that question for a given technology. Patterns replaced the older probe-and-sensor mechanism for most discovery because they are faster, easier to read and modify, and capable of work that probes struggle with — such as tracking configuration files and reaching into public cloud APIs.

Conceptually, a pattern is an ordered series of identification and connection logic that executes on a CI. In horizontal Discovery the pattern fills out the CI's attributes; in Service Mapping the same patterns are reused, but the emphasis is on finding the outbound connections that let mapping continue to the next tier.

The discovery phases and where patterns run

Pattern-based discovery does not replace every stage. Scanning and classification still happen the way they would with probes and sensors. Patterns take over during the identification and exploration phases. After classification identifies what kind of device or application a target is, a pattern probe is launched that names the pattern to run; that pattern then identifies the CI in detail and explores its connections.

Remember the order for the exam: scan → classify → identify (pattern) → explore (pattern).

Pattern Designer

Pattern Designer is the low-code authoring environment for patterns. You build patterns visually as a sequence of steps, each step performing an operation (for example, Parse file, Match, Set parameter value, Create CI, Create connection). Operations read from and write to CI attributes and temporary variables that flow down the pattern as it executes.

Key Pattern Designer concepts to master:

Operations are the atomic actions. You chain them; later steps consume the variables earlier steps populated.
Debug mode lets you run a pattern against a chosen host and inspect, step by step, what each operation produced — the input table, the output table, and any errors. This is the primary troubleshooting tool for "why did mapping stop here?"
Pattern versions allow you to revise a pattern while keeping a stable version in production. You finalize a pattern to make it available to Discovery and Service Mapping.
A pattern is bound to a CI type (table), so the right pattern runs against the right kind of CI.

Connection sections — the heart of mapping

The part of a pattern that makes Service Mapping work is the connection section. Where the identification section figures out what this CI is, the connection section figures out what this CI talks to. A connection section typically:

Reads the running configuration or live network state of the host or application (open sockets, config files, connection strings).
Extracts the endpoints the application connects to — a destination IP/host and port, or a logical name such as a database service name or a downstream URL.
Hands those endpoints back to Service Mapping, which then triggers discovery of the CI on the other end and draws the relationship.

This is the recursive engine of top-down mapping: each connection section yields new endpoints, each endpoint becomes the next tier of the map, and the process repeats until no further outbound connections are found.

Connection sections fed by traffic-based discovery

A connection section can also be fine-tuned using traffic-based discovery. When a pattern's connection logic cannot fully parse how an application connects (custom protocols, opaque middleware), traffic-based discovery observes actual network connections (via OS commands such as netstat/lsof or NetFlow) to supply the endpoints the pattern then validates and maps. The exam expects you to know that traffic-based input complements pattern logic — it is a fallback and a fine-tuning mechanism, not a replacement for a well-written connection section.

Customizing and creating application patterns

You will be tested on the workflow of authoring a pattern for an application that has no out-of-the-box pattern:

Start from the relevant CI type and create a pattern bound to it.
Build the identification section so the CI is correctly recognized and its attributes populated.
Build one or more connection sections to extract outbound endpoints.
Use Debug mode against a representative host to validate each step.
Finalize the pattern so Service Mapping and Discovery can use it.

Know that patterns ship in the Discovery and Service Mapping Patterns application from the ServiceNow Store and are updated independently of the platform release; keeping patterns current is part of pattern design hygiene.

Fast-recall — Domain 1

Pattern = reusable identification + connection logic bound to a CI type.
Phases: scan → classify → identify (pattern) → explore (pattern). Pattern probe launches the pattern.
Pattern Designer = visual steps made of operations over CI attributes/variables.
Connection section finds outbound endpoints → next tier of the map (recursive top-down engine).
Debug mode = step-by-step pattern troubleshooting; finalize to publish; versions for safe revision.
Traffic-based input fine-tunes connection sections; it complements, not replaces, pattern logic.

Domain 2 — Service Mapping Configuration (20%)

This domain covers how you stand up application services and the maps that represent them, and how you steer the mapping process.

Top-down vs. bottom-up

Service Mapping is fundamentally a top-down discovery technique. You begin at the business-visible top of a service — its entry point — and discover downward through every CI the service depends on. This differs from bottom-up (horizontal) Discovery, which scans the network broadly and populates the CMDB without knowing which CIs belong to which service. Top-down produces a precise, service-scoped map; bottom-up produces a broad inventory. Service Mapping reuses the bottom-up patterns but drives them from the top.

Entry points

An entry point is the front door of an application service — the address from which mapping begins. Common entry point types include a URL/web endpoint, a host-and-port, or a load balancer virtual address. Entry point types are extensible: you can create entry point types when an application is reached in a way the out-of-the-box types do not cover. The entry point seeds the map; everything below it is discovered by following connection sections tier by tier.

Application services and service maps

The modern unit Service Mapping produces is the application service (the CSDM-aligned term; older releases called this a business service). An application service map is the visual, navigable graph of the entry point plus every discovered CI and relationship beneath it. You will see references to classic Service Mapping maps — the established top-down, pattern-driven mapping experience — which the exam still treats as core.

Ways to populate an application service:

Pattern-based / top-down — define an entry point, discover downward. Most accurate, fully dependency-aware.
Tag-based — populate the service from cloud or resource tags so that any CI carrying the matching tag is included. Strong fit for dynamic cloud workloads.
Dynamic CI group — define a query; CIs matching the query are members and membership refreshes automatically.
Manual — explicitly add CIs.

Traffic-based discovery as a configuration option

You can enable traffic-based discovery at two scopes: for a specific application service, or for CI types / specific CIs. When enabled, Service Mapping uses observed network traffic to find connections it could not otherwise parse. This is the configuration-side counterpart to the pattern-side connection-section tuning covered in Domain 1.

Steering and maintaining maps

After the first discovery, review the map, then run scheduled rediscovery to keep it current.
Use skip errors to let discovery continue past a failing node so you can map the rest and fix the failure later.
Remove CIs that do not belong to the service to keep the map clean and the impact calculations accurate.

Fast-recall — Domain 2

Service Mapping = top-down from an entry point; bottom-up Discovery = broad CMDB inventory.
Entry point types: URL/web, host:port, load balancer; entry point types are extensible.
Produces an application service (CSDM term) and an application service map.
Populate by: top-down pattern, tag-based, dynamic CI group, or manual.
Enable traffic-based discovery per service or per CI type/CI.
Skip errors to continue; remove non-member CIs to keep maps accurate.

Domain 3 — Discovery Configuration (15%)

Service Mapping rides on the same infrastructure as Discovery, so a CIS-SM candidate must know the Discovery plumbing.

MID Server

The MID Server (Management, Instrumentation, and Discovery) is the Java application, installed inside the customer network, that executes all probes, patterns, and commands on the candidate's behalf and returns results to the instance. For Service Mapping you must:

Configure MID Servers (often in clusters for capacity and high availability) with line-of-sight to the targets being mapped.
Confirm the MID Server has the capabilities and applications assigned for the technologies it will discover.
Know that Service Mapping reads specific MID Server parameters/properties during discovery and mapping; defaults should not be changed unless troubleshooting.

Credentials

Discovery and mapping require credentials stored in the instance credential store (SSH/SNMP for hosts, Windows credentials via PowerShell/WMI, plus application and cloud credentials). Before mapping, verify that every host and application credential needed along a service's dependency chain is present — missing credentials are a leading cause of stalled maps.

Verifying readiness

Use the built-in "verify Service Mapping is set up properly" check before mapping: it confirms MID Servers are configured to discover application services and that host and application credentials are in place. This readiness check is a recurring exam theme — know that it exists and what it validates.

Patterns are shared

The same Discovery and Service Mapping Patterns drive both horizontal Discovery (CI attributes) and top-down Service Mapping (connections). Keep them installed and current from the Store.

Fast-recall — Domain 3

MID Server executes probes/patterns/commands inside the network; deploy in clusters with line-of-sight.
Assign correct capabilities/applications; respect default MID Server parameters unless troubleshooting.
Credentials (SSH/SNMP/Windows/app/cloud) must cover the whole dependency chain.
Run the readiness verification before mapping (checks MID Servers + credentials).
Discovery and Service Mapping share the same pattern set.

Domain 5 — Configuration Management Database (15%)

Service Mapping is both a producer and a consumer of the CMDB, so the exam expects fluency in the data model.

Application services in the CMDB and CSDM

The Common Service Data Model (CSDM) is ServiceNow's standard for organizing service data in the CMDB. Service Mapping populates the application service record (cmdb_ci_service_auto / service tables) and the relationships beneath it. Under CSDM, the application service is the central technical-service construct; it can be associated upward with business-facing services and downward with the CIs that compose it. Knowing how CSDM concepts map to CMDB tables — and that Service Mapping output is meant to populate the technical/application service layer — is a frequent exam target.

CI relationships

Service Mapping's value is the relationships (dependency edges) it creates between CIs. These relationships drive impact analysis, dependency views, and Event Management impact calculations. The relationship direction (depends on / used by) matters for how impact propagates.

Grouping and dynamic membership

CMDB groups collect CIs for management and operations.
Dynamic CI groups define membership by query so the group self-updates as the CMDB changes — the same mechanism that can populate an application service.
Tags (notably from cloud providers) can drive both discovery scope and service membership.

Data quality

Accurate maps require a healthy CMDB: correct CI identification (so CIs are not duplicated), good reconciliation (so the authoritative source wins on each attribute), and clean class assignment. Poor identification produces duplicate or mismatched CIs and broken maps — which is why CMDB health is treated as a prerequisite to a successful Service Mapping deployment.

Fast-recall — Domain 5

Service Mapping populates the application service layer of the CMDB, aligned to CSDM.
Know how CSDM concepts map to CMDB tables; application service is the central technical construct.
The relationships it creates drive impact analysis and dependency views; direction matters.
CMDB groups, dynamic CI groups (query-based, self-updating), and tags organize membership.
CMDB health (identification + reconciliation) is a prerequisite for good maps.

Domain 4 — Event Management (10%)

Service Mapping and Event Management are complementary ITOM capabilities; the exam tests the seam between them.

Why they pair

Event Management ingests events from monitoring tools, deduplicates and correlates them into alerts, and then uses the dependency relationships built by Service Mapping to calculate service impact. Without a map, an alert is just a host problem; with a map, the platform can say which application service is degraded and how the fault propagates upward.

Impact and service health

Alerts are bound to CIs; impact flows up the dependency tree that Service Mapping created, so a database alert can show as impacting the application service that depends on it.
You can view active alerts directly on the application service map, seeing which CIs are affected and how relationships carry the impact.
Event Management can show cross-service impact — how a child service's degradation affects a parent service.
Service health dashboards summarize the operational state of services using this combined data.

Self-health

Event Management includes a self-health application service map so operators can confirm Event Management's own components are healthy.

Fast-recall — Domain 4

Event Management correlates events → alerts; Service Mapping's relationships turn alerts into service impact.
Impact propagates up the dependency tree; view active alerts on the application service map.
Supports cross-service (child→parent) impact and service health views.
A self-health application service map monitors Event Management itself.

Domain 6 — Service Mapping Engagement Readiness (10%)

This domain covers the implementation-consulting side: making sure an organization is ready to deploy Service Mapping successfully, using ServiceNow's delivery methodology.

Now Create and the implementation framework

Now Create is ServiceNow's library of proven methodology, accelerators, and artifacts distilled from many implementations. ServiceNow's adaptive implementation approach moves an engagement through structured phases — broadly Initiate → Prepare → Create → Transition → Close — defining vision and scope first, then design, build, go-live, and post-go-live support.

The Service Mapping readiness checklist

ServiceNow publishes a Service Mapping implementation readiness checklist with the following recurring steps. Expect questions on the intent of each:

Confirm prerequisites — Discovery licensed and working, healthy CMDB, MID Servers and credentials in place.
Define vision, objectives, and success measures — what services, what outcomes, how success is measured.
Assess team readiness — the right roles and skills (Discovery/Service Mapping admin, CMDB owner, app SMEs).
Create a governance structure — who owns the CMDB, who approves service definitions, change control.
Plan organizational change management (OCM) — sponsorship, stakeholder readiness, communications.
Plan for implementation design — which services to map first, prioritization, phased rollout.

Practical readiness themes

CMDB data quality before go-live is non-negotiable: maps are only as good as identification and reconciliation.
Application SMEs are essential — they confirm entry points, expected dependencies, and validate maps.
A phased rollout (start with a few high-value services, prove value, then expand) reduces risk.
Prefer out-of-the-box patterns and content before custom work.

Fast-recall — Domain 6

Now Create = ServiceNow's methodology library; phases ~ Initiate → Prepare → Create → Transition → Close.
Readiness checklist (6): prerequisites, vision/measures, team readiness, governance, OCM, implementation design.
CMDB data quality before go-live is a hard prerequisite.
Engage application SMEs; use phased rollout; favor out-of-the-box content first.

Whole-exam Fast-recall cheat list

Top-down (entry point → downward) is Service Mapping; bottom-up is horizontal Discovery (broad inventory).
Discovery phases under patterns: scan → classify → identify → explore; pattern runs in identify + explore.
Pattern = identification + connection logic, bound to a CI type, authored in Pattern Designer from operations.
Connection section extracts outbound endpoints → next map tier (the recursive engine).
Debug mode = step-through troubleshooting; finalize publishes; versions for safe edits.
Traffic-based discovery (netstat/lsof/NetFlow) complements connection sections; enable per service or per CI/CI type.
Entry point seeds the map; types include URL/web, host:port, load balancer; types are extensible.
Populate application services by top-down pattern, tag-based, dynamic CI group, or manual.
MID Server runs everything in-network; clusters for HA; needs capabilities + credentials + line-of-sight.
Run the Service Mapping readiness verification before mapping.
Output populates the CSDM application service layer; relationships drive impact.
Event Management turns alerts into service impact using Service Mapping relationships; impact flows up the tree.
Now Create + the readiness checklist (prereqs, vision, team, governance, OCM, design) govern engagement readiness.
CMDB data quality (identification + reconciliation) is the foundation of every successful map.

UNVERIFIED items to confirm against your target release's official docs: exact entry-point type list and labels; the precise step list inside the readiness verification UI; current CSDM table names for application vs. business service in your release (terminology shifted from "business service" to "application service" across releases). Treat any release-specific label as release-dependent.