ServiceNow Discovery is useful only when the data it collects improves the CMDB instead of creating a second stream of noisy infrastructure records. Discovery can scan IP ranges, use MID Servers and credentials, classify devices, run patterns or probes, identify configuration items, and update the CMDB on a schedule. The engineering challenge is making sure those observations land in the correct classes, match existing CIs, respect source authority, create useful relationships, and age out correctly when the underlying environment changes.<\/p>\n
Current ServiceNow Australia documentation continues to position Discovery schedules as the control point for when and how discovery runs. A schedule identifies the target addresses, MID Server or behavior, and discovery type. Current Discovery documentation also states that found devices are compared with CMDB CIs and matching CIs are updated; when no match exists, a CI can be created. That makes identification quality and ingestion governance central to Discovery design, not optional cleanup after the scan.<\/p>\n
Discovery therefore belongs inside ServiceNow Platform Engineering<\/a> as a managed data-source pipeline.<\/p>\n Start with the infrastructure and services the CMDB actually needs to support. Scanning every routable address can produce large volumes of low-value data, credentials failures, transient devices, and classes that no operational process uses.<\/p>\n ServiceNow data foundations<\/a> are strongest when data collection follows an agreed model and business purpose.<\/p>\n Prioritize networks, cloud accounts, device classes, and application infrastructure that participate in incident, change, security, asset, or service-management outcomes.<\/p>\n MID Servers need network reachability, DNS, credentials, and protocol access to the targets they discover.<\/p>\n Place them according to network boundaries, security zones, data centers, and cloud environments so Discovery does not depend on broad firewall openings from one central scanner.<\/p>\n Redundant MID Servers or Discovery behaviors can improve resilience, but ownership and credential distribution should remain explicit.<\/p>\n A schedule defines more than convenience. It determines how quickly the CMDB reflects new, changed, and retired infrastructure.<\/p>\n Fast-changing cloud environments may need more frequent discovery than static appliances or legacy systems.<\/p>\n Scheduling should consider scan duration, target load, maintenance windows, network cost, and the freshness expectations defined for each CI class.<\/p>\n Current Discovery relies heavily on patterns to identify and explore supported infrastructure, while older probes and sensors can still exist in some customer environments.<\/p>\n Use out-of-box patterns where they fit and customize only when the target genuinely requires additional identification or attributes.<\/p>\n Custom discovery logic creates upgrade and support obligations, so every customization should have an owner and a reason beyond \u201cthe source team wanted one more field.\u201d<\/p>\n Discovery data should align with the Identification and Reconciliation Engine instead of becoming a parallel duplicate-creation path.<\/p>\n IRE<\/a> uses identification rules and source data to decide whether the incoming observation updates an existing CI or creates a new record.<\/p>\n Stable identifiers such as cloud IDs, serial numbers, or appropriate compound keys are more durable than friendly names that users can change.<\/p>\n Discovery may be authoritative for operating system, IP, hardware, or software facts while another source owns purchase data, business criticality, support group, or application ownership.<\/p>\n CMDB modeling<\/a> should define which source can update which attributes so Discovery does not overwrite business-managed data simply because it scanned the device most recently.<\/p>\n Reconciliation rules turn this ownership model into enforceable platform behavior.<\/p>\n Discovery adds more value when CIs connect to their infrastructure and service context.<\/p>\n CI relationships<\/a> help incident and change teams understand dependencies, while Service Mapping can extend that graph into application-service context.<\/p>\n Validate discovered relationships against representative services so the topology is neither missing critical dependencies nor overwhelmed by noisy low-value connections.<\/p>\n Credential errors, inaccessible subnets, failed patterns, MID Server health, scan gaps, and sudden record-volume changes can all degrade the CMDB silently.<\/p>\n Track discovery status and source freshness with the same seriousness as application monitoring.<\/p>\n A CMDB that appears healthy because old data is still present can be more dangerous than one that visibly shows the source stopped updating.<\/p>\nDefine the discovery scope first<\/h3>\n
Design MID Server placement around reachability<\/h3>\n
Use schedules that match infrastructure change<\/h3>\n
Prefer supported patterns and classification<\/h3>\n
Let IRE decide whether the CI is new<\/h3>\n
Respect reconciliation authority<\/h3>\n
Build useful relationships, not just records<\/h3>\n
Monitor discovery failures as data-quality failures<\/h3>\n
Connect Discovery to CMDB Health<\/h3>\n