Configuration Management (CMDB)
A CMDB that's actually used. Configuration Management in ServiceCore turns your configuration items and the dependencies between them into a living model on the shared data model, so the impact of a change or an incident is visible up front rather than discovered the hard way. Every CI — service, application, server, network device, database, license — lives in one standard structure with typed relationships like depends-on, runs-on, hosts and uses, so the same record answers questions for every ITIL 4 practice instead of being copied into disconnected spreadsheets.
Built for the way configuration management (cmdb) should work
A CMDB that's actually used. Configuration Management in ServiceCore turns your configuration items and the dependencies between them into a living model on the shared data model, so the impact of a change or an incident is visible up front rather than discovered the hard way. Every CI — service, application, server, network device, database, license — lives in one standard structure with typed relationships like depends-on, runs-on, hosts and uses, so the same record answers questions for every ITIL 4 practice instead of being copied into disconnected spreadsheets.
The model stays accurate because Discovery feeds it. Network, SNMP, WMI/WinRM, SSH, cloud and agent scans reconcile against existing CIs by hostname, MAC and serial number, so a re-scan refreshes attributes and relationships rather than creating duplicates. Manual edits and Change records fill the gaps automation can't reach, and every update writes an audit trail of who changed which attribute and when — the difference between a CMDB people trust and one they quietly stop using.
Service relationships are what make the data operational. Each CI is mapped to the services it underpins, so a single application or server is traced upward to the business services that depend on it and downward to the infrastructure it relies on. When an Incident or Change touches that CI, ServiceCore reads the dependency chain to surface affected services, impacted users and critical paths before anyone commits — impact analysis stops being guesswork and becomes a query against the model.
Because the CMDB sits on the same data model as the rest of the platform, configuration context flows into every practice automatically. Incident and Problem records link to the CIs involved; Change uses pre-change impact analysis to scope risk, route the right advisory groups and keep the model reconciled after deployment; Request and Service Level Management read the related agreements and ownership attached to each CI. One source of truth, twenty-nine modules speaking the same language about your environment.
- Configuration item management
- Dependency mapping
- Service relationships
- Impact analysis
- CI lifecycle
- Discovery-fed accuracy
What you can do with it
Configuration item management
Model every CI type — service, application, server, network device, database, license — in one standard data model with reusable type templates and attribute schemas.
Typed dependency mapping
Define depends-on, runs-on, hosts and uses relationships between CIs and query the resulting upstream and downstream dependency chains in a single view.
Service relationships
Connect each CI to the business and technical services it underpins so a service map shows exactly which components keep it running.
Pre-change impact analysis
Walk the dependency graph from any CI to automatically list affected services, impacted users and critical paths before a change is approved.
Discovery-fed reconciliation
Network, cloud and agent scans reconcile against existing CIs by hostname, MAC and serial number, refreshing attributes without creating duplicate records.
CI lifecycle and audit trail
Track each CI through its lifecycle states with a full history of who changed which attribute and when, kept in sync with linked Change records.
Why teams adopt it
Fewer change-related incidents
Teams see the real blast radius of a change before approving it, so risky deployments are caught at the CAB stage instead of in production.
Faster incident resolution
Responders see which services and dependencies sit behind an affected CI immediately, shortening diagnosis and prioritization during major incidents.
A CMDB people trust
Discovery-fed accuracy and a clear audit trail keep the model current, so every practice works from one source of truth instead of stale spreadsheets.
Audit-ready configuration history
Every CI change is attributable and linked to its Change record, giving you a defensible evidence chain for compliance and internal reviews.
Where it fits
Scoping a change
Before approving a server or application change, the change owner runs impact analysis on the CI to see every dependent service and user, then routes it to the right advisory group.
Major incident triage
When a service degrades, the incident team traces the affected CI down to the infrastructure it runs on and up to the business services at risk, prioritizing by real impact.
Keeping the model current
Scheduled Discovery scans reconcile newly added or reconfigured assets into the CMDB automatically, so the model reflects the live environment without manual inventory work.
Linking agreements to assets
Support, supplier and customer agreements attached to each CI let a request or incident surface the relevant Service Level and responsibility boundary at a glance.
Common questions
The Discovery module feeds it directly — network, SNMP, WMI/WinRM, SSH, cloud and agent scans reconcile against existing CIs using hostname, MAC and serial number, so re-scans refresh attributes and relationships instead of creating duplicates. Manual edits and Change records cover what automation can't reach, and every update is recorded in an audit trail.
Part of these solutions
Related modules
See Configuration Management (CMDB) in action.
Book a demo and we'll show configuration management (cmdb) working alongside the rest of the platform — on one shared data model.