Before comparing the data each method produces, it's worth understanding how each one gets that data into the CMDB — because the mechanism explains most of the strengths and limitations below.
ServiceNow Discovery runs from a MID Server sitting on your network. It doesn't install an agent on target machines. Instead, it:
1. Finds IP ranges/hosts via a Discovery Schedule.
2. Classifies what a host is (Windows server, Linux box, network device, etc.) using probes.
3. Interrogates the host directly — over WMI, SSH, SNMP, PowerShell remoting, etc. — using credentials stored in ServiceNow, guided by Discovery patterns (step-by-step logic for what to collect and how).
4. Writes the results straight into CMDB tables, applying Identification and Reconciliation Engine (IRE) rules to match against existing CIs and decide what's allowed to update what.
Because Discovery talks to the live host itself, it can walk outward from that host to whatever it's connected to — open ports, running processes, config files, other hosts it talks to — which is what makes relationship mapping possible.
The SCCM integration isn't Discovery reaching out to endpoints — it's ServiceNow pulling already-collected data from SCCM's own database via IntegrationHub (typically a scheduled data import / ETL job or a REST/SOAP connector, depending on how the integration is built). In this model, ServiceNow:
1. Connects to the SCCM reporting server (not individual site servers, and not the endpoints themselves).
2. Imports whatever SCCM's own agent already collected and reported.
3. Transforms/maps that data into CMDB tables via Transform Maps and IRE.
ServiceNow never talks to the endpoint directly in this flow — it's entirely dependent on SCCM's agent having been installed, healthy, and having already done the collection work. If SCCM doesn't know about something, ServiceNow doesn't either.
The core distinction: Discovery is ServiceNow actively collecting data itself. IntegrationHub is ServiceNow importing data someone else already collected. That's why Discovery can map relationships and middleware it's never been told about, while any IntegrationHub-sourced integration can only ever be as good as what the source system's own agent captured.
SCCM is the most common example of this pattern, but it isn't the only one:
All three (SCCM, JAMF, Foreman) share the same shape: ServiceNow calls out to a management platform's API/reporting layer on a schedule, imports what that platform already knows, and maps it into CMDB via Transform Maps and IRE. None of them involve ServiceNow talking to the endpoint directly.
|
Area |
Behavior |
|
WMI attributes |
Both can pull WMI data. ServiceNow Discovery tends to expand further into the local WMI database than the SCCM import provides. |
|
Software inventory |
ServiceNow generally defers to SCCM for software inventory (it's SCCM's core strength), except on servers, where Discovery's collection is more robust. |
All of these trace back to the same root cause: an IntegrationHub-based integration only reflects what the source platform already collected. If that platform's agent or enrollment is absent or unhealthy, there's no fallback — ServiceNow has no independent way to find that host through that path.
This is where reconciliation rules do the real work: for any given attribute, you designate which data source is authoritative ("safe"). In practice:
If you'd like this article extended further — a coverage-gap decision tree, or a table cross-referencing which platform owns which attribute per OS — let me know and I'll fold that in.