Beziehungstypen

Jede Beziehung hat einen Typ — etwa EXECUTES („führt aus”), OWNS („besitzt”) oder PARENT_OF (Hierarchie). Der Typ bestimmt:

• Welche Entitätstypen an Quelle und Ziel stehen dürfen (Constraints)
• Wie sie heißt in Vorwärts- und Rückwärtsrichtung (Übersetzungen)

Lange Listen filtern und sortieren

Wächst die Liste, findest du einen Typ über die Leiste oberhalb der Karten, statt zu scrollen:

• Suche — sucht gleichzeitig in Name, Von-Typ und Bis-Typ. Die Eingabe „Rollen” findet also auch Typen, die auf Rollen zeigen, ohne dass „Rollen” im Namen steht.
• Von-Typ / Bis-Typ — schränkt auf Typen ein, die von bzw. zu einem bestimmten Entitätstyp erlaubt sind. Typen ohne Einschränkung („Alle Typen”) erscheinen dabei bewusst mit, denn sie sind von jedem Typ aus verwendbar.
• Richtung — gerichtet oder ungerichtet.
• Attribut-Schema — nur Typen mit bzw. ohne eigene Attribute (siehe unten).
• Mandant — erscheint nur, wenn die Liste mehrere Mandanten mischt.
• Sortierung — nach Name, Von-Typ oder Bis-Typ; der Pfeil daneben dreht die Reihenfolge um.

Gesetzte Filter erscheinen als Chips unter der Leiste und lassen sich einzeln über das × oder gesammelt über Alle löschen entfernen. Rechts steht, wie viele der insgesamt vorhandenen Typen gerade angezeigt werden. Die Auswahl bleibt während der Sitzung erhalten — auch nach einem Seitenwechsel.

Forward / Backward Labels

Statt eines kryptischen Codes wie EXECUTES zeigt die UI passende Texte:

• Vorwärts: „führt aus” (Person → Rolle)
• Rückwärts: „wird ausgeführt von” (Rolle → Person)

Beide Labels sind pro Sprache pflegbar und lassen sich per KI übersetzen.

Eine Ansicht statt vier Dialogen

Die Pflege eines Beziehungstyps war auf vier Dialoge verteilt: Erstellen, Bearbeiten, „Entity-Type-Einschränkungen” — und im Platform-Admin ein vierter, der nur die Verb-Beschriftungen bearbeitbar machte. Wer die Geltung einstellen wollte, musste den einen Dialog schließen, einen anderen öffnen und den Zusammenhang im Kopf behalten.

Heute steht alles in einer dreispaltigen Ansicht — derselben im Mandanten-Admin und im Platform-Admin, denn es ist dieselbe Komponente:

Spalte	Inhalt
Stammdaten	Technischer Name, Richtung, wer schreiben darf, Benachrichtigung
Wie es heißt	Verben je Sprache und Richtung, die ausgelieferten Feldbeschriftungen zur Ansicht, das Attribut-Schema, die Bedeutung im Graphen
Wo er erlaubt ist	Alle Entitätstypen mit Kästchen für „von” und „nach”, Zähler („2 von 14 erlaubt”), Suche

Die vollständige Typliste ist Absicht: eine Auswahl hinter einem „+“-Knopf wäre der zweite Dialog durch die Hintertür.

Kein Kästchen gesetzt heißt generisch — der Typ passt dann auf jedes Paar und wird überall angeboten. Das ist ein Ausweg und keine Wahl, deshalb steht es als Merkmal neben dem Namen.

Wer einen Beziehungstyp schreiben darf

In der linken Spalte steht „Wer darf schreiben”. Die Einstellung entscheidet, wer Beziehungen dieses Typs anlegen und ändern darf — sie galt schon immer, war aber bis 09/2026 über keine Oberfläche änderbar: sie stand auf dem Wert, den die Erstprovisionierung gesetzt hatte.

Wert	Bedeutung
Eigentümer oder Admin	Administratoren, und wer eines der beiden Enden besitzt. Die Vorgabe.
Nur Admin	Nur Administratoren. Das Formularfeld bleibt sichtbar, ist für alle anderen aber gesperrt — mit Begründung.
Beteiligte	Jeder mit Schreibrecht auf beiden Modulen — ohne Eigentümerprüfung.
Nur Systemkonten	Kein Mensch darf schreiben.

Zwei der Werte tun mehr, als ihr Name sagt — und das steht deshalb an der Auswahl:

• Nur Systemkonten nimmt dem Typ sein Formularfeld. Es verschwindet ohne Meldung aus allen Masken; wer es sucht, findet es nicht wieder.
• Beteiligte ist der freizügigste Wert, nicht eine kleine Zugabe zu „Eigentümer oder Admin”: die Eigentümerprüfung entfällt vollständig, und die Selbstzuweisungs-Sperre greift nicht. Übrig bleibt allein das Schreibrecht auf den beiden Modulen — wer das hat, kann diese Beziehung an beliebigen Objekten anlegen, auch an sich selbst.

Beides tritt still ein. Deshalb steht die Folge in Bernstein unter der Auswahl, bevor gespeichert wird — und nicht als Rückfrage danach.

Die Sichtbarkeitsstufe — sie öffnet einen Zugriffspfad

Direkt unter dem Schreibrecht steht „Sichtbarkeitsstufe”. Ihr Name klingt nach einer Etikettierung; tatsächlich ist sie die folgenreichste Einstellung an einem Beziehungstyp.

Sie entscheidet, wer durch diesen Typ hindurchsehen darf. roleALPHA läuft von der angemeldeten Person aus über alle Kanten, deren Typ eine Stufe trägt — bis zu drei Schritte weit, nicht nur zum direkten Nachbarn. Wer so verbunden ist, sieht am anderen Ende vertrauliche Objekte.

Stufe	Wirkung
Keine	Der Typ gibt niemandem Einblick. Die Vorgabe.
Vertraulich	Verbundene sehen am anderen Ende Objekte der Klassifikation VERTRAULICH.
Streng vertraulich	Zusätzlich auch STRENG_VERTRAULICH — die weiteste Stufe.

Objekte der Klassifikation INTERN sind ohnehin für alle im Mandanten sichtbar; dafür braucht es keine Stufe.

Auf einem Pfad über mehrere Kanten gilt die niedrigste Stufe, über mehrere Pfade hinweg die höchste. Ein einziger großzügig eingestellter Typ kann also eine Menge öffnen, die niemand überblickt.

Die Kombination, auf die es ankommt

Eine gesetzte Stufe bringt zugleich eine Schutzsperre mit: Wer selbst an einem Ende steht, darf die Kante nicht anlegen — sonst verschaffte man sich den Zugriff selbst.

Diese Sperre entfällt, wenn das Schreibrecht auf „Beteiligte” steht. Stufe gesetzt und „Beteiligte” zusammen heißt deshalb: jeder mit Schreibrecht auf beiden Modulen kann sich selbst eine Kante geben, die ihm Einblick in vertrauliche Daten verschafft. Jede der beiden Einstellungen ist für sich vertretbar — die Warnung gilt ihrem Zusammentreffen, und die Maske zeigt sie genau dann.

Löschen: die Reibung folgt dem Schaden

Ein Beziehungstyp zu löschen ist der einzige Schreibvorgang im Objektbereich, der sofort wirkt: kein Entwurf, keine Freigabe. Dabei verschwinden in einem Zug die Geltungsregeln, alle Beziehungen dieses Typs, ihre Beteiligten und der Typ selbst.

Deshalb zwei Stufen:

• Wird der Typ von keiner Beziehung benutzt, genügt eine einfache Bestätigung. Reibung, die nichts schützt, erzieht zum Wegklicken.
• Sonst nennt die Rückfrage die Zahlen (Beziehungen, betroffene Objekte, Beteiligte, Geltungsregeln), drei Warnungen — und der technische Name muss eingetippt werden.

Die wichtigste der drei Warnungen: ein Standardtyp kommt zurück, die Beziehungen nicht. roleALPHA legt fehlende Standardtypen beim nächsten Dienst-Abgleich automatisch neu an — leer. Wer ASSIGNED_TO löscht, sieht ihn bald wieder und könnte glauben, das Löschen sei fehlgeschlagen; die Beziehungen sind trotzdem weg.

Die dritte Warnung zählt die Darstellungen, die auf den Typ zeigen: jede Kartenzeile, jede Kanban-Bahn und jeder Behälter, der ihn nennt, bleibt danach leer — ohne Fehlermeldung.

Bedeutung der Standard-Beziehungstypen

Jeder Typ hat eine feste fachliche Bedeutung — inklusive Richtung (welche Seite Quelle und welche Ziel ist). Die Richtung entscheidet, wie Hierarchien und Reihenfolgen im Explorer gezeichnet werden.

• PARENT_OF — Über-/Unterordnung zwischen Organisationseinheiten. Quelle = übergeordnete Einheit (Eltern), Ziel = untergeordnete Einheit (Kind). Zieht im Explorer den Unternehmenskasten auf und trägt den Pfad.
• CASCADING — Kaskadierung von Objectives. Quelle = übergeordnetes Objective, Ziel = untergeordnetes Objective.
• HAS_KEY_RESULT — Quelle = Objective, Ziel = Key Result.
• IS_SUBPROJECT — Ober-/Teilprojekt. Quelle = Oberprojekt, Ziel = Teilprojekt (trotz des Namens).
• DEPENDS_ON — Reihenfolge/Abhängigkeit. Die Quelle hängt vom Ziel ab, also ist das Ziel der Vorgänger und die Quelle der Nachfolger. Für „B folgt auf A” ist B die Quelle und A das Ziel. Ein Typ, zwei Module: denselben DEPENDS_ON nutzen Wertströme und IT-Landschaft. Quelle und Ziel müssen daher jeweils ein Wertstrom oder ein IT-System sein — trotz des allgemein klingenden Namens ist er kein freier Abhängigkeitstyp für beliebige Entitäten. Für Abhängigkeiten zwischen anderen Typen legst du einen eigenen Beziehungstyp an (siehe unten). Nutzt dein Mandant weder Wertströme noch EA, bleibt der Typ unbeschränkt.
• HAS_SUBPROCESS — Quelle = übergeordneter Wertstrom, Ziel = Teilstrom.
• EXECUTES (Person → Rolle), OWNS (Person → Wertstrom), RESPONSIBLE_FOR (Person/Rolle → verantwortete Entität), MEMBER_OF (Person → Organisationseinheit) und weitere modulübergreifende Typen mit jeweils fester Quelle→Ziel-Bedeutung.

Woher die Standard-Beziehungstypen kommen

Die Standardtypen legst du nicht selbst an — die Plattform gleicht sie regelmäßig gegen deinen Mandanten ab. Dabei gilt:

• Ein Standardtyp erscheint erst dann, wenn jede Seite, die er verlangt, in deinem Mandanten auch besetzt ist. AGENT_FULFILLS_ROLE (KI-Agent → Rolle) taucht also nur auf, wenn du beide Module nutzt — ohne aktives Agenten-Modul gibt es den Typ schlicht nicht.
• Nennt eine Seite mehrere Alternativen, genügt eine davon. CONTRIBUTES_TO zielt auf OKRs oder Projekte; hast du nur OKRs, entsteht der Typ mit OKR als einzigem erlaubten Ziel.
• Aktivierst du ein Modul später, kommen seine Typen beim nächsten Abgleich automatisch dazu — samt ihrer Einschränkungen. Du musst nichts nachtragen.
• Teilen sich zwei Module denselben Namen, gibt es trotzdem nur einen Beziehungstyp, und seine Einschränkungen summieren sich. DEPENDS_ON gehört zu Wertströmen und zur IT-Landschaft: nutzt du beide Module, sind Wertströme und IT-Systeme auf beiden Seiten erlaubt; nutzt du nur eines, eben nur dessen Typ.

Damit gilt: Zeigt ein Standardtyp in der Liste „Alle Typen → Alle Typen”, ist das in aller Regel kein Normalzustand, sondern ein Rest aus älteren Mandanten (bis August 2026 konnten Typen ohne ihre Einschränkungen entstehen). Du kannst solche Typen gefahrlos löschen, solange sie in keiner Beziehung verwendet werden — die Plattform legt sie nicht erneut an, solange das zugehörige Modul fehlt.

Zwei Ausnahmen sind echt und bleiben so: BELONGS_TO ist absichtlich unbeschränkt (der Notnagel, siehe unten), und DEPENDS_ON ist es in einem Mandanten, der weder Wertströme noch IT-Landschaft nutzt.

Generische Typen sind der Notnagel, nicht die Wahl

Ein Beziehungstyp kann über erlaubte Entitätstypen (Feld „Constraints”) auf bestimmte Quell- und Ziel-Typen festgelegt sein — IS_IMPLEMENTED_BY etwa auf Rolle → Rolle. Typen ohne solche Festlegung (BELONGS_TO) passen per Konstruktion auf jedes Paar; bei anderen ist nur eine Seite offen (CONTRIBUTES_TO legt das Ziel fest, die Quelle nicht). Sie sind als Platzhalter gedacht, für den Fall, dass wirklich kein fachlicher Typ passt.

Es gilt daher: Nimm immer den Typ, der beide beteiligten Entitätstypen ausdrücklich nennt. Der generische Typ ist nur der Ausweg. Zwei Gründe: Ein generischer Typ trägt keine fachliche Aussage, und er lässt die Stellen leer, die auf ihn angewiesen sind — siehe den nächsten Abschnitt.

Was passiert, wenn eine Kante fehlt

Eine Beziehung ist nicht nur eine Aussage über die Wirklichkeit — sie ist zugleich das, was die Oberfläche zeichnet. Vier Wirkungen sind möglich, und welche eine Beziehung hat, hängt an ihrem Typ:

Wirkung	Was sie tut	Was ohne sie passiert
Achse	Ordnet die Anordnung im Explorer: die Knoten werden entlang dieser Kante in Ränge gelegt.	Die beteiligten Knoten stehen unsortiert nebeneinander.
Behälter	Zieht einen Kasten um eine Entität; die verknüpften Knoten werden innerhalb seiner Grenzen gezeichnet (z.B. der Unternehmenskasten über PARENT_OF).	Die Entität steht ohne Kasten im Bild, die zugehörigen Knoten liegen daneben statt darin.
Karten-Slot	Füllt eine Zeile oder eine Avatarreihe auf der Karte (z.B. die Key Results eines Objectives über HAS_KR).	Die Zeile bleibt leer bzw. die Karte zeigt keine Gesichter.
Pfad	Trägt Pfadanzeige, Breadcrumb und Hover-Hierarchie.	Liste und Detailseite zeigen keinen Pfad zur übergeordneten Entität.

Das ist der Grund, warum eine Modellierung fachlich richtig und trotzdem unsichtbar sein kann: die Beziehung sagt das Richtige, ist aber nicht die, aus der die Karte ihre Zeile zieht. Eine Fehlermeldung gibt es dabei nicht.

Ein Beziehungstyp ohne Graph-Rolle ordnet gar nichts: seine Kante wird im Explorer in Warnfarbe als unbestimmte Kante gezeichnet. Wo du eigene Typen anlegst, gib ihnen deshalb eine Rolle (siehe „Bedeutung im Graphen”).

Wichtig: Eine fehlende Kante ist nicht automatisch ein Mangel. Eine Rolle ohne ausübende Person ist eine Vakanz, ein Wertstrom ohne Teilschritte ein Blatt. Die Frage ist nur, ob das so gemeint ist.

Der Assistent versteht die Beziehungstypen

rAlph kennt die Bedeutung und Richtung aller Beziehungstypen und ruft sie bei Bedarf ab (er muss dafür nicht raten). So wählt er beim Anlegen von Beziehungen den richtigen Typ und die richtige Richtung. Erklärst du rAlph als Admin die Bedeutung eines Typs im Chat, merkt er sie sich für den Mandanten. Plattformweit lässt sich Beziehungswissen zusätzlich im Platform-Admin unter „AI Knowledge” (Kategorie „Relationship Semantics”) pflegen.

Er kennt außerdem die Darstellungswirkung jedes Typs — also was die Kante im Bild bewirkt und was ohne sie leer bliebe. Legt er eine Beziehung an, meldet er dir gleich mit, was jetzt noch fehlt, damit die Ansicht vollständig ist. Fragst du „warum sehe ich X nicht?”, kann er den Bestand daraufhin durchsehen.

Dasselbe Wissen bekommt jede eigene KI-Anwendung, die du per OAuth an roleALPHA anbindest — sie erhält den Katalog beim Verbinden und kann ihn jederzeit erneut nachlesen. Siehe [[mcp-modellwissen|Eigene KI-Anwendung: was sie über dein Modell erfährt]].

Dieselbe Vorrangregel gilt für rAlph verbindlich: Schlägt er einen generischen Typ vor, obwohl für das Entitätstyp-Paar ein spezifischer existiert, wird der Vorschlag abgewiesen und ihm die passenden Kandidaten genannt — er korrigiert sich dann selbst. Nur wenn wirklich kein Typ passt, darf er ausdrücklich auf den generischen ausweichen. Die Constraints, die du hier pflegst, steuern damit unmittelbar, was rAlph vorschlagen darf.

Kommt in deinem Mandanten eine Verknüpfung häufig vor, für die es noch keinen passenden Typ gibt, lege lieber einen eigenen Beziehungstyp mit Constraints an, als dauerhaft BELONGS_TO zu verwenden.

Attribute einer Beziehung (Feld „Schema”)

Ein Beziehungstyp kann optional eigene Attribute mitbringen — etwa einen Prozentsatz oder eine Notiz an jeder Beziehung dieses Typs. Definiert werden sie im Feld Schema als JSON Schema:

{
  "type": "object",
  "properties": {
    "note": { "type": "string", "title": "Notiz" },
    "share": { "type": "number", "title": "Anteil in %" }
  }
}

Erst dann erscheint beim Anlegen und Bearbeiten einer Beziehung ein Attributformular — in der Schnellverknüpfung, in der Beziehungsliste, im Graph und beim CSV-Import als zusätzliche Zielspalten. Ohne Attribute bleibt das Feld leer und es wird schlicht kein Formular angezeigt.

Achtung: In demselben Feld liegen auch die Bedeutung des Typs (Schlüssel de / en, siehe oben) und die Beteiligten-Konfiguration (Schlüssel participants, siehe Personen hinter einer Rolle zuordnen). Wer den Inhalt komplett überschreibt, verliert beides. Ergänze Attribute daher, statt den vorhandenen Inhalt zu ersetzen.

Einen Attributwert an der Linie zeigen (x-edge-attrs)

Manche Attribute sagen im Bild mehr als im Formular: bei einer Beteiligung ist es der Anteil, bei einer Lieferbeziehung die Menge. Welche das sind, sagst du im selben Feld Schema:

{
  "properties": {
    "percentage": { "type": "number", "title": "Anteil (%)" }
  },
  "x-edge-attrs": [{ "field": "percentage", "einheit": "%" }]
}

An der Linie im Explorer steht dann „hält Anteile an · 51 %”.

• field — der Name eines Attributs dieses Schemas. Ein Name, den es dort nicht gibt, wird beim Speichern abgelehnt: die Linie bliebe sonst für immer stumm, und niemand fände den Grund.
• einheit — optional, steht hinter dem Wert. Ohne sie stünde dort eine nackte Zahl, und „51” an einer Beteiligung ist zweideutig.
• Es ist eine Liste — mehrere Werte werden mit · verbunden.

Drei Dinge, die dabei gelten:

• Ohne Deklaration erscheint nichts. Alle Attribute ungefragt anzuschreiben machte jedes dichte Bild unlesbar.
• Ein fehlender Wert ergibt keinen Eintrag — nicht etwa „undefined %”. 0 und false sind dagegen Werte und werden gezeigt.
• Die Anwenderin kann es abschalten: im Explorer unter Einstellungen, als eigener Schalter neben den Beziehungsnamen.

Die Kompetenzstufen — und warum Umsortieren gefährlich ist

Drei Beziehungstypen tragen eine Stufe als Attribut: hat Kompetenz (Mensch → Kompetenz), nutzt Kompetenz (KI-Agent → Kompetenz) und erfordert (Bedarf → Kompetenz). Die Auswahlliste dieser Stufe ist die Kompetenzskala des Mandanten — sie steht im Feld Schema des jeweiligen Typs, ist beliebig lang und frei benannt:

{
  "type": "object",
  "properties": {
    "level": {
      "type": "string",
      "title": "Stufe",
      "enum": ["Grundlagen", "Fortgeschritten", "Erfahren", "Experte"]
    }
  }
}

Drei, fünf, sieben oder zehn Stufen — der Abgleich rechnet rein über die Position in dieser Liste. Es ist kein Code und keine Migration nötig, um die Skala zu ändern.

Die Reihenfolge ist die Bedeutung. Wer das enum umsortiert, ändert rückwirkend jede Deckungsaussage im Mandanten: aus „erfüllt” wird „unter Stufe” und umgekehrt, ohne dass sich an einem einzigen Datensatz etwas geändert hätte. Es gibt keinen Verlauf, der den alten Stand bewahrt. Eine Stufe umzubenennen ist dagegen abgesichert (die vorhandenen Werte werden mitgezogen).

Zwei Regeln, ohne die der Abgleich still falsch wird:

• Alle drei Typen brauchen dasselbe enum. Sonst würden Positionen aus verschiedenen Skalen verglichen — das Ergebnis wäre plausibel und falsch. Weichen sie ab, sagt der Abgleich ausdrücklich „nicht vergleichbar” und erfindet kein Ergebnis.
• Ein Wert, der nicht in der Liste steht (Altbestand, Import, umbenannte Stufe), gilt als nicht vergleichbar — nie als niedrigste Stufe.

Eigene Beziehungstypen

Als Tenant-Admin kannst du neue Typen anlegen. Beachte:

• Setze sinnvolle Constraints — sonst kann jede Entität mit jeder verknüpft werden.
• Pflege Labels für DE und EN.
• Beschreibe die Bedeutung inklusive Richtung (Quelle → Ziel), damit der Assistent den Typ korrekt verwendet.

Welche Beziehungstypen die Hierarchie bilden

Pfadanzeige, Breadcrumb und der Klammer-Zusatz in Beziehungslisten leiten die Über-/Unterordnung aus diesen Typen ab:

Typ	Modul	Orientierung
PARENT_OF	Organigramm	Quelle = übergeordnete Einheit
IS_IMPLEMENTED_BY	Rollen	Quelle = Kreis/Oberrolle
CASCADING	OKR	Quelle = übergeordnetes Objective
IS_SUBPROJECT	Projekte	Quelle = Oberprojekt
HAS_SUBPROCESS	Wertströme	Quelle = übergeordneter Wertstrom
PART_OF	Kompetenzen	umgekehrt: Quelle = Teil-Kompetenz (Kind)

Nicht als Hierarchie gewertet werden Abhängigkeiten (DEPENDS_ON) und Key-Result-Beziehungen (HAS_KR) — sie verbinden zwar gleichartige Entitäten, drücken aber keine Über-/Unterordnung aus.

Modellierst du eine Hierarchie mit einem eigenen Beziehungstyp, zeichnet die Rollen-Kreisansicht die Kreise weiterhin, Pfad und Klammer-Zusatz bleiben aber leer. Nutze für Hierarchien daher die Typen oben.

Bedeutung im Graphen

Jeder Beziehungstyp sagt, welche Rolle er im Graphen spielt. Die Angabe steht im Bearbeiten-Dialog unter „Bedeutung im Graphen” und entscheidet, wie die Kante gezeichnet wird:

Achsen ordnen die Knoten an:

Klasse	Bedeutung	Beispiel
Zerlegung (Quelle übergeordnet)	Das Ziel ist Teil der Quelle	PARENT_OF, HAS_SUBPROCESS
Zerlegung (Quelle untergeordnet)	Die Quelle ist Teil des Ziels	PART_OF
Reihenfolge	Die Quelle folgt dem Ziel	DEPENDS_ON

Querverbindungen verbinden die Achsen, ohne die Anordnung zu bestimmen:

Klasse	Bedeutung	Beispiel
Zuweisung	Jemand übernimmt etwas	EXECUTES, ASSIGNED_TO
Verantwortung	Jemand verantwortet oder entscheidet	RESPONSIBLE_FOR, DECIDES_ON
Zugehörigkeit	Etwas gehört zu einer Gruppe	MEMBER_OF, INVOLVES
Geltung und Wirkung	Etwas gilt für, bindet, mindert oder betrifft	APPLIES_TO, AFFECTS, MITIGATED_BY
Mittel und Beitrag	Etwas führt Geld, Rollen oder Beitrag zu	FUNDS, REQUIRES_ROLE, CONTRIBUTES_TO
Können und Stützung	Etwas wird gefordert, besessen oder gestützt	REQUIRES, HAS_COMPETENCE, SUPPORTED_BY

Für die mitgelieferten Typen ist die Klasse bereits hinterlegt — die Auswahl steht dort auf „Automatisch bestimmen” und muss nicht angefasst werden.

Wichtig wird sie bei eigenen Beziehungstypen. Ohne Angabe versucht das System, die Bedeutung aus dem Namen zu erraten, und das geht in beide Richtungen schief: Ein Typ namens „Vorbereitung” wird nicht als Reihenfolge erkannt und ordnet die Schritte nicht; ein Typ namens „Subvention” landet wegen der Zeichenfolge „sub” in der Hierarchie. Wer einen eigenen Typ anlegt, sollte die Klasse deshalb setzen.

Wer darf Beziehungstypen ändern?

Beziehungstypen sind das Fachvokabular des Mandanten — sie anzulegen, zu ändern, übersetzen zu lassen oder zu löschen setzt admin:tenant voraus (Rolle Tenant-Admin oder eine eigene Rolle mit dieser Berechtigung, siehe Rollen & Berechtigungen). Löschen wirkt kaskadierend: die Beziehungen dieses Typs verschwinden mit.

Lesen darf jede angemeldete Person — ohne die Typen könnte keine Ansicht eine Beziehung benennen.

Benachrichtigung bei Änderungen

Je Beziehungstyp lässt sich einstellen, ob eine Änderung am einen Ende das andere Ende benachrichtigt. Damit sagt die Verwaltung einmal, was sonst jeder Einzelne über Beobachten abonnieren müsste: „Ändert sich ein Wertstrom, erfährt es die Rolle, die ihn verantwortet.”

Vier Möglichkeiten:

Einstellung	Bedeutung
Niemanden benachrichtigen	Voreinstellung. Änderungen bleiben still.
Ändert sich die Quelle, erfährt es das Ziel	z.B. ändert sich die Person, erfährt es die Rolle, die sie ausführt
Ändert sich das Ziel, erfährt es die Quelle	z.B. ändert sich der Wertstrom, erfährt es die verantwortliche Rolle
In beide Richtungen	beides

Die Richtung wird aus Sicht des geänderten Objekts gelesen — „Quelle” und „Ziel” sind die beiden Enden der Beziehung, so wie sie angelegt wurde.

Benachrichtigt wird nicht das Objekt am anderen Ende (das ist ja keine Person), sondern wer dafür zuständig ist: die verantwortliche Person — auch wenn die Verantwortung über eine Rolle läuft — und alle, die das Objekt beobachten. Findet sich niemand, entsteht keine Benachrichtigung.

Drei Grenzen, damit daraus kein Lärm wird:

• Voreinstellung ist aus. Bestehende Beziehungstypen ändern ihr Verhalten nicht.
• Mehrere Änderungen innerhalb einer Stunde ergeben einen Hinweis, nicht zwanzig.
• Hat ein Objekt sehr viele Beziehungen, wird der Empfängerkreis begrenzt.

Wer die geänderte Entität nicht sehen darf, wird nicht benachrichtigt. Und wie jede Art lässt sich auch diese in den eigenen Benachrichtigungs-Einstellungen stummschalten.

Verwandt

• Beziehungen verstehen — Wie Beziehungen entstehen
• Entitätstypen — Worauf sich Constraints beziehen