Service Mapping Pattern Design

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 application 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. Connection sections exist only in application patterns and run after the identification section. A connection section typically:

1. Reads the running configuration or live network state of the host or application (open sockets, config files, connection strings).
2. 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.
3. 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.

---