Configuration Item (CI) Types

Configuration Item Types (CI Types) categorizes CIs with similar properties. Any organization-specific entity can be considered as a CI Type, such as Business Services, Workstations, Servers, Documents, or the People working for your organization.

Every CI must belong to a CI type.

All CI types should fall into the base CI type CMDB. A separate hierarchy for CI types is not allowed.

Role Required: SDAdmin and SDCMDBAdmin

CI Types List View

Go to Setup > Customization > CMDB. You will see the CI Types list view.

The list view is in the form of a tree structure that displays the hierarchy of all available CI types and their descriptions.The CI types are arranged in the parent-child structure.

Click Expand/Collapse Tree on the toolbar to toggle the list view between fully expanded and fully collapsed views. Click and to view and hide the children CI types, respectively.

Create CI Types

You can define new CI types to match your business needs. Click New CI Type on the list view.

The New CI Type form contains the following tabs:

Details
Fields
Relationships
Sync Rules

You will be able to configure the CI type fields and relationships only if you complete the basic details.

The CI Type name is unique across the CMDB.

The parent CI type can be any one of the existing CI types only. All the CI types fall under the base CMDB CI type.

You can add a maximum of 5 levels to the CI type hierarchy.

You can only add 100 CI types.

Details:

Fill out the details as explained below:

Fields	Explanation
CI Type Name*	Provide a name for the CI type.
Parent CI Type*	Select a parent type from the available list.
API Name*	Will be populated automatically based on the CI type name. You can still modify it. Enter the value in snake case consisting only of lowercase characters separated by an underscore. The API name will be prefixed by 'ci_' automatically.
Description	Describe the CI type.
Icon	Add an icon, if required.

* mandatory fields

Click Save. You will be redirected to the Fields tab.

Fields:

The Fields tab allows you to customize the layout of the CI Type form. It contains two sections: Canvas and Fields List.

The CI Type and Parent CI Type details are displayed at the top of the section.

There is a limitation to the total number of allowed fields in CMDB and this number keeps reducing as you drag fields inside the canvas while creating different CI types.

The CIs inherit their fields from parent and super-parent CI types.

Canvas

The canvas is where you build a template. It contains two sections:

Parent Fields

Click to expand and view the section. Fields in this section are displayed based on the Parent CI Type.
You cannot add, edit, or delete parent fields/sections.

Child Fields

Add fields and sections from the Fields List to the canvas using a simple drag-and-drop method.
By default, the Child Fields section is named the same as the CI type name. You can rename them by clicking on the section header and typing in the relevant section name.
To add existing fields, drag them from the right pane to the canvas.
To add new fields, drag a field type to the canvas and add the required details. Know more.
Additional fields can be edited or deleted from the canvas. Hover over an additional field and click to edit and to remove the field.
To add new sections, drag the New Section element from the right pane into the canvas and group the fields within the section. Hover over a section and click to set the section properties.
Rearrange the fields and sections by using a simple drag-and-drop method.
Hover over a field and use or on either sides of a field to resize the field length.

Fields List

The field list on the right pane contains two tabs:

Available Fields - Contains additional fields configured in the application that are not used in the canvas. Drag any field from this list to the canvas.
New Fields - Contains various field types that you can use to create additional fields for the CI type. To create a new field, drag a field type to the canvas and add the required details.
- Based on the selected field type, the field properties vary. Refer to this admin page to know how to configure different field types.
- You can also add sections to the template from the right pane. Use the New Section element to add sections to the canvas and group the fields within the section.

After configuring the fields, click Save.

Relationships:

Admin can define certain relationships between CI types, called the Suggested relationships. Admins decide the relationship type, the destination CI type, and the cardinality, based on the organization's requirements or policies. Child CI types inherit the relationships from parent and super parent CI types.

To create relationship types, go to Setup > Customization > CMDB > Relationship Types. Learn more.

Adhere to the following rules while adding suggested relationships:

Rule	Example
Relationships are not possible between parent and child CI types.	Consider the parent CI type 'Computer' and its child CI type 'Server'. While adding the relationship for 'Computer', the 'Server' option will be disabled under the Related CI Type picklist.
Sibling to sibling relationships is possible.	Assume, 'Workstation' and 'Server' are children of 'Computer'. You can create a relationship between 'Workstation' and 'Server'.
Self-relationships are possible but; - they cannot be duplicated. - they are not inherited by the children CI types.	'Computer Backed up by Computer'. Say, 'Computer' is the parent CI type and 'Server' is its child CI type. You cannot view this relationship under Parent Relationships of 'Server'.
You cannot create more than one relationship between two CI Types using the same relationship type. This means only one combination of a Source CI Type, a Relationship Type, and a Related CI Type is possible.	Consider the relationship 'Web Server Connected to IBM Workstation'. If you try to add the same relationship again, you will not see the option 'IBM Workstation' under the Related CI Type picklist.
Conflicting suggested relationships are not allowed.	Consider the suggested relationship 'User controls computer'. You cannot create 'Computer controls user' as another suggested relationship.
Suggested relationships cannot be edited but can be deleted.
If you delete a suggested relationship, the CI relationship created using this relationship will not be deleted, rather it will be treated as a custom relationship.

To add relationships,

Click Add Relationship.
Fill out the fields as required:

Field Name	Description
Source CI Type	This field will already be set to the current CI type and cannot be edited.
Relationship type*	The type of relationship shared between the Source and Related CI types. This can be either direct or inverse.
Related CI type*	Choose a CI type from the hierarchy of all available CI types.
Cardinality	Cardinality is the property of a relationship between one CI type and another. The relationship can be one of the following: One-To-One One-To-Many Many-To-One Many-To-Many If you do not choose a cardinality, the default value is taken as many to many.
Display Options	Enable the options as needed: Show this relationship as a separate tab - Enable this option to view the relationship as an individual tab in the CI details page. Hide this relationship in the map - Hide the relationship in the relationship map and business views. The relationship can still be viewed on the CI details page.

* mandatory fields

Click Save.

To delete a relationship, hover over it and click

The suggested relationships of the parent and super parent CI types, if any, are inherited by the children CI types and are displayed under Parent Relationships at the top of the relationships list view. Click

to expand the view. You cannot edit or delete the parent relationships.

No direct relationships are possible for the base CI type CMDB.

Sync Rules:

Sync rules define the data to be synced from assets, users, or software installations to CMDB.

Click New Rule to add a sync rule. Learn More.
Select a sync rule name to expand and preview the details.
Click to edit, delete, or run through a sync rule.
Use the toggle under Status column to enable or disable a sync rule.
Use the Actions button on the toolbar to enable, disable, or delete sync rules in bulk.

Data Quality

CMDB Data Quality policies help maintain the accuracy, completeness, and reliability of configuration item (CI) data. These metrics ensure that the CIs and their relationships are up-to-date and useful for IT service management and decision making.

Why is this important?

Track configuration items like critical hardware, software, and other assets.
Understand how these items are connected.
Make better decisions during incidents, changes, and upgrades.

Administrators can configure and monitor CMDB Data Quality by using the following policies:

Completeness: Ensures that all necessary information is present for each CI type.
Staleness: Ensures that CI data is up-to-date.
Orphan: Identifies CIs without configured relationships.

You can configure data quality policies for each CI type. The results of these policies can be viewed in the CMDB Dashboards and CMDB list view and CI details view. Results can also be exported as reports.

Configuring Data Quality Policies

To configure these policies,

Navigate to Setup > Customization > CMDB > CI Types.

Edit a CI type.
Go to the Data Quality tab.

If you are setting up the policy for the first time, click Configure. To edit or update an existing policy, use Actions/Configure.
Select the policy inheritance type:
- Inherit Parent Policy: Child CI types inherit data quality policies from their parent by default.
- Override Parent Policy: Define custom policies for the CI type, overriding the parent configuration.

By default, a child CI type inherits its configuration from the parent. If the parent has no configuration, it inherits from the super parent.

Configure the respective policies:
- Completeness:
  - Preferred fields: Select the preferred fields.

Preferred fields are non-mandatory but critical. A CI is considered complete when values are available for its preferred fields.
Mandatory fields can also be added as preferred fields.

Staleness:

Last Update Threshold (Days): Specify the number of days after the last update when a CI will be marked as stale.

Orphan:
- Define essential relationships for the CI type to identify orphaned CIs. Enter the relationship type and the related CI type. Learn more.

Click Save to save the configuration, or Save & Execute to apply them immediately to existing CIs.
After execution, you will receive a notification, and the updated values will appear on the CI details page.

Note: To exclude a particular policy from calculation, select Override Parent Policy, disable the checkboxes, and click Save. The policy will then be marked as not configured.

Data Quality Policy Actions

Edit: Click Actions > Edit to modify the policy configurations.
Execute Policy: Click Actions > Execute Policy to run the selected data quality policy immediately for the existing CIs using the saved configuration.

Usecase

Scenario:
Heather Graham, the IT Manager at Zylker Corp, relies on the CMDB to manage infrastructure and applications. One day, a critical payroll application goes down just before payroll processing, and Heather needs to assess the impact quickly.

When she opens the CMDB, she notices several issues:

The Payroll Application CI is missing key information such as the owner and version. Without this, Heather cannot quickly contact the responsible team or verify if it’s the latest deployed version.
The Windows Server hosting the payroll application hasn’t been updated or scanned for 200 days.
The SQL database supporting the payroll app is not connected to the application CI.

Heather configures data quality metrics to assess the impact.

She marks version and owner as preferred fields for a CI type in the completeness metric. The completeness metric flags this CI, prompting the IT team to update the missing details.

She configures the staleness threshold to 60 days. When the server is not updated within this period, it would be marked as stale. The IT team can then verify the server’s status and ensure it is still active.

The orphan metric flags the SQL database, revealing that the dependency mapping is incomplete. The database is then connected to the payroll application.

The IT team now ensures all CIs are complete, up-to-date, and properly connected, reducing future risk.

Configuring CI Relationships to Identify Orphaned CIs

While setting up essential relationships for a CI type to identify orphaned CIs, you can choose to specify an exact relationship type (for example, Linked to, Hosted on) and a related CI type (for example, Server, Application, Database). However, in scenarios where dependencies may vary, you also have the option to set either field to Any.

Any Relationship type: Allows any type of relationship between the CIs.
Any CI type: Allows the CI to relate to any CI type, without restricting it to a particular type.

This flexibility makes it easier to configure rules broadly while still ensuring that orphaned CIs are detected. The following examples illustrate how these options can be applied.

Scenario	Relationship type	Related CI type	Description
Every server must be linked to at least one dependent CI (like an application, database, or virtual machines).	Hosted on	Any	Servers with no dependent CIs (applications, databases, virtual machines) are flagged as orphans.
Every application, database, or virtual machine must have a relationship with a server.	Any	Server	CIs that are not in any relationship with the server are flagged as orphans.
Every virtual machine must be hosted on a physical server.	Hosted on / Runs on	Server	Virtual machines not hosted on a physical server are flagged as orphans.

Edit CI Types

From the CI types list view click the CI type or > Edit beside the CI type to modify its details.

You can modify all basic details, except Parent CI Type and API Name.

You can edit the fields but not the relationships.

You cannot edit the base CI type CMDB.

Delete CI Types

From the CI types list view click > Delete beside the CI type.

You cannot delete the base CI type CMDB.

Deleting a CI type will permanently delete its CIs, child CI Types and their CIs, its suggested relationships, relationships of all its CIs and all the user-defined fields associated with it.