The ServiceNow CMDB stores configuration items (CIs) — servers, applications, databases, network devices, and the business services they support — along with the relationships between them. It is used for change impact analysis, incident root-cause analysis, service mapping, and compliance reporting. To use it well, let Discovery and Service Graph connectors populate CIs instead of manual entry, enforce identification rules to prevent duplicates, and keep relationships clean so every downstream team can trust the data.

Every CI sits in the cmdb_ci base table or a child table such as cmdb_ci_server, cmdb_ci_database, or cmdb_ci_appl. You can query them with list filters and reports, through CMDB Workspace, or programmatically using GlideRecord in scripts and the Table API for external tools. To pull relationships, query the cmdb_rel_ci table and filter on the parent and child fields.

CMDB stands for Configuration Management Database. In ServiceNow it acts as the single system of record for configuration items and their relationships, anchoring ITIL practices such as incident, problem, and change management.

It is an out-of-the-box set of dashboards that scores your CMDB on completeness, correctness, and compliance. The KPIs worth tracking are duplicate CIs, stale records, CIs missing mandatory attributes, orphaned relationships, and unclassified data — fixing these early keeps change and incident processes dependable.

Typical questions cover what a CI is, CMDB vs asset management, how Discovery feeds the CMDB, identification rules, the reconciliation engine, duplicate handling, relationship types, and CMDB health KPIs. Interviewers usually dig into real scenarios — how you removed duplicates or repaired broken relationships at scale — so prepare one hands-on CMDB cleanup story. Structured options like topic-wise ServiceNow interview prep sessions are useful if you want to rehearse these with feedback.

There is no standalone CMDB exam — CMDB depth is tested inside ServiceNow's ITOM implementation certifications, especially the Certified Implementation Specialist – Discovery (CIS-Discovery) path, and you can reinforce the basics with the CMDB Fundamentals micro-certification on Now Learning. For most roles, one ITOM-side certification combined with proven hands-on CMDB work is enough.

Discovery runs through MID Servers placed inside your network. A schedule scans the target IP ranges (the Shazzam port scan), classifies each device, runs probes, sensors, or horizontal patterns to collect attributes, and then applies identification rules to either update an existing CI or create a new one in the CMDB. The ServiceNow Discovery architecture routes all traffic through the MID Server, so credentials and network access stay under your control.

Discovery processes each device in four phases: scanning (open ports are found), classification (the device type is determined), identification (identification rules match the device to an existing CI or decide to create one), and synchronization/update (attributes and relationships are written back to the CMDB). Knowing which phase failed is the fastest way to debug missing or incorrect CIs.

Horizontal discovery is the bottom-up approach that finds individual infrastructure CIs — servers, switches, databases, storage — using probes, sensors, and horizontal patterns. It differs from top-down discovery (Service Mapping), which starts from a business application and traces its dependent CIs to build the service map. Most implementations start horizontal and add top-down mapping later for critical services.

Install and validate a MID Server that can reach your target networks, add the right credentials (SSH, WMI/PowerShell, SNMP, database), define the IP ranges to scan, and configure the protocols and ports for the port scan. Run a test schedule against one small subnet first, review the created CIs and errors, tune identification rules, and only then scale up to production ranges.

The most common routes are the Jira spoke in Flow Designer (IntegrationHub) or a direct REST integration using OAuth 2.0 on both sides. A typical design triggers a flow when an incident is created or updated, maps fields into the Jira issue payload, and writes Jira updates back using a correlation ID. Decide the sync direction and field mapping upfront to avoid update loops — and if payload mapping or error handling gets complex, a 1:1 ServiceNow integration help session can review your specific design.

Install the ServiceNow app for Microsoft Teams from the Teams app store and connect it through an Azure AD app registration with OAuth. Once linked, users can approve records, receive notifications, and search knowledge articles inside Teams, and you can extend the setup with the Microsoft Teams spoke in IntegrationHub for custom Flow Designer notifications.

Connect Power BI through ServiceNow's Table API or reporting REST endpoints using a dedicated service account with OAuth, and shape the JSON response in Power Query; the ServiceNow ODBC driver is another option for heavier reporting. Schedule refreshes carefully and watch API rate limits on large tables such as cmdb_ci and incident.

IntegrationHub is ServiceNow's low-code integration layer built on Flow Designer, offering prebuilt spokes for tools like Jira, Slack, Microsoft Teams, and AWS so you can call external systems inside flows without custom scripting. The ServiceNow Integration Hub Starter pack is included with most instances with a limited number of spoke activations, while Pro and Pro Plus packs unlock more spokes and higher-volume, complex integrations.

Expect questions on REST vs SOAP, when to use IntegrationHub spokes versus custom REST messages, MID Server-based integrations, authentication methods like OAuth, error handling and retries, avoiding duplicate or looping updates, and payload mapping between systems. Scenario questions such as "ServiceNow and Jira both update the same record — how do you prevent conflicts?" are common, so have one end-to-end integration story ready.