Not every important CI can be discovered by scanning
A scanning tool can reveal hosts, processes, network interfaces and supported cloud resources, but business importance is often invisible to the network. An application portfolio record, a critical customer service, a contract obligation or an identifier used for an audit may need an accountable person or another system of record. The ServiceNow CIS-DF ingestion objectives explicitly include non-discoverable or manually maintained CIs, non-discoverable attributes, compliance identifiers and alignment of assets with CIs.
A useful implementation separates evidence types. Technical collectors supply observable facts; business and risk owners supply classifications, consumers, contracts and lifecycle decisions. An administrator should not fabricate an application owner because a required field is blank, and a technical source should not overwrite a verified business ownership field merely because it refreshed later.
Discovery, Service Graph Connectors and ETL can supply machine-observed identifiers and infrastructure attributes. Regulatory ownership, contractual responsibilities and some business-service relationships require accountable nontechnical sources. Govern those manual values with provenance and reconciliation rules instead of letting them overwrite discovered facts indiscriminately.
Write an intake contract for manual CI creation
For a new logical business application, define what the record represents and what it does not. Require an accountable owner, unique naming or identifier convention, lifecycle stage, service relationships, and the decision that justifies CMDB inclusion. A manually created application component that lacks any actual consumers may still be legitimate, but the submitter should be able to explain its purpose and expected later relationships.
A proposed intake form can ask for the owning team, approved application or service name, environment, lifecycle state, criticality, the relevant business capability and references to supporting infrastructure. Avoid making every technical property mandatory for a logical record; fields such as device serial number may be inapplicable. Data stewards should validate exceptions and standardize values where needed.
The process must also define updates and retirement. If a business application is reorganized, who changes its owner? If two departments submit the same product with slightly different names, which authority decides whether those are distinct applications or duplicate descriptions? Naming conventions and reviews should prevent new manual duplicates before they reach the cleanup queue.
Recognize when an asset and a CI are different views
An asset record tracks commercial or physical lifecycle facts such as purchase, custody, warranty, stockroom and disposal. A CI models a configuration object and operational relationships used for management, incident, change and service impact. These concepts can refer to the same device but should not be collapsed into one table or assumed to have a universal one-to-one relationship. A leased laptop may have a physical asset record; a cloud-hosted application service may be a CI without a purchased hardware asset.
Consider a server being replaced under a warranty. The retired hardware asset, the new hardware asset and the operational service dependency require careful treatment. A simple asset-to-CI link can support traceability where appropriate, but replacing the hardware does not automatically mean the business service ceases to exist. Likewise, financial ownership may live in an asset or ERP process and should not be replaced by an IP-discovery result.
Align identity, not vocabulary. Define the correspondence between serial or inventory identifiers and the CI when useful, agree which system is authoritative for asset fields and test updates after returns, redeployments or disposal. Data synchronization should not create duplicates simply because one team calls a device a configuration item and another calls it equipment.
Add security and compliance identifiers without inventing technical evidence
Risk management may require tracing which service, system or CI is in scope for a regulation, control, contract or audit finding. The CMDB can support that connection, but a regulatory identifier often comes from a compliance process rather than an automated scan. The implementer should model the reference to the correct CSDM object and preserve clear ownership for the identifier.
For example, a financial service may have an approved control identifier and an accountable business owner. One application service supporting the financial offering might inherit operational impact context, but it should not automatically receive every business compliance classification when the requirements apply only to certain data flows. The model should answer “which object is subject to this control and why?” without making unjustified assumptions.
Before bulk populating compliance fields, confirm source, definition, intended target class and change process. If an auditor questions an identifier, the organization needs to trace it back to an approved policy or owner. An empty field can be a governance defect; an invented value is worse because it creates false assurance.
Govern lifecycle and cross-table relationships
Manual CIs can become stale because no Discovery job will refresh them. Assign review intervals based on risk and use attestation for business-supplied attributes. A logical service whose owner left the organization may need reassignment rather than deletion. A non-discoverable object can remain important even when no network scan reports it; staleness must be interpreted in the context of its expected source.
For decommissioning, distinguish CI lifecycle from asset disposal. Data Manager policies govern retirement, archiving, deletion and attestation. A CI that has active relationships to change records or critical services should not be deleted simply because a spreadsheet says “closed.” Review dependent CIs, downstream references and supported retention requirements.
Record evidence of approval and effective changes. A change in asset status can trigger an eligibility review for CI retirement, but business owners should decide whether the corresponding operational service or logical object is actually gone. That safeguard is especially important for shared infrastructure and cloud resources that move between applications.
Test a real workflow question with a fictional portfolio
Assume a business offers online payments supported by two application services, several database instances and a managed network connection. The payment business application has a portfolio owner, while the service offering has a customer-facing owner. Technical feeds discover databases but not contractual control IDs. An intake process must add relevant non-discoverable objects and link them correctly.
Test whether a change planner can find which offering depends on a database; whether an asset administrator can see the physical device link where appropriate; and whether a risk reviewer can identify the approved control associated with the service. If one query yields nothing, investigate missing relationships or incorrect target classes instead of importing another copy of the same application.
Use CSDM 5 service modeling to distinguish service objects, and CSDM service mapping relationships to understand their dependencies. The goal is a CMDB where business-supplied and discovered facts remain traceable, not an inventory that claims every attribute came from a machine.
Decide whether a business object belongs in the CMDB
Not every governance record should be converted into a CI. A department contact, control document or procurement approval may belong in its owning platform with a reference to a CI or service; making a new configuration class for it can make identity and lifecycle unclear. Ask whether the object represents something whose configuration and relationships need operational management, or whether it is evidence about such an object.
An approved compliance requirement may reference an application service and its data flow while remaining a separate control record. A support contract may link to an asset without being the same asset or CI. Clear references provide traceability without inventing extra CI types. The correct design keeps one authoritative business record and only the CMDB relationship required by consumers.
This distinction supports ServiceNow CMDB architecture and the CSDM modeling approach. An exam scenario that offers “discover the regulatory owner from a server” is often testing recognition that technical evidence cannot supply a human compliance decision.
Reconcile a retired asset with an active service
An old network appliance asset is marked disposed, but its linked CI still appears as a dependency of a critical service. A simplistic sync could retire and delete the CI immediately. A governed process confirms whether the appliance was replaced, whether the service map still references obsolete hardware and whether another CI now represents the active endpoint.
If the asset data is correct, the appropriate response may be updating relationships and retiring the old CI under approved lifecycle policy. If the asset status is wrong, correct that authoritative source first. In either case, a service owner should validate the operational effect. This is why asset/CI alignment is a relationship of accountability rather than a universal automatic status copy.