Configuration Items represent your infrastructure and applications in ServiceNow's Configuration Management Database. This guide walks you through manually creating CIs with the right class selection and field setup.
Why manual CI creation is needed
Discovery and Service Mapping automate most CI population, but they can't catch everything — especially cloud services, vendor applications, or infrastructure outside your network scan range. CMDB admins and service owners need to manually create CIs for these gaps. The catch is that manually created CIs can conflict with Discovery later if you don't choose the right CI class or set the correct identification fields. Get it wrong and you'll have duplicate CIs or missing relationships when Discovery runs.
How CI classes and identification work
Every CI belongs to a class in ServiceNow's hierarchy — cmdb_ci is the parent, with subclasses like cmdb_ci_server, cmdb_ci_appl, cmdb_ci_service. The class you choose determines which fields appear, what Discovery rules apply, and how Service Mapping connects relationships. Each class has identification rules that Discovery uses to match incoming data to existing CIs. If you create a server CI but use the wrong name format, Discovery will create a duplicate instead of updating yours.
Building production-quality CIs
A basic CI needs the right class, name, and operational status. Production CIs need proper identification attributes (IP addresses for servers, URLs for applications), accurate relationships to other CIs, and reconciliation state management so Discovery knows how to handle them. The best manually created CIs include enough detail that when Discovery eventually finds the same asset, it updates the existing record instead of creating conflicts.
Before you start
- •itil or admin role with CMDB write access
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to Configuration Items
Go to Configuration → Servers → All. Don't use the generic 'Configuration Items' module — start with the specific CI type you're creating (Servers, Applications, Services, etc.). This ensures you get the right class selection and relevant fields upfront.
The specific modules filter the CI class choices to relevant options only.
Select the correct CI class
Click New and choose your CI class from the dropdown. For physical/virtual servers use 'Computer', for applications use 'Application', for business services use 'Service'. The class determines everything else — available fields, Discovery behavior, relationship types. Don't use the generic 'Configuration Item' class.
When in doubt, pick the most specific class that matches — you can't easily change it later.
Set the name and identification fields
Fill in the Name field using your organization's naming convention. For servers, add the IP Address or FQDN. For applications, include the URL or install path. For services, use the business service name. These identification fields are critical — Discovery uses them to match against your manual CI instead of creating duplicates.
Use the same naming format that Discovery would generate for consistency.
Configure operational status
Set Operational Status to the current state: Operational, Non-Operational, or Repair in Progress. Set Install Status to Installed for active CIs. Leave Substatus blank unless you have specific business rules that depend on it. These status fields affect reporting and change management workflows.
Add location and ownership details
Set Location to the physical or logical location. Fill in Owned by or Managed by to establish ownership. For servers, set Company to your organization. These fields enable accurate reporting and ensure proper access controls on the CI record.
Set Discovery reconciliation state
In the Discovery section, set Reconciliation State to 'Excluded from reconciliation' if Discovery should never touch this CI, or leave it blank if Discovery should update it when found. Set this correctly to avoid CI conflicts later. Save the record.
Use 'Excluded from reconciliation' for cloud services or third-party applications that Discovery will never find.
Best practices
Always choose the most specific CI class available — generic classes break Discovery matching and Service Mapping relationships.
Include IP addresses or FQDNs for servers even when manually created — Discovery uses these as primary identification keys.
Set reconciliation state explicitly on manual CIs to prevent Discovery from creating duplicates or ignoring updates.
Use consistent naming conventions that match what Discovery would generate — this ensures clean merging when automated tools find the same assets.
Create relationships to parent CIs immediately after creating the CI — orphaned CIs provide no value for impact analysis or service mapping.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue