You are here:
IT Admin Builds a CMDB with Discovery
Use Discovery to help an IT admin build a trustworthy configuration management database (CMDB) by inventorying configuration items (CIs) and their dependencies in a controlled portion of the IT environment.
Use Case at a Glance
Persona: An IT admin responsible for configuration data, Discovery coverage, and CMDB quality
Job to be done: Discover assets, identify them consistently, create or update configuration items, and expose useful relationships without relying on manual inventory entry
Starting point: CMDB and Service Graph are provisioned, and Asset Discovery is available in Salesforce Go.
Successful outcome: A defined pilot scope produces current CIs without duplicates, with traceable sources and sufficient relationship data to support impact analysis.
Use this scenario to choose an initial Discovery scope, validate the resulting records, and determine when the data is reliable enough to expand. Follow the linked Help topics for detailed provisioning, installation, credential-management, and target-configuration procedures.
Before You Begin
Confirm that CMDB and Service Graph are provisioned, CMDB and Asset Discovery are enabled, and the admin has the required access. See Set Up Discovery using Salesforce Go for the activation process.
Define a Trustworthy Pilot
Start with one inventory question and one bounded environment. For example, discover workstations in one office, servers in one subnet, remote endpoints in one pilot group, or selected cloud resources. A smaller scope makes identification, coverage, and relationship errors easier to detect before they affect the broader CMDB.
| Pilot Decision | Question | Evidence of Readiness |
|---|---|---|
| CI scope | Which CI types support the first operational use case? | Required types and attributes exist in CI Type Manager. |
| Discovery method | For end-user devices, can Microsoft Intune or Jamf Pro supply the inventory? For other assets, do you need agentless scans or endpoint agents? | The selected source matches how those devices are already managed. Intune, Jamf, or the chosen scan method is entitled and reachable. |
| Identity | Which stable attributes distinguish one CI from another? | Identification rules use values such as serial number or MAC address. |
| Ownership | Who reviews newly discovered or changed records? | A named data owner can investigate exceptions and gaps. |
| Success measure | What proves that the pilot is useful? | Coverage, freshness, duplicate rate, required attributes, and relationship completeness have acceptance criteria. |
Discovery can populate CMDB from network, endpoint, virtual, cloud, and supported management-system sources. For a first end-user device inventory, start with Microsoft Intune or Jamf Pro. Those integrations pull managed Windows, macOS, and mobile devices from systems customers already use. Use agentless or agent-based scans when the target isn’t in Intune or Jamf. Select only the methods that match the environment and entitlements. See Discover Devices from Microsoft Intune and Discover Devices from Jamf Pro. For how Discovery and CMDB work together, see How CMDB and Discovery Work Together to Improve Asset Management.
Define Identification Rules Before You Scale
Define CI types and the attributes that the pilot requires before trusting scan results. Identification rules determine whether incoming data updates an existing CI or creates a new one. Incorrect or missing identifiers can create duplicate records, update the wrong asset, and weaken relationships and reporting.
Use stable identifiers that the selected source reliably supplies. Test representative assets that are new, already known, renamed, or reported by more than one source. Confirm that repeated scans update the intended CI instead of creating another record. See Identification Rules in CMDB for the canonical matching behavior.
Identification is not a general source-precedence or duplicate-merging engine. If sources disagree, investigate the source data and modeling decision rather than assuming that CMDB automatically selects a surviving value or merges existing duplicates.
Discover and Validate the First Assets
Choose the collection method based on reachability. Agentless Discovery uses a Discovery Application on a Windows host, stored credentials, targets, probes, and scan jobs. Agent-based Discovery extends coverage to Windows, macOS, or Linux endpoints that aren't consistently reachable through network scans.
If the pilot manages laptops, Macs, or mobile devices, create an Intune or Jamf discovery target instead of starting with a network scan. Intune and Jamf run through Salesforce Flow and a registered connection. Each run creates or updates CIs from the MDM inventory. Review field mappings and identification rules before the first sync so devices match existing CIs instead of creating duplicates.
For each target, keep the initial scope narrow, choose the appropriate credentials and probe, and run the scan under the team's security practices. For more information about detailed installation and target procedures, see:
- 652868910280820633232821670507601149851513188037Agentless Discovery for Scanning IT Assets
- Agent-based Discovery for Extended Device Coverage
- Discover Devices from Microsoft Intune
- Discover Devices from Jamf Pro
Review the scan as a data-quality checkpoint rather than treating completion as success. Compare discovered totals with expected inventory, inspect failed discoveries, and review assets under All, New, and Updated. Confirm that required fields are populated and that repeated scans update existing records. See Monitor and Review Scan Jobs for the canonical scan-result sections.
Connect Configuration Items into a Service View
Inventory becomes operationally useful when teams can understand dependencies. Discovery creates or updates configuration items. It does not create those relationships automatically. After the scan or MDM sync finishes, open Process Manager and run a Process Job to connect the discovered CIs—for example, an application that runs on a server or a workstation that connects through a network device. Validate relationship direction and remove links that don’t represent the actual environment. See Process Manager for Analyzing Discovery Data and Run a Process Job.
Use Service Graph to inspect upstream and downstream connections, assess change or outage impact, and identify missing links. A graph layout controls what appears; it doesn't create relationships that aren't recorded in CMDB. See Visualize Configuration Item Relationships with Service Graph. Use Service Graph after Process Jobs have written the relationships you expect to see.
The adoption milestone occurs when a service team can use the pilot data to answer a practical question, such as which systems depend on an affected server. That requires Process Jobs to have created the relationships, not only a completed scan. A large CI count without stable identity, current attributes, and useful relationships is inventory volume rather than CMDB adoption.
Monitor Data Quality and Expand Discovery
Record a baseline after the first successful scan: expected assets, discovered assets, new and updated CIs, failures, duplicates, missing required attributes, and validated relationships. Choose scan or agent intervals that match how quickly the environment changes instead of describing all Discovery data as real time.
Expand to another subnet, endpoint group, CI type, or source only after the current pilot meets its acceptance criteria. Continue monitoring source activity, first and latest discovery timestamps, CI history, scan outcomes, coverage, and freshness. For the canonical Discovery sequence and processing behavior, see Learn the Discovery Lifecycle.
