Custom CI classes let you track configuration items that don't fit existing categories — IoT sensors, specialized appliances, or business-specific assets. You'll end up with a properly positioned table in the CMDB hierarchy that supports Discovery and maintains data integrity.
Why custom CI classes beat workarounds
Without proper CI classes, teams end up force-fitting assets into inappropriate categories or tracking them outside the CMDB entirely. You'll see network printers classified as generic computers, IoT devices stuffed into the hardware table, or worse — critical infrastructure tracked in spreadsheets. This breaks Discovery workflows, makes reporting meaningless, and forces admins to maintain parallel inventories. Platform architects inherit these messes when they need accurate dependency mapping or compliance reporting.
How CI class hierarchy works
Every CI class extends from cmdb_ci or one of its child tables, inheriting fields and behaviors from its parent. The key decision is choosing the right level to extend from — too high (like cmdb_ci directly) and you miss useful inherited fields, too low (like extending cmdb_ci_computer for network devices) and you inherit irrelevant attributes. Start with the base functionality you need, then add your custom fields. ServiceNow's Discovery and other integrations respect this hierarchy, so proper placement makes your CIs work with existing workflows automatically.
Production-quality improvements
Basic custom classes work for manual data entry, but production implementations need Discovery integration, proper relationship definitions, and health state logic. Add identification rules so Discovery can populate your tables automatically. Define CI relationships that make sense for dependency mapping. Build health state calculations specific to your asset type. Consider performance — custom classes with hundreds of fields or complex business rules can slow down bulk operations and Discovery runs.
Before you start
- •admin role or table_admin access
- •Custom application scope (never extend CI classes in global scope)
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 the Tables module
Go to System Definition > Tables. You're creating a new table that will automatically appear in CMDB modules once it extends a CI class. Set your application scope to your custom app before starting — CI extensions in global scope create maintenance headaches and upgrade conflicts.
Create the table in the same scope as other CMDB customizations to keep related changes together.
Create the CI class table
Click New and fill in the Label (user-friendly name like 'IoT Sensor'), Name (auto-generates as 'u_iot_sensor'), and set Extends table to your chosen parent class. For most custom hardware, extend cmdb_ci_hardware. For applications, extend cmdb_ci_service_discovered. For infrastructure components, extend cmdb_ci_infrastructure. Check 'Auto number' if you want automatic numbering and save the record.
The extends choice is hard to change later — spend time picking the parent that gives you the most relevant inherited fields.
Add your custom fields
Navigate to the Columns tab on your new table record. Add fields specific to your CI type — sensor protocols, firmware versions, vendor-specific attributes. Use appropriate field types and avoid making fields mandatory unless absolutely required. Reference fields to other CMDB tables (like Location or Company) integrate better than free-text fields. Save each column as you create it.
Prefix custom field names with something recognizable like 'sensor_' to distinguish them from inherited fields during troubleshooting.
Configure the form layout
Go to System UI > Forms and search for your table name. Create a new form view or modify the default view to organize your custom fields logically. Group related fields in sections and position your most important custom fields prominently. Don't hide inherited fields that users need — like Name, Serial number, or Location. Test the form by navigating to your CI class in the Configuration > CI Class Manager.
Keep the standard CMDB fields visible — hiding Name or Asset tag breaks integrations that expect those fields.
Set up CI identifier rules
Navigate to Configuration > CI Class Manager, find your new class, and click on it. Go to the Identification Rules tab and click New. Create rules that define how Discovery identifies your CIs uniquely — typically combinations of Serial number, MAC address, or vendor-specific identifiers. Set the priority order for multiple rules and save. These rules determine how Discovery matches discovered items to existing CI records.
Test identification rules with a few manual records before running Discovery — incorrect rules create duplicate CIs.
Define CI relationships
In CI Class Manager, go to the Relationship Rules tab for your class. Add relationship rules that define how your CIs connect to other configuration items — IoT sensors might connect to network switches, specialized appliances to UPS systems. Use existing relationship types when possible rather than creating custom ones. Configure both parent and child relationships as appropriate for your CI type and save the rules.
Start with essential relationships only — you can add more complex dependency mapping after the basic class is working.
Test CI creation and Discovery
Create a test CI record manually through Configuration > [Your CI Class] to verify all fields work correctly. If you use Discovery, configure your MID server to recognize and populate your CI type — this typically requires custom Discovery patterns or sensor modifications. Run a limited Discovery test to confirm your identification rules work and don't create duplicates. Check that relationships populate correctly and the CI appears in dependency maps.
Best practices
Never extend from cmdb_ci directly unless you're creating a completely new top-level category — you'll miss essential inherited functionality from hardware, software, or infrastructure classes.
Keep custom CI classes in application scope even if you never plan to publish them — global scope extensions break during upgrades and can't be easily moved later.
Add custom fields gradually and test Discovery integration after each batch — bulk field additions often reveal field type or relationship issues that are easier to fix incrementally.
Use Choice fields for vendor-specific enumerations rather than string fields — this prevents data inconsistency and makes reporting cleaner.
Always create identification rules even for manually-managed CIs — if Discovery later detects these assets, proper rules prevent duplicate records.
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