Configuration Items (CIs) represent any component within your organization that you want to track, manage, and connect. A CI can be anything, from a single pencil or laptop to a jet plane.
Each CI helps you build a structured, dynamic view of your organization’s infrastructure and services, allowing you to understand how everything is connected and how changes in one area might impact another.
CIs are the foundation of your Configuration Management Database (CMDB), a centralized system that stores detailed information about all configuration items and their relationships. With the CI API, you can create, update, retrieve, and delete CIs programmatically, ensuring your CMDB remains accurate and up-to-date across all systems.
Why use CIs?
- Flexibility: Define your own CI types and attributes. Whether you’re managing a fleet of company cars or virtual machines in the cloud, the CI structure adapts to your organization’s needs.
- Complete visibility: Track every component that makes up your IT ecosystem — hardware, software, users, documents, contracts, or even non-technical assets.
- Better impact analysis: Understand dependencies between systems and how an issue or change in one CI may affect others.
- Automation and synchronization: Keep your CMDB consistent by integrating with external systems or discovery tools via the API.
CI Properties
The following properties are available for all CIs:
| Property | Type | Description | Required |
|---|---|---|---|
id | integer | Unique identifier of the CI. | Yes |
name | string | Name of the CI. | Yes |
ciTypeId | integer | Type identifier for the CI. | Yes |
serialNumber | string | Serial number of the CI. | No |
ciSubtypeId | integer | Sub-type identifier for the CI. | No |
primaryCategoryId | string | Primary category ID of the CI. | No |
secondaryCategoryId | string | Secondary category ID, providing further classification. | No |
thirdLevelCategoryId | string | Tertiary classification ID of the CI. | No |
ownerId | string | Username of the user who owns the CI. | No |
ownerGroupId | string | Group name of the user who owns the CI. | No |
locationId | integer | Identifier of the CI’s location. | No |
companyId | integer | Identifier of the company the CI is assigned to. | No |
statusId | integer | Identifier of the CI’s status. | No |
priorityId | integer | Identifier of the CI’s priority level. | No |
supplierId | integer | Identifier of the supplier of the CI. | No |
supplyDate | string | Date when the CI was supplied (ISO date). | No |
acceptDate | string | Date when the CI was accepted from the supplier (ISO date). | No |
version | integer | Version number of the CI object. | No |
CI Relations
CIs can be linked through relationships to model how they interact and depend on each other.
These relationships exist entirely within your Configuration Items (CIs), independent of how physical assets are managed or discovered through network tools.
Together, they build a logical map of your environment’s topology, showing how each component interacts with others at the configuration level.
Relation Types
SysAid includes several predefined CI relation types that describe common relationships between CIs.
Each relation type includes two directions - the affecting relation and its affected counterpart, which define how one CI relates to another.
For example, if a server hosts a database, the relation type “Hosts / Hosted on” defines this relationship, with the server being the affecting CI and the database being the affected CI.
Each predefined relation type defines two directions: how one CI affects another and how that CI is affected in return. The table below lists the predefined relation types available in SysAid by default:
| Affecting Relation → | ← Affected By Relation |
|---|---|
| Consists | Part of |
| Installed on | Contains SW (Software) |
| Hosts | Hosted on |
| Covers | Is covered by |
| Provided to | Receives |
| Owns | Owned by |
When creating a Relation Type, you specify two components:
- Relation name: Describes the relationship in one direction (e.g., hosts).
- Opposite relation name: Describes the inverse of that relationship (e.g., hosted by).
Both components are required, but their wording is completely flexible. You can define them in any way that fits your organization’s terminology or business domain.
You can then use these relation types to create or delete relationships between any two Configuration Items (CIs) via the API.
Please note:
In the Service Desk Portal, both base and opposite relations are displayed for each CI.
However, only the base relations are returned when retrieving relations through the API.
For example, a database instance may depend on a virtual machine, which in turn runs on a cloud infrastructure service. A business application may also interface with a configuration file or API endpoint.
You can use the CI Relations API to:
- Create, view, or delete relationships between CIs.
- Understand which items are affecting or affected by others.
- Model complex infrastructure and service dependencies.
CI Relation Properties
| Property | Type | Description |
|---|---|---|
relationTypeId | integer | The unique ID of the CI relation type. |
relationName | string | Base CI relation name. |
oppositeRelationName | string | Opposite CI relation name. |