The CMDB is where you record the things your organization runs on, and the connections between them. Each thing you record is a configuration item, or CI, and each connection between two CIs is a relation.
A CI can be almost anything physical, from a pencil to a jet plane, and what makes it worth recording is the connections rather than the count. A jet engine is part of an aircraft, and the maintenance software that certifies that engine is installed on two laptops in the hangar: record those relations, and you can answer on one page which aircraft can't be signed off if both laptops fail.
Once your CIs and relations exist, you can open any CI and see what it depends on, what depends on it, and which service records are already open against it. That is what lets you judge the real impact of a failure before you start working on it.
How it works
A CMDB has two moving parts. CIs are the records, one per thing you track. Relations connect them, and every relation has a direction: one CI affects the other, and the other is affected by it. Because relations carry direction, SysAid can trace the chain outwards from whichever CI you open, through as many hops as it takes.
To work with your CIs, go to Asset Manager > CI List.
To set up the types, relation types, templates, and imports behind them, go to Settings > Setup & Monitoring > CMDB.
What a CI is
A CI is anything worth tracking on its own and connecting to the rest of your service management data. For IT teams, that usually means workstations, servers, network devices, and software. It doesn't have to be IT equipment: HR teams track onboarding equipment and company vehicles, Facilities teams track buildings and service centers, and Finance teams track contracts and leased equipment tied to renewal dates.
Recording these as CIs rather than in a spreadsheet means you can see how they relate to each other, which laptop belongs to which employee or which contract covers which software, attach service records to the item they actually affect, and report across all of it from one place.
What a CI is made of
Part | What it does |
|---|---|
Type | Decides which fields the CI form shows. Every CI has one. |
Sub type | Classifies CIs further within a type, and can carry its own form view and icon. Optional. |
Relations | Connect this CI to other CIs, each in a direction: affecting or affected by. |
Fields | The details you record on the CI itself, on its General Details tab. |
Because CI types differ so much from one another, each type and sub type can have its own set of fields on the CI form. Alongside the standard fields, CIs carry custom text, number, date, and list fields that you can rename to match what your organization actually tracks, so a vehicle CI and a contract CI can each hold their own details without affecting the other. See Edit CI Properties for the fields available and how to rename them, and Modifying Forms (Design Form) for how to change which ones appear.
CI types and sub types
A CI type is what classifies a CI and determines what its form looks like. SysAid includes six predefined types, marked Yes in the Predefined column on the CI Types page so you can always tell them from the ones your organization added:
ID | CI type |
|---|---|
1 | Asset |
2 | Software Product |
3 | Catalog |
51 | Company |
52 | End User |
53 | Administrator |
Predefined types can't be edited or deleted. You can add as many of your own as you need, and a type can represent anything you want to track: alongside the IT types, customers create types for vehicles, buildings, business processes, documents, and lines of business. To add or edit types, see CI Type List.
Please note:
Predefined IDs aren't consecutive. They run 1, 2, 3, then 51, 52, 53. This matters when you build a CSV for Importing CIs from a Delimited File, which identifies each CI's type by ID.
Sub types classify CIs further within a single type. The Asset type ships with a set of sub types covering the usual hardware, and you can add your own to any type. See CI Sub Types.
Every predefined type and sub type has its own icon. A CI type you create yourself uses a generic icon instead. To give your own type a specific icon, create a sub type under it, set the icon on the sub type, and make sure new CIs of that type use the sub type as well.
CI relationships
Every relation type is a pair of opposite phrasings, one per direction. Software is installed on a server, and that server contains the software. On the CI Relation Types page the two halves appear as Affecting relation and Affected by relation.
SysAid includes three predefined relation types:
ID | Affecting relation | Affected by relation |
|---|---|---|
1 | Consists | Part of |
2 | Installed on | Contains SW |
6 | Hosts | Hosted on |
Like predefined types, these can't be edited or deleted, and their IDs aren't consecutive either. To add your own, see CI Relation Types.
Relations between computers, the software installed on them, and their matching catalog items can be created for you in bulk. Every other relation you create yourself, either on a CI's CI Relations tab or in bulk from a CSV. See Importing CIs Overview.
Where the CMDB shows up
Once your CIs and relations exist, the relation graph is available in several places:
On a CI, the CI Relations Graph tab. See Edit CI Properties.
On an asset, the CMDB tab, which shows the CI representing that asset and how it connects to everything else. See Viewing and Editing an Asset.
On a task, the Business Impact tab shows the task's Main CI and that CI's relations. See Task Form.
Attaching service records to CIs is what makes the graph worth reading, because it shows you which parts of the chain already have work open against them. The Main CI field records which CI a service record or task is about. Add that field to a form using the design form icon, see Modifying Forms (Design Form). Once Main CI is on the request submission form, End Users can set it themselves when they submit, choosing from the CIs they're listed on as owner or user. Import Settings can attach service records to the right CI automatically.
Reading the graph is how a routine request turns out not to be routine. A workstation comes in with usability problems, normal priority. Its graph shows one software CI attached to no other computer, so that workstation is the only place the software runs. That software is attached to a business process CI for the company newsletter, and the newsletter goes out on the 15th. It's the 14th. The request is now urgent, and nothing on the request itself said so.
Access and permissions
Two permissions govern the CMDB:
View CMDB lets an Agent see CIs. Clear it and that Agent sees no CIs at all.
Modify CMDB lets an Agent create and edit CIs, CI templates, and CI types.
One thing to know beyond those two: Restrict access for blocks an Agent from selected SysAid pages on top of every other permission, so an Agent who has both CMDB permissions can still be kept off the CMDB pages. It's available in the Full Edition.
See Managing Agent and Admin Permissions.
Limitations
Predefined CI types and relation types can't be edited or deleted, and their IDs aren't consecutive.
Automatic CI creation isn't retroactive. Turning it on covers System Items created from that point onwards, so the first time you enable it you still need to run the import once to backfill. See Import Settings.
The relation graph draws only the direction you select. If the direction you pick has no relations, the CI appears on its own even when relations exist in the other direction.
CI relations and Links to Other Items are separate mechanisms. Links you create under Links to Other Items don't appear on the relation graph, and CI relations aren't copied into Links to Other Items. There are cases where you'll want to record the same connection in both.
Next steps
Setting up a CMDB runs in this order, because each stage depends on the one before it:
Define anything you need beyond the predefined sets, so you don't create something that already exists: CI Type List, CI Sub Types, CI Relation Types.
Create the CIs. Importing CIs Overview covers every route in, whether the items already exist in SysAid or arrive from a CSV. For many near-identical CIs at once, use CI Templates instead.
Relate the CIs to each other. Both ends of a relation have to exist first, since relations reference CI IDs. See Importing CI Relations.
Attach service records, using the Main CI field or Import Settings, so the graph reflects work actually open against your CIs.
To browse and edit the CIs themselves once they exist, see Configuration Items List.