ServiceNow Discovery Integration Patterns

Discovery Inbound Data Flow: Pulling Infrastructure Data

ServiceNow Discovery scans your IT infrastructure (servers, networks, applications, databases) and imports discovered data into the CMDB. The inbound flow is: Scanner (running on MID Server) → Discovery data → ServiceNow CMDB. Discovery connectors scan specific resource types: vmware clusters, AWS accounts, database servers, network devices. Each scanner imports normalized data into ServiceNow Configuration Item tables.

Configure which discovery scanners to enable based on your infrastructure. If you run primarily on AWS, enable AWS discovery. If you have a private data center with vSphere and physical servers, enable vSphere and network discovery. Each scanner has configuration requirements: AWS scanner needs IAM credentials; vSphere scanner needs vCenter authentication; network scanner needs SNMP read credentials.

Ownership question: Who is responsible for keeping discovery credentials current? If AWS access keys or vCenter passwords change, discovery will fail silently until an audit catches the failure. Assign discovery credential maintenance to the infrastructure team and implement alerting in ServiceNow if discovery runs fail.

Outbound Data Exports: Syncing CMDB Data to External Systems

Some organizations maintain external inventory systems (Atlassian Jira Service Management, BMC tools, Excel spreadsheets) that must stay synchronized with the ServiceNow CMDB. Outbound data flow is: ServiceNow CMDB → Integration → External system. Common outbound patterns: CMDB to configuration management systems, CMDB to spreadsheet exports, CMDB to reporting tools.

For outbound exports, define which CMDB tables and fields to sync, and how frequently. A nightly export might sync all servers and key attributes (hostname, IP address, OS, owner) to a Jira Service Management account. An hourly export might sync hardware asset data to an asset tracking system. Define the schedule based on how current the external system must be.

Error handling in outbound exports: What happens if the export fails? Set up alerts so the integration team knows about failures. Implement retry logic: exponential backoff for transient failures, escalation for persistent failures. Monitor export volumes: if export record counts diverge from expected counts, investigate data quality issues.

Bi-Directional Sync: Keeping Data Current Across Systems

Bi-directional sync maintains consistency between ServiceNow and external systems. When ServiceNow data changes, external systems are updated; when external systems change, ServiceNow is updated. This pattern is complex but essential for organizations with multiple tools responsible for different aspects of the same data.

For example, the hardware asset lifecycle might be managed in a procurement system, but asset location and ownership are managed in ServiceNow. Bi-directional sync keeps both systems current: procurement system sends serial numbers and acquisition dates; ServiceNow sends location and owner changes back. Without synchronization, the data diverges, creating confusion and errors.

Challenges with bi-directional sync: conflict resolution (if both systems modify the same field simultaneously, which takes precedence?), data mapping (how do field names and values differ between systems?), and performance (sync logic must be efficient). Start with one data direction (inbound or outbound); add bi-directional sync only if justified by business need.

Error Handling and Data Quality Assurance

Integration failures are inevitable. A scanner loses network connectivity, an external API times out, or data validation fails. Integrations benefit from solid error handling: detect failures, log details, alert the appropriate team, and retry intelligently. Configure error handling in ServiceNow Integration Hub: define retry strategies, set escalation thresholds (if 3 retries fail, escalate), and implement compensation (rollback or manual intervention).

Data quality is critical in both directions. If Discovery imports invalid data (e.g., malformed IP addresses, null required fields), CMDB quality suffers. Implement data validation before import: check field lengths, validate IP address format, ensure required fields are present. For outbound exports, validate that data mapping is correct and that external system expectations are met.

Audit data quality regularly. Compare record counts: if a previous export had 500 servers and today’s export has 450, investigate why servers are missing. Are they deleted legitimately? Was the discovery scan incomplete? Run reconciliation reports monthly to catch discrepancies early.

Scalability and Performance Considerations

As your infrastructure grows, integration scalability becomes important. If Discovery scans 10,000 servers and imports all data nightly, the import job must complete in a maintenance window without impacting production ServiceNow users. Large imports consume CPU and memory; schedule them during off-peak hours.

For large-scale integrations, consider incremental sync: instead of exporting all CMDB data every time, export only changed records. ServiceNow tracks change logs; use them to identify updated records since the last export. Incremental sync reduces network bandwidth, reduces external system update burden, and completes faster.

Monitor integration performance: track job execution times, error rates, and resource utilization. If a nightly export is taking longer as data volume increases, optimize the integration (use filters to reduce record count, parallelize the export, upgrade hardware) before the job exceeds the maintenance window.

Ownership and Governance of Integrations

Each integration must have clear ownership: Who maintains the integration configuration? Who responds if it fails? Who resolves data quality issues? Assign integration ownership to a team with access to both systems: typically, the platform team owns ServiceNow side, and the infrastructure or external system team owns the other side. Define an escalation path if disagreement arises about data precedence or conflict resolution.

Document integrations: What data is synced? What is the sync schedule? What are error handling procedures? Where are logs stored? Maintain this documentation in a central location (wiki, SharePoint) so teams can reference it and troubleshoot issues. Include contact information for the integration owner and escalation procedures.

Choosing a feed model before choosing a tool

Teams often pick a feed mechanism because a tool they already own supports it, and only later ask what the data actually needs. The result is a pipeline that moves records on a schedule nobody chose, or a real-time flow built for data that changes once a week. The better order is to decide the feed model first: how often the consumer needs the data, what happens when a record changes between two reads, and what the consumer does if a record is missing. Only then choose the mechanism that delivers it.

Three feed models and the consumers they suit

Identifiers that keep records matched across systems

Many feed failures are identity failures. The consumer receives a record, but cannot tell whether it is the same item it already holds under a different name or key. Before any feed goes live, agree which identifier each consumer will use to match records, and what happens when the identifier is missing or changes. A serial number is stable for a physical device but absent for a virtual one. A hostname is readable but reused. A cloud resource identifier is unique but meaningless to a service desk analyst. Write down the rule for each consumer and test it against a set of records that include the awkward cases.

Testing a feed with a small, known slice

1. Choose a slice of records that you can verify by hand, such as one segment with a known count and a few items with known relationships.
2. Send the slice through the feed to the consumer’s test environment, and record the count that arrives against the count that was sent.
3. Check identity: confirm that updated records update the existing consumer record rather than creating a new one.
4. Check deletion: remove one item at the source and confirm the consumer behaves as agreed, whether that is marking it inactive or holding it for review.
5. Force one failure, such as an unavailable endpoint, and confirm the alert reaches the owner named in the feed record.
6. Only then widen the slice, and repeat the count check at each widening.

What a consumer should be told about the feed

Each consumer needs a short statement of what it will receive, how fresh it will be, and what it must not assume. A common gap is a consumer that treats a missing record as deleted, when the feed simply skipped it because its source was unreachable. Make that distinction explicit in the statement, and ask the consumer to report any record that disappears without a matching change at the source. That report is one of the most useful signals the feed has.

When to choose none of these

Some consumers do not need a feed at all. A quarterly audit extract, a one-time migration or a report that runs once a month can read a snapshot. Building a live feed for them adds maintenance cost and failure points without adding value. Write down the decision not to build a feed and its reason, so that the request cannot quietly reappear.

Should every consumer get the same feed?

No. Give each consumer the fields and the frequency it needs. A shared feed carrying everything is harder to test and harder to secure, and it exposes data to consumers that have no use for it.

How do we handle a consumer that writes back to the model?

Treat write-back as a separate design decision with its own owner and its own rules for which fields may change. Without those rules, two systems will take turns overwriting the same attribute.

Where should we look first if a consumer reports wrong data?

Whether the consumer matched the record on the identifier you expected. Many reports of wrong data turn out to be a match on the wrong key, rather than a fault in the record itself.

How often should feed contracts be reviewed?

Whenever a consumer changes the fields it reads, and at the point of any change to the source model. A contract that nobody re-reads becomes a record of what was once agreed rather than what is running.

Who should be told when a feed fails silently?

The consumer owner first, because they are the one acting on stale data, and then the feed owner. Silent failure is a common way a consumer keeps acting on data that stopped updating weeks earlier.

Feed failures are often caught by the same monitoring that tracks integration health, so the guide to integration error handling and the note on monitoring ownership should be read before a feed goes live. The REST integration design guide covers feeds exposed as REST interfaces to other applications.