Configuration Items

The Configuration Items table holds records containing information about your company's Configuration Items (assets). It may include CIs that are in inventory and not in service, as well as all assets that are in service.  

Configuration Item Creation

Staff may add a configuration item (CI) manually to the system by creating a new record, or integrated discovery systems may create CI records automatically with specified attributes. Configuration Items have type-specific attribute fields (Manufacturer, Model, Serial Number, etc.) and relationships to other CIs, Service Requests, Incidents, Problems, Change Requests, and Releases.

Related Service Requests, Incidents, Problems, Change Requests, Releases and Tasks are displayed as lists of records within a CI, so the history of a given CI is readily available. Events and a CI Change Log are also shown there. 

Configuration Items may also be related to other CIs by creating records in the CI Relationships table.

Configuration Items Layout

The tabs and fields in the Configuration Items table are described below.

Common Area

The common area at the top of the form includes the critical information about the configuration item: its name, its operational status and criticality, its general status, and its ownership.

CI common area.

The icon next to the Relationship Diagram field can be clicked to show a graphical display of the relationships between this CI and others. For instance, the CI representing the Email/Calendaring/Slack business service uses the Slack Company Account and Requires a server, which in turn uses four components.

The options for Status are Installed, In Maintenance, In Stock, On Order, Pending Install, Stolen, and Retired.

Details Tab

The Details tab shows the other basic information about the configuration item.

CI Type can be set to any of the following options: Hardware, Software, Service, Networking, Documentation, Furniture or Fixture, Other, and None. Each CI Type, except None, has an associated list of CI Subtypes to choose from. For example, the CI Subtypes for the CI Type of Software are:

  • Database Application
  • Database Instance
  • Desktop Application
  • Enterprise Application
  • Google Search Appliance
  • Infrastructure Software
  • Operating System
  • Other Application
  • Web-Based Cloud Service Application
  • Web Server Application
  • Web Service.

Additional information that can be entered for a CI includes the CI Tag, Serial Number, CI Role and Description, Manufacturer, Vendor, Item Name/Number, and Item Description. The latter two fields are selected from linked records in the Catalog Items table, and this pulls in any data sheets or pricing information stored in the Catalog item record.

If the CI has a CI-specific SLA, that can be selected in the SLA section.  Any CI-Subtype-specific fields are displayed below the SLA section, and the responsible team is also defined there.

Knowledge articles related to a configuration item can be searched for and selected in the Relevant Knowledge Articles table by clicking on the lookup icon.  This allows the system to be used to store user manuals or other documentation and link them to the configuration items to which they apply.

Service / Contracts Tab

This tab shows information about the purchase price and dates, as well as any suppport contract or maintenance information.

Usage / Relationships Tab

This tab shows any relationships created between this configuration item and other configuration items.  Click New to create a new relationship.

Related Configuration Items related table.

It also includes information about the location of the configuration item and, if assigned to a user, the user's name and information.

Requests / Work Done Tab

This tab contains an append-only notes field for any running notes about the configuration item, as well as information about related incidents, service requests, problem requests, change requests, releases, and tasks done.

Changes / Events Tab

This tab contains information about any change freezes, the CI change log, baselines, and any related events, if you are using the Event Management functionality.  The Change Freeze Information section can be used to indicate that changes should not be made to this CI during a certain period of time. User permissions to edit these records can then be filtered to only allow editing if the CI is not frozen.

Agiloft can be integrated with an asset polling system, and any changes made through this integration can be captured automatically with change logs. The information tracked includes the date/time the changes were made and the field values before and after the change. This information is stored in a change log record linked to the CI that was modified.

To add a new baseline, click New in the action bar of the Baselines table (this table will not be visible if you have turned off the ITIL Function for Baselines). This opens a new baseline record that is automatically linked to the CI.

Baseline screen.

Emails and History Tabs

These are standard tab with any emails sent about the CI and information about when the CI was created and updated, who created and last updated it, and all changes made to fields. It also contains the CI Version, which can be set to auto-increment if certain fields in the CI record change.

Configuration Item Lifecycle

Configuration Items follow a lifecycle workflow from ordering through retirement.  Configuration Items are created in the state of Installed by default.

Configuration Items that are requested but not immediately available might be created in a state of On Order, moved to In Stock when the Configuration Item is received, Pending Install while Operations is tasked with installing the Configuration Item, and finally Installed. Installed Configuration Items can change to In Maintenance for repairs and Retired or Stolen when the Configuration Item is no longer in use.


Workflow diagram shows states On Order, In Stock, Pending Install, In Maintenance, Stolen, Retired, and Installed (default).


Configuration Item ownership is defined as the user whose Login matches the User Login field in the Configuration Item record.

Integration with CMS and CMDBs

All Service Requests, Change Requests, Incidents, and Problems are fully integrated with the Configuration Management Database (CMDB). Every Configuration Item displays a related table for each request type, showing all of the Requests that the Configuration Item was included in. With the appropriate permissions, a user can easily open the Configuration Item from any of the Requests related to it, and view other related Requests to help identify, investigate, diagnose, and eliminate problems/issues more easily.

Each Configuration Item is also linked to a parent Catalog Item, and it is possible to display all of the other Configuration Items for that Catalog Item in the Configuration Management System (CMS).

Automation and Notifications

The following automation is configured for Configuration Items: 

  • When a configuration item is created, if it was created from an Item Requested (it was ordered and is marked as received there and then converted to create a CI), it writes back its ID to the Item Requested and if its status is marked as Installed, it sets the status of the Item Requested to Installed.
  • If the item has an Operating system defined, i.e., it is a computer and has been linked to an OS configuration item, a CI relationship is automatically created linking the OS to the CI.
  • A general edit rule handles several updates.  It interacts with event management to send appropriate notifications when an outage or outage resolution event occurs.
  • If the Operational status changes to Unplanned outage, whether manually or by an event, this triggers an immediate browser popup and sends an email to the CI Responsible Team and the System Admin Team about the outage.  If the CI's Criticality was High or Critical, it also sends an sms message to the team's notification numbers.
  • If the Operational Status changes from Unplanned Outage to Working, whether manually or by an outage resolution event, notifications will be sent to the same people as for the outage, but with a resolution message telling people the outage has been resolved.

Using the CI Change Log

There is another rule, disabled by default, that handles automatic creation of records in the CI Change Log table.  This rule will only work once some global variables are customized.  It runs a python script that logs changes to specific fields in a configuration item.  This is only available for the Enterprise edition.

When enabled, this rule runs a script that generates one CI Change Log record for each change to a tracked field to show the old value, the new value, and the date/time/person who made the change. It also increments the CI Version field by .1 each time one of the tracked fields is changed.

The fields tracked by default are:

  • CI Name
  • CPU
  • Hostname
  • IP Address
  • Memory
  • Number of Licenses
  • Operating System
  • Ownership
  • Version

These fields are configured and mapped in a global variable and can be changed at any time to include newly created fields. The other details needed by the script are also set in global variables and can be changed as needed without having to modify the script. 

In order to set up the system to be able to run this script, change the highlighted global variables (go to Setup > System > Manage Global Variables):

  • CIChangeHostname must be changed to the hostname for your KB, i.e. 
  • CIChangeFieldsMap can be changed if you want to track different fields.  This provides a map of the field name in the configuration items table followed by the label to be displayed to represent the field in the CI Change Log.  You can add more fields or remove fields here.
  • CIChangeKBName must be changed to the name of your KB.

Unless you make other changes, you should not need to modify the remaining variables.  The user whose login is cichange is used by the script to create the CI Change record.  That user's password is defined as the CIChangePassword variable.  And the table name is the name for the CI Change Log table.

Once you have updated the variables, go to the rules for Configuration Items and review and enable the rule called "zDisabled - Edit: CI - Create CI Changes (web or API)."  If you have changed which fields should be tracked, you may need to change the search condition for the rule as well.

Global Variables screen.

Charts and Reports

The Configuration Items table has the following pre-built charts and reports:

  • All Configuration Items by Status, sorted by count
  • CI's purchased in the past 12 months with cost
  • CIs with Change Logs in last 90 days
  • CIs with change requests in last 90 days
  • Configuration Items by CI Subtype
  • Configuration Items by CI Type
  • Maintenance Report -CI's With Problems or Maintenance Time
  • Number of In Stock CIs by CI Type then subtype
  • Number of Installed CIs by CI Type then subtype
  • Service Due within next 3 Months

Several of these reports are described in more detail below.

Report NameDescription

CIs Purchased in the Past 12 Months with Cost

This report shows the sum of the purchase cost for CIs per month purchased, for all CIs purchased in the past year. It has a both a graphical chart and a report component.

Number of In Stock CIs by CI Type and then Subtype

This report outputs information about the number of CIs that are In Stock, grouping them by CI Type and Subtype. It has a chart component and a report component.

CIs with Change Requests in last 90 days

This report provides a list of all CIs that were involved in change requests completed in the last 90 days.

Maintenance Report - CIs With Problems or Maintenance Time

This report shows the CIs that have been associated with at least one problem record and which have spent more than 1 hour in maintenance.

CIs with Change Logs in last 90 days

This report displays CIs that have been updated in the past 90 days. This is useful when integrating with an asset polling system to see all CIs that were modified through the integration recently.

  • No labels