What are ServiceNow patterns?

Patterns are reusable discovery instructions that tell ServiceNow how to identify configuration items, collect attributes, evaluate conditions, parse technical data, and create relationships. They are used across IT Operations Management to support both infrastructure discovery and application service mapping.

In practical terms, a pattern answers questions such as:

• What type of CI is this?
• Which process, port, registry key, file, command output, API response, or SNMP value proves what it is?
• Which attributes should be populated on the CI?
• Which other CIs does this CI depend on or communicate with?
• When should discovery stop, continue, or branch based on conditions?

Pattern Designer provides the interface for building and maintaining this logic through sections, steps, variables, operations, and debugging tools.

Pattern types

ServiceNow patterns are generally created as either application patterns or infrastructure patterns.

Roles and prerequisites

Before creating or editing a pattern, confirm the following prerequisites are in place:

• The application or infrastructure component has a corresponding CI type.
• The CI type has an appropriate classification.
• The user has the pd_admin role for Pattern Designer activity.
• The MID Server can reach the target host, application, API, or device.
• Required credentials are configured and tested.
• For domain-separated environments, the correct domain is selected.
• The implementer has enough scripting, command-line, or platform knowledge to understand what the pattern is collecting.

High-level pattern build process

A typical pattern build follows this lifecycle:

1. Confirm the target CI type and classification.
2. Create or open a pattern in Pattern Designer > Discovery Patterns.
3. Define the basic pattern attributes.
4. Create one or more identification sections.
5. Add discovery steps to identify the CI and populate attributes.
6. For Service Mapping, add connection sections to discover outbound relationships.
7. Use variables to pass values between steps.
8. Use Debug mode to test each step.
9. Activate the pattern.
10. Synchronise the pattern to the MID Server.
11. Run Discovery or Service Mapping and validate the resulting CIs and relationships.

Create or customise a pattern

To create or modify a pattern:

1. Navigate to All > Pattern Designer > Discovery Patterns.
2. Select New, or open an existing pattern.
3. On the Basic tab, define the key attributes.
4. Save the pattern.
5. Create identification sections for incoming entry points.
6. Define discovery steps for each section.
7. For application patterns used by Service Mapping, create connection sections where outbound dependencies need to be discovered.
8. Activate the pattern when testing is complete.
9. Run Pattern Sync to MID so MID Servers receive the latest pattern version.

Basic pattern attributes

Identification sections

An identification section contains the logic used to recognise a CI from an incoming connection or entry point. A pattern can have multiple identification sections when different entry point types or discovery routes are possible.

Design guidance

• Use separate identification sections for materially different entry point types.
• Keep the section name descriptive, for example Identification for HTTPS TCP.
• Place the most reliable identification logic earlier in the run order.
• Avoid broad matching logic that could identify the wrong CI type.

Discovery steps

Discovery steps are the building blocks of a pattern. Each step performs an operation. The operation determines which fields, variables, parsing rules, or conditions must be configured.

Add a discovery step

1. Open the relevant pattern.
2. Select the required identification section or connection section.
3. Add a step above or below the current step.
4. Select an operation from the operation list.
5. Complete the operation-specific fields.
6. Use comments to explain complex logic.
7. Use Debug mode to test the result.
8. Save the section and pattern.

Common step settings

Pattern operations reference

The table below summarises common Pattern Designer operations and when to use them.

Working with variables

Variables are used to pass values between steps, populate CI attributes, store command output, and build relationships. Pattern Designer uses several variable types.

Variable syntax examples

Important: Avoid hard-coded paths where possible. Use discovered variables or parsed values so the pattern works across hosts with different installation locations.

Using Debug mode

Debug mode allows you to test pattern logic as you build it. This is one of the most important tools in Pattern Designer because it shows whether each operation returns the expected data before the pattern is activated.

Debug mode can help you:

• Run individual pattern steps.
• Browse processes, files, or registry entries where supported.
• Run commands against the target host or MID Server.
• Populate and inspect temporary variables.
• Validate parsing logic.
• Confirm that preconditions and Match operations behave as expected.

Activate Debug mode

1. Open the pattern section you want to test.
2. Select Debug Mode.
3. Optionally select a MID Server for the session.
4. Select the debug type:
   • Top down for Service Mapping behaviour.
   • Horizontal for Discovery behaviour.
5. Select the entry point type.
6. Enter the required entry point values, such as URL, host name, or IP address.
7. Select Connect.
8. Run Test on each step and review the temporary variables.

Make a step conditional

Preconditions control whether a step should run. Use them to prevent unnecessary processing, avoid false matches, and make a pattern more resilient across different host configurations.

Example use cases

• Only parse a file if the file path variable is not empty.
• Only run a Unix command when the host OS is Linux or Unix.
• Only create a relationship when both parent and child values exist.
• Only run a connection step in top-down discovery mode.

Configure a precondition

1. Select the step.
2. Enable Precondition.
3. Enter the first value, such as a variable or string.
4. Select an operator.
5. Enter the second value where required.
6. Add additional conditions if needed.
7. Choose whether All or Any conditions must match.
8. Choose whether the condition must evaluate to True or False.

Connection sections for Service Mapping

Connection sections are used by Service Mapping to discover outbound dependencies from an application CI. A CI can have multiple outgoing connection types, so create a separate connection section for each meaningful connection type.

Examples of connection sections include:

• Database connections
• Message queue connections
• Web service calls
• Cluster relationships
• Storage flows
• Included child components such as websites or deployed application artefacts

Create a connection section

1. Open an application pattern.
2. In the Connectivity Section, select New.
3. Enter a meaningful section name.
4. Save the pattern.
5. Open the connection section.
6. Start with a Create Connection operation.
7. Define the connection type, entry point, attributes, target CI type, and any hidden or traffic-based settings.

Creating relationships and references

Use the Create Relation/Reference operation when a pattern needs to create relationships or references between CIs discovered within the pattern.

Key fields

Tip: Validate the CI class relationship model before creating relationships in a pattern. Incorrect relationship direction can create confusing maps and poor CMDB data quality.

Parsing strategies

Several operations can parse data from commands, files, HTTP responses, variables, scripts, or API calls. Choose the parsing strategy based on the format of the source data.

Parsing best practices

• Test parsing in Debug mode using real command output or file content.
• Name variables clearly so later steps are easy to understand.
• Use Terminate carefully. Only stop discovery when missing results should genuinely halt the pattern.
• Use caching for expensive or repeated calls to reduce load on shared components.
• Prefer robust parsing strategies over fragile string positions where source output may vary.

Operation deep dives

Get Process

Use Get Process to find running processes that identify an application. You can search by command line, working directory, parent process, port, or process ID. The result is stored in a tabular variable that can be used by later steps.

Best practice: Avoid relying only on process ID because it can change. Command line and port-based matching are usually more reliable.

Parse Command Output

Use Parse Command Output to run a command and extract values from the result. This is useful when required data is only available through a command-line utility.

Best practice: Avoid hard-coded file paths in commands. Use variables and discovered installation directories where possible.

Parse File

Use Parse File to extract values from configuration files. This is common for application discovery where ports, endpoints, cluster names, or dependencies are stored in local configuration files.

Best practice: In Debug mode, browse to the target file and validate both the path and the parsing logic.

Match

Use Match to verify that required conditions are met. If the condition is not met, discovery stops. This is useful for avoiding false-positive identification.

Best practice: Where a non-match is expected in some environments, use an expected termination message so the discovery log explains the result clearly.

Filter Table

Use Filter Table to reduce a source table to only the rows that match specific criteria. This is useful when a prior step returns a broad data set and only some rows are relevant to the CI or relationship being discovered.

Merge Table

Use Merge Table to combine data from two tables. You can merge by matching fields or conditions and choose how unmatched values are handled.

SNMP Query

Use SNMP Query for devices that expose management information through SNMP, such as load balancers or network devices. In Debug mode, browse the MIB tree, select scalar values or table columns, and test the query result.

WMI Query and WMI Method Invocation

Use WMI Query to collect data from Windows systems. Use WMI Method Invocation when a method must be executed against a table returned by a previous WMI query.

Best practice: The WMI Method Invocation step should follow the WMI Query step because it depends on the source table produced by that query.

HTTP Get Call and Cloud REST Call

Use HTTP Get Call to retrieve data from HTTP-based CIs. Use Cloud REST Call to query cloud APIs such as AWS or Microsoft Azure. Both operations can parse the response and create variables for later steps.

Best practice: Refer to the vendor API documentation for correct URL, method, body, and header syntax.

Run SSH Script File and Put File

Use Put File to transfer a file from the MID Server to the target host. Use Run SSH Script File to execute composite commands or scripts on Unix-based hosts.

Best practice: Use these operations when built-in commands are not enough or when complex host-side logic must be executed consistently.

Custom operations

Standard operations allow input parameters to be configured, but custom operations allow administrators to define the business logic and mechanism of an operation. This is useful when the discovery process requires a protocol, API, or transformation that is not covered by the base operation set.

When to create a custom operation

• A proprietary system requires a custom query format.
• A vendor API does not fit an existing operation.
• Complex MID Server-side logic needs to be reused across patterns.
• Input parameters need custom validation.

Custom operation design notes

• Create parameters using a dollar sign prefix, such as $fileName.
• Use the execution context object to access information from pattern execution.
• Return operation results using the expected return variable.
• Define operation parameters in the related list after writing the script.
• Use validation regex where parameter input must conform to a required format.

Testing and validation checklist

Before activating a pattern, validate it with the following checklist:

• Pattern name and description are clear.
• CI type is correct.
• Run order is configured if there is a risk of pattern confusion.
• Identification sections are ordered correctly.
• Entry point types match the expected discovery route.
• Process classification is enabled where appropriate.
• Variables are named consistently and clearly.
• No unnecessary hard-coded paths are used.
• Each step has been tested in Debug mode.
• Preconditions are used to avoid invalid execution paths.
• Match operations stop discovery only when appropriate.
• Parsing strategies are resilient against realistic output variations.
• Relationships and references follow the CMDB relationship model.
• Connection sections create the expected outbound dependencies.
• Credentials work from the selected MID Server.
• The pattern has been activated.
• The updated patterns have been synchronised to MID Servers.

Troubleshooting guide

Recommended implementation approach

For a reliable implementation, build patterns incrementally rather than attempting to configure the full pattern in one pass.

1. Start with identification. Confirm that the pattern correctly recognises the CI.
2. Populate core attributes. Add only the fields needed to uniquely identify and describe the CI.
3. Add parsing logic. Extract additional details from files, commands, APIs, registry keys, or SNMP.
4. Add relationships. Create references and relationships once parent and child values are reliable.
5. Add connections. For Service Mapping, define outbound dependencies after identification is stable.
6. Optimise and harden. Add preconditions, caching, expected terminations, and comments.
7. Validate in multiple environments. Test across hosts with different installation paths, versions, and configurations.

Governance and maintainability

Patterns become part of the operational foundation for CMDB and service visibility. Treat them as maintained technical assets.

Recommended governance practices

• Use a naming convention for custom patterns, sections, steps, and variables.
• Document why each complex step exists.
• Record assumptions about OS, application version, path structure, or API format.
• Keep custom operations to a minimum and reuse them where appropriate.
• Test patterns after upgrades or application version changes.
• Review discovery logs regularly for recurring expected and unexpected terminations.
• Align relationships with the approved CMDB class and relationship model.

Quick reference: what to use when