How Can We Help?

CMDB Configuration

 
The module “CMDB” contains all the information necessary to manage the CIs.
There are 3 key concepts to understand the module:

  • CMDB Classes: the classes of objects managed by the CMDB. It is important to define the classes to organize our CMDB.
    Every class represents a macro-family of CIs, for example: Locations, Devices, Services, Customers, etc.
  • CMDB Types: every class can be organized into types. Types are sub-sets of elements, for example for the class “Devices” we can define types like: Computers, Servers, Mobile Devices, etc.
  • CMDB Sub-Types: every type can be organized into sub-types. Subtyped represents a specific set of elements, for example for the Type “Devices -> Computers” we can define sub-types like: Workstations, Laptops, etc.

Notice that only classes are mandatory in Deepser, so if a user wants to define only one level of elements he can use classes, avoiding the use of types and sub-types.
Users that need a more in-depth analysis and categorization of their CIs can use just classes and types.
The use of classes, types and sub-types can be done only for certain (very specific) kinds of CIs (eg: Devices -> Computers > Laptops) but an organization that doesn’t need an accurate level of separation, could use just “Devices > Laptops” or “Devices -> Computers”.

 
Once defined the CMDB Classes, Types and Sub-Types a user can start inserting or updating his CIs.

The CMDB managements of Deepser is very flexible. Every moment a user can insert new Classes or Types (or Sub-Types) to adapt the software to the organization and the objects managed by it.

CIs are the real records that represent the objects (elements) of the CMDB.
Every CI has one Class well defined (and optionally a Type and a Sub-Type), so every CI in Deepser is related to one (and only one) Class.
Every CI contains data: the name of the element, the owner user or company, the business impact, priority, urgency, category, etc.
We will see in the next sections how to configure and edit the CMDB.

 


Insert a new Class

To insert a new CMDB Class, go to menu System > CMDB Configuration > Class.

 

We will see the grid with all the CMDB Classes already in the system.

 
To add a new Class click the button Add Class upper on the right.

 

We will see the form to create a new Class.

 

We list all the fields and their meaning:

 

Field Meaning
Name The name of the Class, it will be displayed in the “CMDB” menu and in the select-boxes of the CMDB module.
Status If disabled, the CMDB Class will not be displayed in the system and no new CI of that Class can be inserted.
Position The position of the Class in the menu CMDB and in the select-boxes. Using this numeric field we can sort the CMDB Classes.
Icon Icon that we will see in the grids and in the menus.
Groups User groups that can access the CMDB CIs with that Class.

Once inserted a new CMDB Class, the corresponding item will be displayed on the Navigation Menu, under the item CMDB.

 

By clicking on the item we will access the grid with all CIs of that Class, initially empty.

 


Insert a new Type

To insert a new CMDB Type, go to menu System > CMDB Configuration > Type.

 

We will see the grid with all the CMDB Types already in the system.

To add a new Type click the button Add Type upper on the right.

We will see the form to create a new Type.

 

We list all the fields and their meaning:

 

Field Meaning
Name The name of the Type, it will be displayed in the select-boxes of the CMDB module.
Status If disabled, the CMDB Type will not be displayed in the system and no new CI of that Type can be inserted.
Position The position of the Type in the select-boxes. Using this numeric field we can sort the CMDB Types.
Icon Icon that we will see in the grids.
Class The parent Class of the Type.

 


Insert a new Sub-Type

To insert a new CMDB Sub-Type, go to menu System > CMDB Configuration > Subtype.

 

We will see the grid with all the CMDB Sub-Types already in the system:

To add a new Sub-Type click the button Add Subtype upper on the right.

We will see the form to create a new Sub-Type.

 

We list all the fields and their meaning:

 

Field Meaning
Name The name of the Sub-Type, it will be displayed in the select-boxes of the CMDB module.
Status If disabled, the CMDB Sub-Type will not be displayed in the system and no new CI of that Sub-Type can be inserted.
Position The position of the Sub-Type in the select-boxes. Using this numeric field we can sort the CMDB Sub-Type.
Icon Icon that we will see in the grids.
Type The parent “Class – Type” of the Sub-Type.

 


Insert a CI

Once defined the CMDB Classes, Types and Sub-Types (only Classes are mandatory) we can start to insert the records of our CMDB: in Deepser (following the ITIL methodology) we call them CIs.

 
Note: the word CI is common in the ITIL methodology. For ITIL, infact, the CI is the configuration item (Wikipedia): the fundamental structural unit of a CMDB. Examples of CIs include documents, software, models, and licenses. The CMDB oversees the life of the CIs through a combination of processes and tools by implementing and enabling the fundamental elements of identification, change management, status accounting, and audits. The CMDB aims to avoid the introduction of errors related to lack of testing as well as of incompatibilities with other CIs.
The term “configuration item” can be applied to anything designated for the application of the elements of configuration management and treated as a single entity in the CMDB.

 

CIs can be accessed by the menu CMDB.

 


As said before, Deepser creates dynamically the items corresponding to the CMDB Classes, so to see a grid with all the Cis of a certain Class click the icon of that Class in the menu.
An exception is the item CMDB > All that lists all the CIs in the system, without filtering the Class.
This item is useful when a user (operator) has to audit different classes of CIs and needs to understand the records with higher impact or owned by a specific company without filtering the class.

 

We can create CIs in different ways:

  • Manually from the Back-end: we will explore this method in this chapter. The operator that manages the CMDB can insert all the data from the back-end.
  • By the Email Integration: it is possible to supply a mailbox to create CIs. Deepser parses the emails of that mailbox and creates a CI record.
  • By the API Integration: Deepser can be integrated using its native REST API. Other systems (monitoring, other service desk tools, other CMDB tools) can create records.

 


Insert CIs from the back-end portal

An operator that audits the CMDB or a Service Manager can insert manually the CIs, using the back-end portal.
To insert a new CI, click the menu CMDB > All and then upper on the right click the button Add Ci.

In the popup that appears, select the Class of the CI.

 

We will access the form to insert a new CI.

 

Tip: to expand fullscreen the main screen with the form of the CI, click the blue button upper on the left near the global search textbox.

 

The structure of the default screen of every CI is organized like that:

 

  1. Buttons to edit the form and to select the template: we will explain that in the advanced Form Templates guide.
  2. Tabs: using Tabs we can change the main screen of the form. We can see display fields on different tabs.
  3. Main screen of the CI: the main screen of the CI varies depending on the selected Tab and it contains the Fieldsets.
  4. Fieldsets: a set of fields, included in a frame. All the fields of the CI are inside Fieldsets.
  5. Action Buttons: to save, reset the data, etc. The difference between the button Save and the button Apply is that the button Save updates the record and redirects to the CI grid, while with the Apply button we stay inside the CI form.

 


CI Tabs

The default form of the CI is divided into tabs, each containing specific data to help the data inspection and insertion by a back-end operator:

 

Default tabs have this meaning:

  1. Main Data: main data of the record like CI name, description, status, business impact, priority, urgency, category.
  2. Users Details: details of the users, like assigned company, assigned group, assigned user, owner company, etc.
  3. Activities: activities and file attachments.
  4. Relations: relations with other CIs.

It is possibile to modify entirely the CI form, with the configuration of form templates.

 


Meaning of the fields in the CI form

We list all the fields of the CI and their meaning

 

Field Meaning
Name The name of the CI. Usually a brief description.
Type The type of the CI. It is a very important value to manage the organization of the CMDB.
Subtype The Subtype of the CI. It is a very important value to manage the organization of the CMDB.
Category The category of the CI. It can be used according to the category of the Service module, in order to link Operations and CIs.
Description Large description of the CI.
Status The status of the CI. It is an important value to manage the lifecycle of the element.
Priority Priority of the CI from the operator perspective.
Urgency Urgency of the CI from the requester user perspective.
Business Impact Business Impact of the CI from the organization perspective. If a CI is not available, the business impact represents the enormity of the situation and can be in terms of people, finances, systems, etc. For example, it can describe: the number of people affected by the CI outage or the potencial financial losses, or the number of other systems affected.
Serial Number The serial number of the CI.
Notes Large Notes field.
Front Image The main image of the CI.
Back Image The back image of the CI. For example, if the CI is a rack, we can take a photo of the back side in order to see the connections or the cables.
Assigned Company Company that has taken in charge the CI. It is typically a Service Provider Company that has to monitor the CI. This field is very important to give the right visibility on the CIs. If a user has company restricted visibility, he cannot see CIs of other companies. Notice that a user with restricted company visibility can always see both CIs with its company in the Assigned Company OR Owner Company field.
Assigned Group User Group that has taken in charge the CI. It is typically a Service Provider Group of agents/key users that has to monitor the CI. This field can be left blank if there is no specific group assigned to the CI, otherwise it can be used to restrict permissions to groups.
Assigned User The users who has taken in charge the CI. It is typically a Service Provider agent/key user that has to monitor the CI. This field can be left blank if there is no specific user assigned to the CI, otherwise it can be used to restrict permissions to single users.
Owner Company Company that is the owner of the CI. It is typically a Customer Company that uses the CI. This field is very important to give the right visibility on the CIs. If a user has company restricted visibility, he cannot see CIs of other companies. Notice that a user with restricted company visibility can always see both CIs with its company in the Assigned Company OR Owner Company field.
Owner Group User Group that owns the CI. It is typically a Customer or User Group of end users that can open requests on the CI. This field can be left blank if there is no specific group that owns the CI, otherwise it can be used to restrict permissions to groups (eg: when a user submits a request it could link only CIs owned by his user group).
Owner User User that owns the CI. It is typically a Customer or end user who can open requests on the CI. This field can be left blank if there is no specific user that owns the CI, otherwise it can be used to restrict permissions to users (eg: when a user submits a request it could link only CIs owned by himself).
Version The version of the CI. Deepser stores in its DataBase every version of the CIs. We can always know the changes, the user that made a change and the date.
Created At Creation date of the record.
Updated At Date of the last update on the system.
Updated By The user that has lat updated the CI.
Attachments File attachments of the CI.
Activities The activities (comments or worklogs) planned or reported. Comments let you communicate with the other users. Worklogs keep track of the time spent to solve an incident on the CI or to document internal activities.

 


Status of the CI

A very important field of the CMDB CIs is the status.
The status represents where the lifecycle of the CI has arrived.
Statuses are editable, accessing the System > Tools > Lists.

 

We have a system list with all CI statuses: CMDB CI Status. The modification of that list must be done by an expert user or with the help of a Deepser consultant.

 

Every status can be associated to a class that represents a set of values.
Default classes for status are:

 

Class Meaning
Active The statuses belonging to this class mean that the CI is in use.
Inactive The statuses belonging to this class mean that the CI is not in use, but could be used in the future (eg: a CI in stock or a service suspended for a while).
Deleted The statuses belonging to this class mean that the CI has been soft-deleted from the DataBase, for example if we want to keep track of the CIs that have reached the End Of Life, but we don’t want to lose the association with relations or service requests linked to the CI.

Default values of the status field have this meaning:

 

Status Class Meaning
Active Active The CI has been inserted into the system and is in use.
In Stock Inactive CI in stock, for future use.
Decommissioned Inactive Decommissioned CIs that are still in the organization offices.
Deleted Deleted The CI has been removed from the organization and we want to keep track of its lifecycle, so we don’t delete it from the DB.

 


Category of the CI

We have seen at the beginning of this chapter that CIs must be firstly organized by their Classes and Types.
For example, a CI can be a Software or a Device and then we can define if that Device is a Computer or a Server, and so on.
Certain organizations have the need to link the CIs to the Operations in order to assign a right category to a request or an incident, for example, when a CI is linked to the request.
For that, Deepser uses the Category: an entity associated to every CI and Operations, in order to identify their scope.
We can define a category commonly used by the Service and CMDB module and then, when a CI is linked to an Operation, that Operation inherits the category of the CI.
Categories configuration has been already showed in this guide. Notice that guide mainly refers to the categories for the Service Module, but the configuration is the same for the CMDB module.

Table of Contents