Configuration items
A configuration item (CI) is something a service runs on: a server, a virtual machine, a database, a load balancer, a certificate, a cloud account. The CMDB (configuration management database) is the list of them, each with its owner, the team that looks after it, how other tools know it, and what it is joined to.
CIs come with the CMDB plugin, which is built on Service Configuration. In the sidebar, under Service Configuration, it shows as Configuration items. If you don't see it, the plugin is off; an admin turns it on under Platform → Plugins.
Who can use it
Needs the CMDB plugin.
| Who | Can |
|---|---|
| Agent, Viewer, Auditor | Read the CIs of the units they work in, with their relationships and history. |
| Configuration Manager | Everything: add, edit, import and delete CIs, set their health by hand, and manage the classes. |
| A CI's owner | Edit their CI and set its health, whatever their role. |
| Platform Administrator, Organization Administrator | Everything. |
Each permission in detail: Permissions and the API.
Services and CIs
The service catalogue says what you deliver and who answers for it; the CMDB says what it runs on. They are one picture, joined by relationships:
SHOPbusiness service
application service, depends on
virtual machine, runs on
database, runs on
You don't need a CMDB to use services, and you don't need to record every server to use the CMDB. Start with what breaks most often, or what a change touches most often, and add the rest when it earns its place. Model an application adds a service and what it runs on in one go.
[!TIP] Join a CI to the application service that runs on it, not straight to the business service. The desk follows the chain upwards, so trouble on
db-prod-01reaches the application service and every service that depends on it.
A CI's record
| Field | What |
|---|---|
| Name | As people know it: a host name, or db-prod-01. |
| Class | The kind of thing (classes). It decides which data properties it has. |
| Lifecycle | Planned, Live, Retiring or Retired, as for services. |
| Environment | Production, staging and the like, from Service Configuration → Settings → CMDB → Environments, where you add your own. |
| Units | The units that hold it. People in them see it. |
| Owner | Accountable for the record, and can always edit it. Must work in one of its units. |
| Support team | Who looks after it. |
| Identifiers | How other tools know it: host names, addresses, serial numbers, ids in monitoring or a cloud (identifiers). |
| Description and links | For agents: what it is, what runs on it, where to start when it fails; runbooks and dashboards. |
| Data properties | The fields its class has, such as the operating system or a certificate's expiry. |
A retired CI keeps its relationships and history, and health skips it. A CI can be deleted only when nothing is joined to it and no case, incident, problem or change names it; otherwise retire it.
In this section
- Classes and identifiers: The kinds of CI and their properties, and how other tools know a CI.
- Health: A CI's health from its incidents and changes, how its trouble reaches the services that run on it, and setting it by hand.
- CIs on cases, incidents, problems and changes: Naming the CIs a record is about, known errors on a case, a change's impact, and the work on a CI.
- Model an application: A business service, its application and what that runs on, added and joined in one go.
- Working with CIs: The list, a CI's page, relationships and its history.
- Importing from a spreadsheet: Adding and updating CIs from a CSV file, checked first.
- For auditors: What is kept as evidence, and exporting the CMDB as it was on a date, for an audit scope.
- Permissions and the API: Each permission in detail, and what AI assistants and the API can do.