CMDB Admin Configurations
The CMDB comprises configuration items (CIs), grouped under different CI types and connected by different relationships. Before you start configuring CIs and defining CI relationships, you need to first configure the CI types and the relationship types.
Click here to know about different CMDB components.
Role Required: Only administrators and technicians with SDCMDBAdmin role can access the CMDB admin configurations.
Configure CMDB roles under Setup > Users & Permissions > Roles.
Once you gain the CMDB admin access, you can configure CI types and relationship types from Setup > Customization > CMDB.
Configuration Item (CI) Types
Each Configuration Item (CI) type holds Configuration Items (CIs) with similar properties. The CI types contain fields that are specific to all CIs under that type. Say, for example, if two CI types have common fields and relationships, you can create a new parent CI type with those common fields and relationships and place both the CI types as children under that parent CI type.
- 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.
CI Types List View
Go to Setup > Customization > CMDB.
- 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.
Example: In the sample screenshot, Application is a parent CI type and if you click beside it, its children CI types Apache Instance, Database Instance, and IIS Instance are shown. - You can toggle the list view between fully expanded and fully collapsed views using the Expand/Collapse Tree button. Click the icons and to view and hide the children CI types, respectively.
- Click each CI type to view its details in a new page.
- You can define new CI types to match your business needs.
An example screenshot showing the hierarchical list view of CI Types
The list view tabulates all the available CI types along with their descriptions. You can perform the below operations from this view:
- Add New CI Types
- Edit CI Types
- Delete CI Types
Add New CI Types
Adding a CI type involves configuring the following information:
- 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.
Follow the below steps to add a CI type:
Details
From the CI Types list view click New CI Type.
In the New CI Type form displayed, complete the details as required:
Fields
| Explanation
| Example
|
Module Name*
| Provide a name for the CI type.
| Web Server
|
Parent CI Type*
| Select a parent type from the available list.
| Server
|
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. | ci_clusters , ci_windows_application, ci_linux_app_server
|
Description
| Describe the CI type.
| Web servers that host websites and deliver web content.
|
Icon
| Add an icon, if required.
| |
Click Save.
A sample 'New CI Type' form with the details of the CI type 'Web Server'
Next, you will be prompted to configure the fields.
Fields
Each CI type consists of fields that are specific to all CIs under that type. After adding CI type details, you can switch to the Fields tab and create various fields.
Examples
- 'Memory' is a field associated with the CI type 'Server/Workstation'.
- 'MAC Address', 'Operating System' and 'Processor Name' are the fields associated with the CI type 'Computer'.
- 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.
The fields tab allows you to customize fields for different CI types.
The tab has two sections: Canvas and Fields List.
The CI Type and Parent CI Type details are displayed at the top of the section.
- Additional fields can be dragged from the right pane into the canvas. The available fields will be displayed beside the New Fields column.
- You can configure Lookup fields to add departments, impact, products, sites, users, and to refer data from custom modules.
- Use New Section to organize the fields. You can modify the Section Properties. Hover over a section and click to customize the section.
Click the Fields Left link on the right pane to see the Field Metrics.
Canvas: The canvas is where you build the template. The fields of the parent and super parent CI types, if any, are inherited by the children CI types and are displayed under Parent Fields. Click
to expand the view.
As the fields under Parent Fields are inherited, you cannot edit or delete them.
Drag the available fields from the right pane onto the canvas. You can add new fields as well. Define the field by entering the required details. Click here to know in detail about each field type.
Note that you cannot set default values for the fields from the fields tab. You can set the default value only in the New Field pop up.
The Field Name is unique among the hierarchy of CI types.
A sample screenshot for new field creation
Rearrange the fields by dragging and placing them over empty cells.
Hover over a field and click,
- to edit the field
- to remove the field
,
- to expand or compress the field
After configuring the fields, click Save.
The fields configured here can be seen while creating a CI under this CI type.
Screenshot showing a few fields configured and the hover over options
Screenshot showing the configured fields viewed in the 'New CI' form
After configuring fields, you can add relationships.
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. You can view the CI type relationships while adding CI Relationships under CMDB. Child CI types inherit the relationships from parent and super parent CI types.
Example: Hosting payroll and finance applications in a single Unix workstation. The admin can create a relationship, say 'Application hosted in Unix Workstation' with cardinality "Many to One".
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 relationship 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.
|
Follow the below steps to add CI type relationship:
From the CI types list view, click a CI type for which you wish to add relationships.
- Click the Relationships tab from the left side. You will see the list view of existing relationships of the selected CI type.
- Click Add Relationship. A window pops up.
- 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 (Mandatory)
| The type of relationship shared between the Source and Related CI types. This can be either direct or inverse.
|
Related CI type (Mandatory)
| 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. In other words, cardinality defines relationships in terms of numbers. 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.
|
Screenshot showing a sample relationship added for the CI type 'Web Server'
Click Save. The new relationship will be added to the list view.
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.
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, their CIs, its suggested relationships, relationships of all its CIs, and all the user-defined fields associated with it.
Sync Rules
After configuring the CI type relationship, switch to the Sync Rules tab. Learn More.
Relationship Types
Relationship types define the nature of relationship between CIs or CI types. Each relationship type is direct when viewed from one side and inverse from the other side. For example, if the relationship type 'Managed By' is direct, 'Manages' is its inverse. The relationships between the CI types are defined by the SDCMDBAdmin.
The relationship types are used while:
- Adding a custom relationship for a CI
- Adding suggested relationships between CI types
Relationship Types List View
You can do the following actions from the list view:
Add Relationship Types
- Click New Relationship Type.
- Fill out the required details.
- Click Save.
Name and Inverse name are unique for a relationship and cannot be reused.
Edit/Delete: Click
beside the relationship type and select the required option. You cannot delete a relationship type that is in use.
Sync Rules
Sync rules define the data to be synced from assets, users, or software installations to CMDB. The synced data is populated as CIs in CMDB and linked to the corresponding asset, user, or software.
You can perform various actions on CIs and their relationships based on the synced data. Any changes made to data in the asset, user, or software installation will be reflected in the corresponding CI and vice-versa.
Sync rules will not be applied while importing assets, workstations, mobile devices, and asset components.
Role Required: SDAdmin
Create Sync Rule
- Go to Setup > Customization > CMDB > Sync Rules.
- Click New Sync Rule.
- Fill out the form using the pointers below:
Field
| Description
|
Name
| Enter the name of the sync rule.
|
Description
| Describe the sync rule purpose and usage.
|
CI Type
| Select the destination CI type where the data from the source module is synced.
|
Sync with
| Select the source module from where the data is fetched and synced as CIs. You can sync data from:
- Assets
- Users
- Software Installations
Only Managed Software of software installations can be converted as CIs using sync rules.
|
Applies to
| Select the asset or user type where the sync rule is applied.
This field is not applicable while syncing software installations as CIs.
|
Status
| Enable or disable the sync rule. Disabled sync rules cannot be executed using the Run Through option.
|
Actions
| Define actions to be performed when the sync rule is applicable:
- Create CI
- Create asset from CIs
- Map fields between CI and records in other modules
- Create relationships
- Delete CI
- Delete asset
|
- Click Save.
You can create multiple sync rules for a particular CI Type. However, if the source is Assets, then only one rule per asset type is allowed.
Sync rules are automatically applied when the asset, user, or software installation is added, updated, or deleted. You can also manually apply sync rules using the Run Through option.
Sync Rule Actions
Create CI from [x]
Create/link new CIs based on the specified condition. The CI will be created from the configured asset, software installation, or user.
- Specify the condition to apply the sync rule:
- Based on conditions - Define the criteria to apply the sync rule by selecting the column, operator, and value. Use the Add icon to define multiple criteria.
- Without condition - Apply the sync rule to all records in the selected module.
- Enable Configure default values to create CI to create CI with all details in the source module record. You can also add custom values to various CI fields by mapping them.
Create [asset] from CIs
Create/link an asset from CIs based on the specified condition. The CI data will be auto-populated in the asset; you can also map fields to populate data.
This action is applicable only when the sync rule is configured for assets.
- Specify the condition to apply the sync rule:
- Based on conditions - Define the criteria to apply the sync rule by selecting the column, operator, and value. Use the Add icon to define multiple criteria.
- Without condition - Apply sync rule to all CIs in the selected CI type.
- Enable Configure default values to create [asset] to create assets with all details in the CI. You can also add custom values to various asset fields by mapping them.
Map [x] Fields
Map the asset, software installation, or user fields with the selected CI type fields.
- Select a field in the source module.
- Select a corresponding CI Type field.
- Only fields of the same type can be mapped.
- You can map multiple fields. To add new fields to a CI Type or to know more, click here.
- Changes to Assets/ Software Installation field values will be reflected in the corresponding CIs and vice-versa. If CI Type has unique fields, then they should be mapped with the fields in Assets/Software Installation records.
- If the mapped field is non-editable, then it will not be synced.
Create Relationships
Define relationships between the CI with other CIs based on asset, user, or software installation fields.
- Select the relationship type by using predefined or custom relationship types.
- Select the destination CI type
- Select the relevant asset/ software installation field.
- Click to define multiple relationships.
The associated asset, user, or software installation must already be a CI.
Delete CI
Delete the CI when the corresponding asset, user, or software installation is removed.
Delete [asset]
Delete asset when the corresponding CI is removed. This action is applicable only when the sync rule is configured for assets.
List View Operations
- Click to edit or delete sync rules. To bulk-delete, select the sync rules and click Delete on the toolbar.
- Click Organize to set the order in which sync rules will be executed. Use and to reorder the rules and click Save.
- Click and select Run Through to execute a sync rule manually. You cannot execute sync rules manually.
- You can enable or disable existing sync rules using the toggle button under the Status column in the Sync Rules tab.
Impact
Impact is a measure of the business criticality of CMDB. Impact is often measured by the number of systems affected. Four impacts are provided by default. You can also add new impacts.
Add Impacts
- Go to Setup > Customization > CMDB > Impact.
- Click New Impact.
- Provide a name and description for the impact.
- Click Save.
Downtime Type
Downtime refers to a period of outage or unavailability of a system or service during a planned release. SDAdmins can predefine downtime types, which will be used to classify the downtimes specified in CMDB.
AssetExplorer Cloud comes with default downtime types, which you can rename based on your requirements. You can also add new downtime types.
A maximum of 50 downtime types, inclusive of default ones, is supported.
Add Downtime Type
- Go to Setup > Customization > CMDB > Downtime Type.
- Click New Downtime Type.
- Provide a name and description for the downtime type.
- Click Save.
Edit/Delete: Click
beside the downtime type and select the required option.