Module configuration
Configuration items
The universal base record for assets, knowledge articles and reservable services — driven by templates that decide which fields appear.
Updated Jan 23, 2026
Configuration · Modules · 4.1
A configuration item (CI) is the universal base record for anything you register that isn’t a ticket, reservation or task: company assets, knowledge articles, reservable services. Three different worlds in the same data structure — what sets them apart is the class and the template you pick.
Why this matters to the business
"End user faces 50 fields"
The CI template drives field visibility — only the right questions appear.
"Assets, services and KB mixed up"
Class (Asset · Service · Knowledgebase) splits behaviour — different flows, same module.
"External parties see internal assets"
The template ties to a group — anyone who can't see the template can't pick the CI.
"No consistent naming"
Default values + allowed values in the template → uniformity without forcing it.
Three classes drive behaviour
Asset
Standard object with no special functions. Company asset, vehicle, software licence.
Service
Reservable object. Restrictions and restriction rules decide when and by whom it can be booked.
Knowledgebase
Knowledge article. Shown automatically on tickets whose title/classification matches.
Templates drive which questions appear
When creating a CI the user first picks a template. That template decides: which fields are visible, which are editable, the default value, and the allowed values.
| Standard question | What it drives |
|---|---|
| Name · Description | Identification of the object. |
| Organization · Location | Where the CI belongs — feeds routing and filters. |
| Class | Asset · Service · Knowledgebase. Drives behaviour. |
| Scope | Knowledgebase only — where the article is allowed to appear. |
| CI type | Decides which workflow applies (see Building Blocks → Workflows). |
| Classification | Categorisation — feeds reporting and KB matching. |
| Parent · Child | Hierarchy between objects (e.g. licence sits under application). |
| Tags · Attachments | Discoverability and related documents. |
Custom fields? Add them via custom fields (see Building Blocks).
Which decisions will you make?
Which templates do you need?
One per registration type: laptop, monitor, software licence, meeting service, KB incident, …
Who is allowed to use which template?
Template-group gate — end users get a shorter list than admins.
Which fields do you hide?
Not relevant for the class → make invisible instead of leaving empty.
Default values worthwhile?
Reduce typos — e.g. classification auto-filled for the "Laptop" template.