Freigabe-Modi

Pro Entitätstyp lässt sich konfigurieren, wer einen Draft freigeben darf:

Liberal (Standard)

Jeder User des Tenants darf freigeben. Wenig Reibung — geeignet für Stammdaten ohne hohes Risiko.

Konsens

Die betroffenen Personen müssen aktiv zustimmen. Erst wenn genug Zustimmungen da sind, wird publiziert.

Konsent

Die betroffenen Personen müssen antworten — aber Schweigen gilt nicht. Ein Einwand blockiert. Pragmatischer als Konsens.

Beschlussfähigkeit: wie viele antworten müssen

Konsens und Konsent verlangen im Standard, dass alle Betroffenen geantwortet haben. Das ist streng — und scheitert in der Praxis an der einen Person, die im Urlaub ist.

Deshalb lässt sich je Entitätstyp eine Beschlussfähigkeit einstellen: der Anteil der Betroffenen, der geantwortet haben muss, damit überhaupt entschieden werden darf. Einstellbar von „mehr als die Hälfte” bis „alle”; ohne Einstellung gilt weiterhin „alle”.

Drei Regeln, die dabei nicht aufgeweicht werden:

• Die Schwelle sagt nur, ab wann entschieden werden darf. Welche Entscheidung gilt, regelt weiter der Modus: bei Konsens muss jede abgegebene Stimme eine Zustimmung sein, bei Konsent darf kein Einwand darunter sein.
• Ein Einwand bleibt ein Veto. Er wird durch keine Schwelle überstimmt — auch nicht, wenn schon genug andere geantwortet haben.
• Schweigen enthält sich. Es zählt weder als Zustimmung noch als Ablehnung; es verhindert nur die Beschlussfähigkeit. Eine fehlende Antwort wird nie in ein Ja umgedeutet.

Gerundet wird auf: 60 % von 5 Betroffenen sind 3, nicht 2. Das Entwurf-Detail zeigt den Stand laufend an — etwa „2 von 5 Rückmeldungen — beschlussfähig ab 3”.

Die Schwelle wird beim Einreichen festgehalten. Ändert jemand die Konfiguration danach, gilt für bereits laufende Entscheidungen weiterhin die Regel, unter der die Stimmen abgegeben wurden.

Ohne Rückfrage veröffentlichen

Bis 09/2026 wurde jede Veröffentlichung bestätigt — auch die risikoärmste. Bei einer Migration von 50 Vorhaben ist das 50-mal dieselbe Frage, auf die es nur eine Antwort gibt; danach klickt man sie überall weg, auch dort, wo sie etwas bedeutet. Eine Rückfrage, die nichts schützt, macht die Rückfragen kaputt, die etwas schützen.

Je Entitätstyp lässt sich deshalb einstellen: „Ohne Rückfrage veröffentlichen”. Sie ist für neue und bestehende Mandanten eingeschaltet.

Sie wirkt nur unter Liberal. Bei Highlander muss eine benannte Person freigeben, bei Konsens und Konsent entscheiden andere — „gilt sofort” wäre dort eine Aussage über einen Datenstand, den es noch nicht gibt. Der Schalter bleibt in diesen Modi sichtbar, aber unwirksam, und die Oberfläche sagt das ausdrücklich.

Was weiterhin fragt, unabhängig von der Einstellung:

• Löschen, Massenlöschung und Wiederherstellen
• Änderungskommentar Pflicht — ohne Dialog gäbe es keinen Ort für die Notiz
• ein Klassifikationswechsel (die Sichtbarkeit ändert sich mit)
• eine Löschung, die mehr als zehn Beziehungen mitnimmt
• jede Lage, in der roleALPHA den Freigabemodus gerade nicht kennt

Der Knopf sagt, was passiert

Er hieß früher in jeder Lage „Speichern & Veröffentlichen” — und erst ein Fehlschlag machte daraus nachträglich „eingereicht, Freigabe ausstehend”. Jetzt nennt er das Ergebnis:

Lage	Knopf	Danach
Liberal, Sie dürfen selbst freigeben	Veröffentlichen	Veröffentlicht
Änderungskommentar Pflicht	Veröffentlichen … (die drei Punkte kündigen die Rückfrage an)	Veröffentlicht
Konsens oder Konsent	Zur Abstimmung einreichen	Wartet auf Freigabe
Highlander, Sie sind nicht die benannte Person	Zur Freigabe einreichen	Wartet auf Freigabe
Anlegen unter Konsens/Konsent	Veröffentlichen	Veröffentlicht

Die letzte Zeile ist der Sonderfall: ein neuer Datensatz hängt noch an nichts, also gibt es niemanden, der betroffen wäre — er gilt sofort, auch in einem Konsens-Mandanten.

Highlander

Nur eine vorher konfigurierte Liste an Personen darf freigeben. Klassisch für sicherheitsrelevante Bereiche.

Admin-Override

tenant_admin und platform_admin können in jedem Modus freigeben. Dasselbe gilt für jede Rolle, der die übergreifende Berechtigung approval:admin zugewiesen wurde (siehe Rollen & Berechtigungen) — damit lässt sich das Freigaberecht auch ohne volle Admin-Rechte vergeben.

Der Override gilt nur im eigenen Mandanten. Wer in mehreren Tenants angemeldet sein kann, gibt nur dort frei, wo er gerade aktiv ist und die Admin-Rolle hat; für einen anderen Tenant muss er zuerst dorthin wechseln. Ausgenommen sind platform_admin und interne Systemaufrufe, die naturgemäß mandantenübergreifend arbeiten.

Administratoren können den Entwurfsschritt in der Beziehungsmatrix per Haken auch ganz überspringen.

Wo die Durchsetzung greift

Der konfigurierte Modus gilt unabhängig davon, auf welchem Weg die Freigabe ins System kommt — ein einzelnes Draft-PATCH, ein Sammel-Publish eines Szenarios oder der eigene Draft-Endpoint eines Fachservice-Moduls. Eine nicht autorisierte Freigabe lässt den Entwurf auf „submitted” stehen, statt ihn stillschweigend freizugeben oder zu verwerfen.

Wer sind die „betroffenen Personen”?

In Konsens und Konsent entscheiden nicht alle Tenant-User, sondern nur die betroffenen Personen — eine konkrete Liste von Person-UUIDs, die beim Einreichen des Drafts einmal berechnet und als Snapshot am Draft (affectedPersonUuids) gespeichert wird. „Betroffen” heißt: erreichbar im Entitäts-Graphen ausgehend von der geänderten Entität, entlang der konfigurierten Beziehungspfade.

Das Konfigurieren passiert pro Entitätstyp im Traversal-Bereich der Approval-Konfiguration (Admin → Entitätstypen → Typ → Freigabe-Modi).

Wie der Algorithmus die betroffenen Personen ermittelt

Die Traversal-Konfiguration besteht aus bis zu zwei Phasen. Jede Phase hat drei Parameter:

• relTypeIds — welche Beziehungstypen gefolgt werden (z.B. nur EXECUTES)
• hops — wie viele Schritte tief gegangen wird
• direction — forward (in Pfeilrichtung), reverse (entgegen) oder both (beide)

Schritt für Schritt

1. Startknoten: die geänderte Entität (z.B. die Rolle, deren Beschreibung geändert wurde).
2. Phase 1: vom Startknoten aus per Breitensuche traversieren, bis hops ausgeschöpft sind. Nur Kanten mit den konfigurierten relTypeIds und der konfigurierten Richtung zählen. Alle besuchten Knoten landen im „Phase-1-Ergebnis”.
3. Phase 2 (optional): die Zwischenknoten aus Phase 1 (also alle außer dem Start) werden als neue Start-Set für eine zweite Traversierung verwendet. Häufiger Einsatz: Phase 1 findet alle anwendenden Rollen, Phase 2 hängt von dort die Personen via EXECUTES-rückwärts an.
4. Personen-Filter: aus dem Endergebnis bleiben nur Knoten übrig, deren entity_type.module = "person" ist. Dedupliziert.
5. Snapshot beim Submit: die berechnete Liste wird genau einmal — beim Einreichen — am Draft gespeichert. Spätere Graph-Änderungen verändern die Liste nicht mehr.

Sonderfälle

• hops = 0 in Phase 1 → die Entität selbst wird betrachtet (Self-Approval, falls sie selbst eine Person ist). Praktisch für Person-Stammdaten: „Nur diese Person darf ihre eigenen Daten freigeben”.
• Relationship-Drafts (Beziehung anlegen/ändern): beide Endpunkte werden parallel traversiert, die Personen-Sets werden vereinigt. Der effektive Freigabe-Modus ist der strengere der beiden Endpunkt- Entitätstypen (Reihenfolge der Strenge: Highlander > Konsens > Konsent > Liberal).
• Create-Drafts ohne Scenario: die neue Entität existiert noch nicht im Graphen, das Personen-Set ist leer. In diesem Fall fällt das System automatisch auf Liberal zurück — sonst gäbe es niemanden, der zustimmen könnte.
• Keine Traversal-Phasen konfiguriert: gleiches Verhalten wie hops = 0 → nur Self-Approval möglich.

Beispiel

Konfiguration für den Entitätstyp Rolle:

Phase 1: relTypeIds = [IS_IMPLEMENTED_BY], hops = 2, direction = both
Phase 2: relTypeIds = [EXECUTES],          hops = 1, direction = reverse

Bei Änderung der Rolle „Engineering Lead” passiert:

1. Phase 1: Traversiere Eltern- und Kindrollen bis Tiefe 2 → „CTO”, „Backend Lead”, „Frontend Lead”, „Platform Lead”, …
2. Phase 2: Von diesen Rollen aus rückwärts EXECUTES → alle Personen, die eine dieser Rollen ausführen.
3. Personen-Filter: nur die Personen-Entitäten bleiben übrig.
4. Im Modus Konsens müssen alle diese Personen aktiv zustimmen, bevor der Draft veröffentlicht wird.

Verwandt

• Drafts – Entwürfe — Wie der Draft-Lebenszyklus aussieht
• Szenarien und Sammelvorschläge — Mehrere Änderungen als EIN Antrag entscheiden (dort gilt der strengste Modus aller enthaltenen Typen)
• Beziehungstypen — Die Beziehungstypen, denen das Traversal folgt
• Personen — Personen als Endknoten der Traversierung
• Sichtbarkeit — Wer überhaupt vom Draft erfährt

Wer erfährt von einer offenen Entscheidung?

In den Modi Konsens und Konsent bekommen die betroffenen Personen eine Benachrichtigung, sobald ein Entwurf eingereicht wurde — und eine Erinnerung, solange sie nicht geantwortet haben. Liberal und Highlander sind Schreibrechte und kein Freigabeverfahren; dort wartet niemand auf eine Entscheidung, also entsteht auch keine Benachrichtigung. Siehe Benachrichtigungen.