> ## Documentation Index > Fetch the complete documentation index at: https://docs.serval.com/llms.txt > Use this file to discover all available pages before exploring further. # CMDB > A configuration management database for business applications, IT services, and the infrastructure that delivers them, mapped for impact analysis. The configuration management database (CMDB) template installs a [database](/sections/documentation/databases/overview) that catalogs your service landscape: the business applications and IT services people depend on, the infrastructure that runs them, and the relationships between them. CMDB relationships are built into the schema and [queryable](/sections/documentation/databases/browsing-and-querying#the-context-graph), so change management and impact analysis (e.g. "what's downstream of this server?") work out of the box. To set up a CMDB, either install it from the template library, or ask Catalyst to "set up a CMDB." One team gets one CMDB database. ## What it models The schema is organized into three layers: business, service, and infrastructure. ### Business layer This layer maps the outcomes an application outage affects, so that business impacts are clear. | Table | What it records | | :- | :- | | **Business Capability** | A business function (e.g. Payroll, Order Fulfillment), supported by one or more applications. | ### Service layer The service layer describes what people name when they ask for help, and the applications behind it. | Table | What it records | | :- | :- | | **Business Application** | A business-facing application (e.g. Salesforce, Workday, an internal API). One record per application, across all environments. | | **IT Service** | A service as employees experience it (e.g. Email, VPN, Single Sign-On, Wi-Fi). | | **Application Service** | A deployed instance of an application in one environment (e.g., a production API). | ### Infrastructure layer The infrastructure layer maps the resources that deliver the services, typically ingested from cloud, MDM, and discovery sources. | Table | What it records | | :- | :- | | **Server** | A physical or virtual server, hypervisor, or container host. | | **Virtual Machine** | A hypervisor-hosted or cloud VM. The physical host, if tracked, links via a Server record. | | **Container Workload** | A long-running containerized workload (e.g. a Kubernetes deployment, an ECS service). One record per workload, not per instance. | | **Database Instance** | A database backing one or more services, self-hosted or managed (e.g. RDS, Cloud SQL). | | **Network Device** | Switches, routers, firewalls, load balancers, access points, VPN gateways. | | **Cloud Resource** | A provisioned cloud resource (e.g. VM, bucket, managed database, cluster, function). | | **Certificate** | A TLS/SSL certificate, with its expiration date. | | **Location** | A site where infrastructure lives (e.g. office, datacenter, cloud region, warehouse). | ## The dependency map In addition to the reference fields on each table, the CMDB template documents the following relationship types, which are useful for impact analysis: * **Delivered By**: an IT Service to the Application Services that deliver it. * **Service Dependency**: one Application Service to another it calls at runtime. * **Runs On** / **Hosted On**: an Application Service to the Server or Cloud Resource it runs on. * **Uses Database**: an Application Service to the Database Instances it reads and writes. * **Secures**: a Certificate to the services it secures. * **Supports Capability**: a Business Application to the Business Capabilities it supports. Together, these relationships allow you to trace impact from a dead server, through the Application Service and its dependency chain, up to the IT Service an employee named in a ticket, and out to the Business Capability it affects. Open any record's [context graph](/sections/documentation/databases/browsing-and-querying#the-context-graph) to trace it, and the help desk agent traverses the same graph when it answers. The help desk agent can find **Business Application** and **IT Service** records by name without a requester link, because those are what people name in tickets (e.g. "Salesforce is down"). Infrastructure records stay [scoped to the requester](/sections/documentation/databases/administration#help-desk-agent-visibility). ## Use cases * **Impact analysis before a change.** Before you take a server, database, or certificate down, trace what depends on it, so you know who's affected and can plan. * **Faster incident triage.** When someone reports a problem like "Salesforce is down," the help desk agent resolves the named service to the applications and infrastructure behind it, and surfaces the likely culprit from the dependency chain. * **Service ownership.** Understand which applications support each Business Capability and which infrastructure delivers each service. ## Usage tips * **Populate** it by connecting your cloud, MDM, and discovery sources with [ingestion configs](/sections/documentation/databases/ingestion), or load records by [CSV import](/sections/documentation/databases/manual-data-entry). Key fields (e.g. FQDN, resource ID, instance ID) are the de-duplication keys that sync matches on. * **Extend** it with your own fields, tables, and [relationships](/sections/documentation/databases/schema-design#relationship-edge-types), and add [validation rules](/sections/documentation/databases/rules) to keep records complete. * **Govern** it with [table, field, and record-level access](/sections/documentation/databases/administration#record-level-access-rules), and mark sensitive fields so each reveal is logged in your organization's audit logs (accessible by your admins). ## How it fits with the other templates CMDB, [Hardware Assets](/sections/documentation/databases/hardware-assets), and [Software & Licensing](/sections/documentation/databases/software-and-licensing) are separate databases by design, joined by shared values rather than hard links: a Server's serial number matches its hardware-asset record, and Location means the same thing in each. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.