Entitätstypen

Jeder Tenant hat eine Menge an Entitätstypen — z.B. „Person”, „Rolle”, „Wertstrom”. Sie werden beim ersten Start aus deiner Subscription abgeleitet und können von Admins angepasst werden.

Anlegen: Name-Pflicht bei manchen Typen

Bei einigen Entitätstypen (z.B. Wertstrom, Rolle, Organigramm, IT-Landschaft) ist ein Name Pflicht. Im Anlegen-Dialog ist das Namensfeld dann mit einem * markiert, und die Schaltflächen Als Entwurf speichern und Speichern & Veröffentlichen bleiben so lange deaktiviert (ausgegraut), bis du einen Namen eingegeben hast. Ein kurzer Hinweis unter den Schaltflächen erinnert dich daran. Sobald ein Name im Feld steht, werden die Schaltflächen aktiv.

Was zu einem Entitätstyp gehört

• Schema (JSON Schema): welche Felder die Entitäten haben
• Modul: zu welchem Fachservice der Typ gehört
• Sichtbarkeit: Standard-Sichtbarkeitsregeln

Modul gesetzt oder geändert? Dann zieht die Plattform die zugehörigen Beziehungstypen automatisch nach — beim Anlegen ebenso wie beim nachträglichen Wechsel des Moduls, jeweils mit den passenden Einschränkungen. Umgekehrt entsteht ein Beziehungstyp erst, wenn beide Seiten, die er verlangt, einen Entitätstyp haben.

Mehrere Typen in einem Modul

Ein Modul darf mehrere Entitätstypen führen — etwa „Prozess” und „Gate” in der Wertschöpfung. Jeder Typ hat sein eigenes Schema, seine eigenen Pflichtfelder und seine eigene Darstellung.

• Anlegen: Hat ein Modul mehr als einen Typ, wird der Knopf auf der Modulseite zu Neu ▾ und fragt, welcher Typ entstehen soll. Formular und Pflichtfelder kommen dann vom gewählten Typ, und der Datensatz entsteht genau als dieser Typ. Bei nur einem Typ bleibt alles wie gewohnt.
• Beschriftung: Titel und Detailkopf nennen den Typ („Gate anlegen”, „Gate bearbeiten”), ebenso die Entwurfsliste, die Freigabe und die Vorschläge des KI-Assistenten.
• Bearbeiten: Ein Datensatz wird immer gegen das Schema seines Typs geprüft.
• Beziehungen: Ein weiterer Typ bekommt automatisch dieselben Beziehungsmöglichkeiten wie der Haupttyp des Moduls. Ein Gate kann also genauso DEPENDS_ON tragen wie ein Prozess.
• Konnektor-Sperre: Verwaltet ein Konnektor einen Typ, greift die Sperre für genau diesen Typ. Ist beim Speichern kein Typ bekannt, gilt das Modul als gesperrt, sobald einer seiner Typen gesperrt ist.
• Felder und Karte des Haupttyps werden beim Start nicht in einen weiteren Typ übertragen.
• Auch die übrigen Wege halten den Typ fest: das Anlegen im Explorer, der CSV-Import, die Vorlagen eines Typs, der KI-Assistent und angebundene KI-Anwendungen. Wer keinen Typ angibt (z.B. ein Konnektor), bekommt den ersten Typ des Moduls.
• Bestehende Datensätze behalten ihren Typ; einen Datensatz nachträglich in einen anderen Typ umzuwandeln, ist nicht vorgesehen.

Lange Listen filtern und sortieren

Oberhalb der Liste steht dieselbe Leiste wie bei den Beziehungstypen: Die Suche greift auf Name, Modul und API-Endpunkt zu, die Facette Modul schränkt auf einen Fachservice ein (inkl. „Ohne Modul”), und die Sortierung ordnet nach Name oder Modul — der Pfeil dreht die Reihenfolge um. Gesetzte Filter erscheinen als Chips und lassen sich einzeln oder gesammelt entfernen; die Auswahl bleibt während der Sitzung erhalten.

Eigene Felder hinzufügen

Im Entitätstyp-Editor kannst du das Schema erweitern. Welche Optionen das Schema kennt — Pflichtfelder, Dropdowns, Textareas, bedingte Felder — beschreibt [[entity-type-schema|JSON-Schema für Entitätstypen]]. Felder, die als [[view-mode|wichtig für die Normalansicht]] markiert sind, erscheinen prominent in der Detailansicht.

Darstellung & Sichtbarkeit pro Feld

Der Dialog ist dreispaltig aufgebaut: links die Stammdaten, in der Mitte der JSON-Schema-Editor und rechts eine Feld-Tabelle mit einer Zeile pro Schema-Feld. In dieser Tabelle konfigurierst du zwei Dinge gemeinsam:

• Darstellung — wie ein Wert im Normalmodus gerendert wird (Text, Badge, Währung, Datum, Fortschrittsbalken …). Auswahl per Dropdown pro Feld.

• Sichtbarkeit — ob ein Feld im Normalmodus erscheint. Ein Drei-Wege-Toggle pro Feld:

  Zustand	Bedeutung
  Standard	Heuristik entscheidet (technische Felder wie _-Präfix oder UUID-Felder werden automatisch verborgen)
  Zeigen	Feld ist im Normalmodus immer sichtbar
  Verbergen	Feld ist im Normalmodus immer verborgen

Beide Einstellungen werden direkt im Schema des Entitätstyps gespeichert (x-presentation und x-visibility) und gemeinsam mit dem Entitätstyp gesichert — es gibt keine separate Seite mehr. Plattform-Admins konfigurieren dieselbe Tabelle pro Tenant unter Plattform-Admin → Services.

Tipp: Sobald du mindestens ein Feld auf Zeigen stellst, wechselt der Normalmodus für diesen Entitätstyp in einen „nur diese Felder”-Modus — alle übrigen Felder sind dann verborgen, sofern nicht ebenfalls auf Zeigen gesetzt.

Die Darstellung wirkt teils auch auf das Eingabeformular: Ein string-Feld mit der Darstellung Bild bekommt einen Upload, eines mit Icon eine durchsuchbare Icon-Auswahl statt eines Textfeldes, und die Datums-Darstellungen schalten einen Date-Picker frei. Details in JSON-Schema für Entitätstypen.

Embedding-/Semantik-Index-Status

Neben dem API- und MCP-Status zeigt jede Fachservice-Zeile den Embedding-Status der semantischen Suche. Er dient vor allem der Störungserkennung und ist nur für Admins sichtbar. Eine Ampel fasst den Zustand zusammen:

Ampel	Bedeutung
OK	Semantischer Index aktuell und vollständig
Warnung	Index unvollständig, veraltet oder gekappt (Limit erreicht)
Fehler	Embedding-Anbieter konfiguriert, aber der letzte Lauf schlug fehl
Nur lexikalisch	Kein Embedding-Anbieter konfiguriert → Wortsuche als Fallback
Nicht erreichbar	Der Fachservice antwortet nicht (mögliche Störung)

Über die Schaltfläche neben der Ampel öffnet sich ein Popup mit Details (Anbieter, Modell, Abdeckung, indexierte Einträge, letzte Aktualisierung, letzte Prüfung). Plattform-Admins sehen denselben Status tenant-übergreifend unter Plattform-Admin → Services.

Die Vektoren werden je Fachservice in dessen eigener Datenbank persistiert — ein Neustart löst also kein teures Neu-Embedding aus.

Wann der Index gebaut wird

Der Index entsteht nicht von selbst im Hintergrund und auch nicht beim Anlegen oder Ändern einer Entität. Es gibt genau zwei Auslöser:

1. Die erste semantische Suche. Sucht jemand semantisch — auch über den Assistenten rAlph —, baut der Fachservice den fehlenden Index im selben Vorgang auf und sucht anschließend darin. Es gehen also keine Treffer verloren, aber diese erste Suche dauert spürbar länger und verursacht einmalig Kosten beim KI-Anbieter, weil alle Einträge des Typs auf einmal eingebettet werden.
2. Der Reindex-Knopf neben der Ampel. Damit lässt sich der Aufbau bewusst vorziehen, etwa nach einem Import oder einer Wiederherstellung, statt ihn die erste Suchanfrage bezahlen zu lassen.

Daraus folgt, was Warnung in der Praxis meist bedeutet: Der Index wurde für diesen Typ schlicht noch nie gebaut (im Detail-Popup steht dann 0 von N indexiert). Das ist kein Fehler und keine Fehlkonfiguration — es verschwindet, sobald jemand semantisch sucht oder der Reindex läuft.

Ändert sich später nichts mehr an den Daten, schreibt ein Index-Lauf auch nichts Neues. Deshalb unterscheidet das Detail-Popup zwei Zeitpunkte: Zuletzt aktualisiert ist der letzte tatsächlich berechnete Vektor, Zuletzt geprüft der letzte Lauf, der den Index als vollständig bestätigt hat. Für „veraltet” zählt die Prüfung — ein gepflegter Index, an dem sich nichts ändert, bleibt also grün.

Ein Reindex mit der Option vollständig neu aufbauen verwirft alle vorhandenen Vektoren und berechnet sie neu. Das kostet den vollen Betrag beim KI-Anbieter und ist nur nötig, wenn der Index nachweislich falsch ist — für Lücken genügt der normale Reindex.

Ohne freigegebenen KI-Anbieter steht der Typ auf Nur lexikalisch. Häufigste Ursache ist nicht ein fehlender Schlüssel, sondern dass das Modul in den KI-Einstellungen nicht für die KI freigegeben ist (siehe rAlph – Slash-Befehle (/help, /report, /drafts)). Die Suche funktioniert dann stichwortbasiert weiter.

Wer darf Entitätstypen ändern?

Ein Entitätstyp ist der Bauplan einer Datenart — ihn anzulegen, zu ändern, sein Schema zu migrieren oder ihn zu löschen setzt admin:tenant voraus (Rolle Tenant-Admin oder eine eigene Rolle mit dieser Berechtigung, siehe Rollen & Berechtigungen). Das gilt auch für die Schema-Vorschau, weil sie die vollständige Feldstruktur zeigt. Die Migration schreibt in die Daten des Fachservice, das Löschen wirkt kaskadierend.

Lesen darf jede angemeldete Person — jede Liste und jede Detailansicht braucht den Typ, um Felder überhaupt beschriften zu können.

Vorlagen des Typs

Neben dem Schema kannst du je Entitätstyp eine kleine Bibliothek von Vorlagen pflegen: Muster-Entitäten, die es fachlich gibt, die aber bewusst nicht zur Organisationsstruktur gehören. Der Knopf mit dem Bibliotheks-Symbol in der Aktionsleiste der Typ-Karte öffnet sie. Siehe Vorlagen (nicht assoziierte Entitäten).

Verwandt

• JSON-Schema für Entitätstypen — Alle Schema-Optionen im Detail
• Customer ID — Lesbare Kennung pro Entität
• Beziehungen verstehen — Wie Entitäten verknüpft werden