Validator

Der Validator sorgt für Daten-Integrität. Du definierst Regeln, die prüfen, ob eine Entität bestimmte Bedingungen über ihre Beziehungen erfüllt — etwa „eine Rolle darf nicht mehr als 100 % FTE auf sich vereinen” oder „jeder Wertstrom braucht mindestens einen Verantwortlichen”. Verletzt eine Entität eine Regel, meldet der Validator das mit einer von dir formulierten Fehlermeldung.

Du erreichst den Validator über die Sidebar unter Einstellungen → System & Automatisierung → Validator (/validator). Die Seite ist nur für Tenant-Admins und Platform-Admins sichtbar.

Regeln gehören immer genau einem Mandanten. Als Tenant-Admin siehst und verwaltest du ausschließlich die Regeln deines eigenen Mandanten — auch dann, wenn du eine fremde Regel-Adresse direkt aufrufst. Nur Platform-Admins arbeiten mandantenübergreifend.

Die zwei Tabs

• Regeln — Validierungsregeln anlegen, bearbeiten, (de-)aktivieren.
• Ausführungsverlauf — jede durchgeführte Prüfung mit Ergebnis (gültig/ungültig) und den konkreten Fehlern.

Eine Regel aufbauen

Über Neue Regel öffnet sich der Editor.

Grundangaben

• Regelname und Beschreibung: zur Wiedererkennung.
• Entitätstyp: Welcher Typ geprüft wird (z.B. Rolle, Person).
• Validierungstyp: bestimmt die Logik der Prüfung (siehe unten).

Die Konfiguration muss vollständig sein: Beim Speichern prüft roleALPHA, ob der gewählte Validierungstyp alle Pflichtfelder hat. Fehlt etwas, nennt eine Meldung die offenen Felder und der Dialog bleibt offen — eine halb konfigurierte Regel würde sonst bei jeder Prüfung ins Leere laufen.

Konfiguration — gemeinsame Felder

Vier der fünf Validierungstypen arbeiten über Beziehungen und teilen sich zwei Felder (die Ausnahme ist „Feld erforderlich” — siehe unten, die prüft ein eigenes Feld der Entität und braucht diese beiden Felder nicht):

• Beziehungstyp: der Beziehungstyp, dessen Verknüpfungen betrachtet werden (z.B. EXECUTES).
• Richtung — von welchem Ende der Beziehung aus gezählt/summiert wird:
  • from — Beziehungen, bei denen die geprüfte Entität die Quelle ist.
  • to — Beziehungen, bei denen sie das Ziel ist.
  • both — Beziehungen in beide Richtungen.

Wichtig: attributePath (Attributpfad) liest einen Wert aus den Attributen der Beziehung (nicht der verknüpften Entität!). Beispiel: Wenn auf der EXECUTES-Beziehung ein Feld fte gepflegt wird, summiert der Validator über diese fte-Werte. Steht für den gewählten Beziehungstyp ein Schema bereit, kannst du das Attribut bequem aus einer Liste wählen.

Zusätzlicher Beziehungsfilter (optional)

Für alle vier beziehungsbasierten Typen kannst du zusätzlich einen Beziehungsfilter setzen: eine weitere Bedingung über die Attribute der Beziehung, die zusätzlich zu Beziehungstyp und Richtung erfüllt sein muss, damit eine Beziehung überhaupt mitzählt. Ohne Filter verhält sich die Regel exakt wie oben beschrieben — der Filter ist eine reine Einschränkung.

• Feld (der Attributname auf der Beziehung, z.B. fte), Operator und Wert — ein einzelner Vergleich.
• Beispiel: Nur EXECUTES-Beziehungen mit mindestens 0,5 FTE zählen für die Summen-Regel → Feld fte, Operator gte, Wert 0.5.
• Im Experten-Modus (Umschalter oben rechts, oder M) steht zusätzlich „Als JSON bearbeiten” zur Verfügung — damit lassen sich auch ODER/NICHT-verknüpfte oder mehrteilige Filter schreiben, die die Ein-Zeilen-Form nicht abbilden kann. Details zum JSON-Format siehe Automators „Advanced Mode”-Abschnitt — das Format ist identisch.

Verbundene Entität filtern (nur bei „Anzahl max”)

Der Beziehungsfilter oben liest ausschließlich Attribute der Beziehung selbst. Willst du stattdessen ein Feld der verbundenen Entität prüfen (z.B. ihren Organisationstyp), steht bei „Anzahl max” (count_max) zusätzlich ein Entität-Filter zur Verfügung:

• Entitätstyp der Gegenseite, Feld (im Inhalt dieser Entität) und Wert — nur Beziehungen, deren Gegenseite dieses Feld mit diesem Wert trägt, zählen mit.
• Beispiel: Eine Organigramm-Einheit darf nicht mehr als einem Unternehmen direkt untergeordnet sein → Beziehungstyp PARENT_OF, Richtung to, Max-Anzahl 1, Entität-Filter: Entitätstyp organigramm, Feld orgType, Wert Unternehmen. Mehrfache Vorgesetzte ohne Unternehmen-Beteiligung (klassisches Matrix-Reporting) bleiben davon unberührt — der Filter zählt nur Beziehungen zu Unternehmen-Entitäten. Diese Regel ist als Default für den organigramm-Modul-Entitätstyp bereits vorbereitet, siehe Organigramm.

Die fünf Validierungstypen

1. Summe max (sum_max)

Prüft, dass die Summe eines Beziehungs-Attributs ein Maximum nicht überschreitet.

• Zusätzliche Felder: Attributpfad, Max-Wert.
• Beispiel: Eine Rolle darf in Summe nicht mehr als 100 % FTE binden → Beziehungstyp EXECUTES, Richtung from, Attributpfad fte, Max-Wert 100.

2. Beziehung erforderlich (relationship_required)

Prüft eine Mindestanzahl an Beziehungen eines Typs.

• Zusätzliches Feld: Min-Anzahl.
• Beispiel: Jeder Wertstrom braucht mindestens einen Eigentümer → Beziehungstyp OWNS, Richtung to, Min-Anzahl 1.

3. Anzahl max (count_max)

Prüft eine Höchstanzahl an Beziehungen eines Typs.

• Zusätzliches Feld: Max-Anzahl.
• Beispiel: Eine Person darf höchstens 5 Rollen ausführen → Beziehungstyp EXECUTES, Richtung to, Max-Anzahl 5.

4. Eigenes Aggregat (custom_aggregate)

Die flexibelste Variante: berechnet ein Aggregat über ein Beziehungs-Attribut und vergleicht es mit einem Schwellenwert.

• Zusätzliche Felder: Attributpfad, Aggregation, Operator, Schwellenwert.
• Aggregation — wie zusammengefasst wird:

Aggregation	Bedeutung
sum	Summe aller Werte
avg	Durchschnitt
min	kleinster Wert
max	größter Wert
count	Anzahl der Werte

• Operator — wie gegen den Schwellenwert verglichen wird:

Operator	Bedeutung
gt	größer als
gte	größer oder gleich
lt	kleiner als
lte	kleiner oder gleich
eq	gleich
neq	ungleich

• Beispiel: Das Durchschnittsalter eines Teams muss mindestens 25 sein → Aggregation avg, Attributpfad alter, Operator gte, Schwellenwert 25.

5. Feld erforderlich (field_required) — Auslaufmodell

Für neue Pflichtfelder nimm das Entitätstyp-Schema: Häkchen in der Spalte Pflicht im Feld-Builder (siehe JSON-Schema für Entitätstypen). Das greift auch beim Anlegen einer Entität — was diese Regelart nie konnte, weil sie eine bereits gespeicherte Entität braucht. Bestehende Regeln laufen unverändert weiter, und der Typ bleibt wählbar, damit sie sichtbar und änderbar bleiben.

Er prüft als einziger der fünf Typen nicht die Beziehungen einer Entität, sondern ein eigenes Feld ihres Inhalts — Beziehungstyp und Richtung werden dafür ausgeblendet.

• Felder: Feld (der Feldname im Entitäts-Inhalt, z.B. firstName oder purpose) und Erforderlich (Schalter — deaktiviert lässt die Regel die Prüfung aus, ohne sie löschen zu müssen).
• Eine Entität verletzt die Regel, wenn das Feld fehlt, null ist oder nur aus Leerzeichen besteht.

Mitgelieferte Standardregeln

Einige Module bringen Standardregeln mit, die dein Mandant automatisch bekommt. Übrig ist genau eine: „Organigramm: höchstens ein übergeordnetes Unternehmen” — eine Aussage über Beziehungen, die JSON Schema nicht treffen kann.

Entscheidend ist dabei dein Schema, nicht das Modul: eine Standardregel entsteht nur, wenn das geforderte Feld im Entitätstyp-Schema deines Mandanten tatsächlich vorkommt. Fehlt es, wäre die Regel unerfüllbar und würde nur blockieren. Passt eine bereits angelegte Standardregel nicht mehr zu deinem Schema (etwa weil du ein Feld umbenannt hast), räumt die Plattform sie von selbst wieder ab.

Unberührt bleibt alles, was du selbst angefasst hast: eigene Regeln und Standardregeln, deren Konfiguration oder Fehlermeldung du geändert hast, werden nie automatisch entfernt.

Einmalige Ausnahme im August 2026: Mit der Umstellung auf das Schema-Pflichtkennzeichen wurden die mitgelieferten Pflichtfeld-Regeln zurückgezogen und der gesamte Bestand an field_required-Regeln entfernt — auch selbst angelegte. Sonst hätte dieselbe Zusage zweimal bestanden, mit zwei Meldungen und zwei Pflegeorten. Für alles Weitere gilt die Zusage oben unverändert.

Fehlermeldungen (DE / EN)

Pro Regel hinterlegst du eine deutsche und eine englische Fehlermeldung. Sie wird angezeigt, wenn die Regel verletzt wird — formuliere sie verständlich für die Endnutzer (z.B. „Die Rolle ist über 100 % ausgelastet”). Bleiben die Felder leer, erzeugt der Validator eine technische Standard-Meldung.

Wann läuft die Prüfung?

Der Validator prüft eine Entität bei der Freigabe eines Drafts sowie auf manuellen Anstoß. Verletzt der Endzustand eine Regel, erscheint der Fehler im Ausführungsverlauf. So fängst du fehlerhafte Daten ab, bevor sie wirksam werden — im Gegensatz zum Automator, der nach einem Ereignis reagiert.

Zwei Feinheiten, die im Alltag zählen:

• Beim Freigeben zählt der Entwurf, nicht der gespeicherte Stand. Ein Entwurf, der ein fehlendes Pflichtfeld gerade ergänzt, geht deshalb durch — sonst wäre ein einmal entstandener Verstoß über die Oberfläche gar nicht mehr zu beheben.
• Beim Verknüpfen zweier Entitäten prüft der Validator nur die Regeln, die eine Beziehung überhaupt verändern kann (Summen, Anzahlen, geforderte Beziehungen). Ein fehlendes Pflichtfeld an einer der beiden Entitäten blockiert die Verknüpfung nicht — es war vorher verletzt und bleibt es danach; melden tut es die Prüfung dieser Entität selbst.

Blockieren oder nur beobachten?

Jede Regel hat einen Modus:

Modus	Wirkung
Blockieren (Voreinstellung)	Verletzt der Endzustand die Regel, wird der Vorgang abgelehnt. Beim Verknüpfen wird die gerade erzeugte Beziehung wieder entfernt und die Anfrage mit einem Fehler beantwortet.
Beobachten	Die Regel wird genauso ausgewertet, der Vorgang läuft aber durch. Der Befund erscheint im Ausführungsverlauf mit dem Status Beobachtet — sichtbar, aber ohne Hindernis.

Wofür „Beobachten” gedacht ist: eine neue Anforderung einführen, ohne den Betrieb anzuhalten. Stelle die Regel zuerst auf Beobachten, sieh im Ausführungsverlauf, wie viele Datensätze sie heute verletzen würden, räume den Bestand auf — und schalte sie erst dann auf Blockieren. Andernfalls lehnt eine frisch eingeführte Pflicht sofort jede Speicherung ab, auch dort, wo niemand die Ursache kennt.

Zwei Punkte, die dabei zählen:

• Ein beobachteter Befund ist kein Fehlschlag. Der Status Beobachtet wird deshalb eigens ausgewiesen und nicht als „Ungültig” dargestellt.
• Fehlt die Angabe, gilt Blockieren. Der Modus muss ausdrücklich auf Beobachten stehen — eine bestehende Pflichtregel hört also nicht versehentlich auf zu greifen.

Wartungstipps

• Richtung bewusst wählen: from/to entscheiden, von welcher Seite aus gezählt wird. Bei gerichteten Beziehungen wie EXECUTES (Person → Rolle) macht das den Unterschied.
• Attribut muss gepflegt sein: Summen-/Aggregat-Regeln funktionieren nur, wenn das Attribut tatsächlich auf den Beziehungen gesetzt ist. Fehlt es oder ist es keine Zahl, fließt die Beziehung gar nicht in die Berechnung ein (nicht als 0) — anders als bei Reports im Aggregator, der einen fehlenden Wert defensiv als 0 wertet.
• Klare Fehlermeldungen: Endnutzer sehen die Meldung, nicht die Regel — formuliere fachlich, nicht technisch.
• Pausieren statt löschen: Über den Aktiv-Schalter legst du eine Regel vorübergehend still.

Per Assistent anlegen (rAlph)

Du kannst eine Regel auch in eigenen Worten beschreiben: Tippe im Assistenten /validator und dann z.B. „Eine Person darf an höchstens einer Kostenstelle hängen.” rAlph wandelt das in eine Regel um (hier count_max mit maxCount: 1), zeigt sie als Vorschau-Karte im Chat, und erst dein Klick auf „Regel anlegen” erstellt sie. Der Befehl ist Admins vorbehalten.

rAlph versteht dabei auch Zusatzbedingungen über Beziehungs-Attribute — z.B. „…aber nur EXECUTES-Beziehungen mit mindestens 0,5 FTE zählen” — und trägt sie direkt als Beziehungsfilter in den Vorschlag ein.

Verwandt

• rAlph – Slash-Befehle (/help, /report, /drafts) — Slash-Befehle des Assistenten
• Automator — reagiert nach Ereignissen, statt vorab zu prüfen
• Drafts – Entwürfe — Validierung greift bei der Draft-Freigabe
• Beziehungstypen — die geprüften Beziehungstypen
• Freigabe-Modi — wer Drafts freigibt, die der Validator durchlässt