Modulkonfiguration
Configuration Items
Der universelle Basisdatensatz für Assets, Wissensartikel und buchbare Services — gesteuert durch Vorlagen, die bestimmen, welche Felder erscheinen.
Aktualisiert am 23. Jan. 2026
Konfiguration · Module · 4.1
Ein Configuration Item (CI) ist der universelle Basisdatensatz für alles, was Sie registrieren, das kein Ticket, keine Reservierung und keine Aufgabe ist: Unternehmens-Assets, Wissensartikel, buchbare Services. Drei verschiedene Welten in derselben Datenstruktur — unterschieden werden sie durch Klasse und Vorlage, die Sie wählen.
Warum das für das Business zählt
„Endanwender sehen 50 Felder“
Die CI-Vorlage steuert die Sichtbarkeit der Felder — es erscheinen nur die richtigen Fragen.
„Assets, Services und KB durcheinander“
Die Klasse (Asset · Service · Knowledgebase) trennt das Verhalten — verschiedene Flows, dasselbe Modul.
„Externe sehen interne Assets“
Die Vorlage ist an eine Gruppe gebunden — wer die Vorlage nicht sieht, kann das CI nicht auswählen.
„Keine konsistente Benennung“
Standardwerte + zulässige Werte in der Vorlage → Einheitlichkeit ohne Zwang.
Drei Klassen bestimmen das Verhalten
Asset
Standardobjekt ohne besondere Funktionen. Unternehmens-Asset, Fahrzeug, Softwarelizenz.
Service
Buchbares Objekt. Einschränkungen und Einschränkungsregeln legen fest, wann und von wem es gebucht werden darf.
Knowledgebase
Wissensartikel. Wird automatisch auf Tickets angezeigt, deren Titel/Klassifikation passt.
Vorlagen bestimmen, welche Fragen erscheinen
Beim Anlegen eines CI wählt die Person zuerst eine Vorlage. Diese Vorlage bestimmt: welche Felder sichtbar, welche bearbeitbar sind, den Standardwert und die zulässigen Werte.
| Standardfrage | Was sie steuert |
|---|---|
| Name · Beschreibung | Identifikation des Objekts. |
| Organisation · Standort | Wohin das CI gehört — speist Routing und Filter. |
| Klasse | Asset · Service · Knowledgebase. Steuert das Verhalten. |
| Scope | Nur Knowledgebase — wo der Artikel erscheinen darf. |
| CI-Typ | Bestimmt, welcher Workflow gilt (siehe Building Blocks → Workflows). |
| Klassifikation | Kategorisierung — speist Reporting und KB-Matching. |
| Übergeordnet · Untergeordnet | Hierarchie zwischen Objekten (z. B. Lizenz unter Anwendung). |
| Tags · Anhänge | Auffindbarkeit und verwandte Dokumente. |
Eigene Felder? Ergänzen Sie sie über Custom Fields (siehe Building Blocks).
Welche Entscheidungen treffen Sie?
Welche Vorlagen benötigen Sie?
Eine pro Registrierungstyp: Laptop, Monitor, Softwarelizenz, Meeting-Service, KB-Incident, …
Wer darf welche Vorlage nutzen?
Vorlage-Gruppen-Gate — Endanwender erhalten eine kürzere Liste als Admins.
Welche Felder blenden Sie aus?
Für die Klasse nicht relevant → unsichtbar machen, statt leer lassen.
Lohnen sich Standardwerte?
Reduzieren Tippfehler — z. B. Klassifikation für die Vorlage „Laptop“ automatisch befüllt.