Service Graph Connectors are designed to bring data from external technology systems into ServiceNow in a way that fits the CMDB rather than treating ingestion as a simple import job. A connector may collect rich information from a cloud platform, infrastructure tool, security product, or management system, but the engineering value comes from how that data is transformed, identified, reconciled, and related inside the platform. Successful ingestion creates trustworthy configuration context; unsuccessful ingestion merely creates more records.<\/p>\n
That distinction makes Service Graph Connectors a core topic in ServiceNow platform engineering<\/a>. Connector installation, credentials, schedules, and mappings are operational details, but they sit inside a larger data architecture. The team needs to know which source is authoritative for which attributes, how duplicate CIs are prevented, what happens when sources disagree, and how connector failures are detected before downstream consumers make decisions from stale or partial data.<\/p>\n ServiceNow positions Service Graph Connectors as standardized integrations that use platform CMDB capabilities, including the Identification and Reconciliation Engine and common data-model practices. That is important because the connector should participate in the same governance as other CMDB sources. A prebuilt integration reduces implementation effort; it does not remove the need to understand the data it contributes.<\/p>\n Every source has a reason to exist. A cloud provider may know resource identifiers and runtime metadata. An endpoint platform may know device posture. A network controller may know topology. A procurement system may know ownership or lifecycle data. Before enabling a connector, write down which classes and attributes the source is expected to improve and which fields it should not control.<\/p>\n This prevents a common failure mode in which the latest source to connect becomes the accidental authority simply because it writes frequently. The governance principles in CMDB governance<\/a> require deliberate ownership of source precedence. If an attribute is important enough to drive automation, routing, risk, or reporting, the platform team should be able to explain which source is trusted to update it and why.<\/p>\n Source authority should also include lifecycle expectations. What happens when an object disappears from the source? Does the connector retire the CI, mark it stale, or simply stop updating it? A CMDB record that remains forever after its source has forgotten it can become more misleading than a missing record.<\/p>\n Connector data must land in classes that preserve useful meaning. Mapping everything into a generic class may simplify ingestion initially but weakens relationships, identification, reporting, and downstream automation. Mapping too aggressively into specialized custom classes can create another problem: a model that is difficult to maintain and incompatible with standard applications.<\/p>\n The design patterns in CI classes and relationships<\/a> are directly relevant. Choose classes based on durable semantic differences and operational use, then model relationships that answer real questions about dependency, hosting, containment, or service composition. A connector should enrich that model rather than invent an isolated taxonomy.<\/p>\n Review the connector\u2019s default mappings before changing them. Standard mappings can provide compatibility benefits with common ServiceNow capabilities. Customize only where the source semantics or organization\u2019s operating model genuinely require it, and document the consequences for upgrades and other consumers.<\/p>\n When a connector sends a candidate CI, ServiceNow needs to determine whether the object already exists. Identification rules provide the ordered criteria used to match incoming data to an existing CI. If the identifiers are weak, unstable, or poorly scoped, the same real object can appear as multiple records. If they are overly broad, distinct objects can be merged incorrectly.<\/p>\n A strong ServiceNow data foundation<\/a> therefore treats identifiers as part of the data contract. Stable provider IDs, serial numbers, names qualified by context, and relationships to parent objects can all be useful depending on the class. The right identifier is the smallest reliable set of attributes that describes identity, not simply the fields most convenient to query.<\/p>\n Before large-scale activation, test representative objects that have incomplete fields, changed names, duplicate names, and existing records created by another source. The important question is not whether the connector can create a CI. It is whether the same physical or logical object converges on one CI across realistic source conditions.<\/p>\n Most enterprise CMDBs have overlapping sources. Discovery, Service Graph Connectors, imports, manual stewardship, and application integrations may all know something about the same CI. Reconciliation rules decide which source is allowed to update selected attributes and, where priorities apply, which source wins when several can write.<\/p>\n The mechanisms described in ServiceNow reconciliation<\/a> are essential to connector design. A new source should not be allowed to overwrite a high-confidence attribute merely because it runs later in the day. Conversely, an overly restrictive rule can stop a better source from correcting stale values. Precedence should reflect data authority, not chronology.<\/p>\n Reconciliation also needs exception handling. If a connector begins submitting malformed values, operators should be able to detect that its updates are rejected or producing unexpected changes. Silent disagreement is dangerous because the source appears healthy while the CMDB never reflects its intended improvements.<\/p>\n Service Graph Connector implementations commonly rely on structured transformation and ingestion pipelines. Whether configuration uses standard mappings or organization-specific extensions, the transformation layer should be understandable enough to troubleshoot. Source fields, normalized values, target classes, reference lookups, and relationship creation should not depend on undocumented magic.<\/p>\n The integration principles in REST API automation<\/a> still apply at the source boundary: authentication, pagination, rate limits, partial responses, and error handling can all affect the data delivered to the CMDB. A connector that successfully authenticates but silently drops half the pages is not healthy.<\/p>\n Capture counts and meaningful failure categories throughout the pipeline. Operators should be able to compare objects seen at the source, objects transformed, CIs matched, CIs created, attributes rejected by reconciliation, and records failed. Those numbers make it possible to distinguish a source outage from a mapping defect or an identification problem.<\/p>\n Connector freshness depends on jobs running successfully and on credentials remaining valid. A platform team that configures a connector once and never monitors it will eventually have stale data. Treat the connection, credential, MID Server path where applicable, and collection schedule as production dependencies with owners and alerts.<\/p>\n Credential privileges should be limited to the source data the connector needs. Broad cloud or infrastructure credentials increase the impact of compromise and can make troubleshooting harder because the account can perform actions unrelated to inventory. Rotation procedures should include a way to validate the new credential before the old one expires.<\/p>\n Collection cadence should reflect how quickly the source changes and how quickly consumers need that change. More frequent ingestion increases API and platform load. Less frequent ingestion increases staleness. The correct schedule is a service-level decision grounded in downstream use, not an arbitrary \u201cevery hour\u201d default.<\/p>\n A connector can run without errors and still produce weak data. Health monitoring should therefore include whether expected objects are present, whether critical attributes are populated, whether relationships are created, whether data is fresh, and whether duplicate or reconciliation exceptions are increasing. No single metric captures all of those dimensions.<\/p>\n The operating model in CMDB health metrics<\/a> is useful because it connects measurements to remediation. A spike in stale CIs should lead to source or schedule investigation. A rise in duplicates should lead to identification analysis. Missing relationships should be routed to the owners of mapping or source data.<\/p>\n Trend changes matter as much as absolute thresholds. A connector that moves from 99 percent coverage to 95 percent may still be \u201cgreen\u201d under a broad threshold but could indicate a new API filter, credential scope change, or source inventory shift. Platform engineers should investigate meaningful deltas before they become widespread data loss.<\/p>\n A mature environment keeps a source registry describing each connector, its owner, classes, key attributes, identification assumptions, reconciliation authority, schedule, credentials, and support path. That register gives change reviewers a way to see interactions before a new connector is added or an existing mapping changes.<\/p>\nStart by defining what the external source is authoritative for<\/h3>\n
Map external concepts into a coherent class model<\/h3>\n
Identification rules determine whether ingestion creates trust or duplication<\/h3>\n
Reconciliation rules protect attribute ownership when sources overlap<\/h3>\n
IntegrationHub ETL and transformation need observable contracts<\/h3>\n
Schedules and credentials are operational dependencies, not setup details<\/h3>\n
Health metrics need to measure coverage, freshness, and correctness together<\/h3>\n
Connector governance should make CMDB trust explainable<\/h3>\n