In einem B2B-SaaS kann eine Einstellung für die gesamte Plattform, eine Organisation oder nur eine einzelne Person gelten. Wenn auf jeder Ebene andere Werte möglich sind und die Benutzeroberfläche nicht erklärt, welcher Wert gerade greift, entstehen unangenehme Überraschungen: Nutzer erleben unterschiedliches Verhalten, Administratoren können Richtlinien nicht zuverlässig durchsetzen und Supportteams müssen mehrdeutige Konfigurationen untersuchen.
Vererbte Einstellungen lösen dieses Problem, wenn Entscheidungen tatsächlich einer Hierarchie folgen. Ziel ist nicht, vorsorglich möglichst viele Ebenen einzuführen. Entscheidend ist vielmehr, wer für welche Einstellung zuständig sein sollte, welche Ausnahmen sinnvoll sind und wie der wirksame Wert verständlich angezeigt wird. Ein explizites Modell verhindert, dass Flexibilität zu einer schwer wartbaren Sammlung von Sonderregeln wird.
Wann sich Vererbung von Einstellungen anbietet
Vererbung ist sinnvoll, wenn zwischen den Entscheidungsebenen eine stabile Beziehung besteht. Das Produkt kann beispielsweise einen Standardwert bereitstellen. Der Administrator einer Organisation darf ihn an die eigenen Richtlinien anpassen. Einzelne Nutzer können die Einstellung für ihre Arbeit personalisieren, sofern ihre Wahl keiner verbindlichen Vorgabe der Organisation widerspricht.
Nicht jede Einstellung braucht eine Hierarchie. Ist ein Wert rein individuell und hängt nicht von einer gemeinsamen Richtlinie ab, reicht womöglich eine persönliche Präferenz. Muss er aus Sicherheitsgründen für alle gleich sein, sollte ihn vielleicht nur eine autorisierte Person innerhalb der Organisation festlegen dürfen. Unnötige Ebenen erhöhen den Aufwand für Design, Berechtigungen, Tests und Support.
Bestimme vor der Implementierung, welche Entscheidung hinter jedem Feld steht. Frage, wer dafür verantwortlich ist, wer eine Ausnahme benötigt und welche Folgen eine Änderung hat. Lässt sich das nicht klar beantworten, sollte die Einstellung zunächst einfach bleiben, bis ein konkreter Anwendungsfall die Vererbung rechtfertigt.
Ebenen danach wählen, wer entscheidet
Ein gängiges Modell unterscheidet drei Ebenen:
- Produktstandard: Er sorgt für ein einheitliches Ausgangsverhalten und gilt für Organisationen, die keinen anderen Wert festgelegt haben.
- Organisation: Der Administrator kann die Einstellung an gemeinsame Abläufe, Richtlinien oder Anforderungen anpassen.
- Nutzer: Eine individuelle Anpassung ist möglich, sofern sie der Entscheidung der Organisation nicht widerspricht.
Diese Ebenen sind nicht zwingend. Füge eine Ebene nur hinzu, wenn es eine zuständige Person gibt, die diese Entscheidung treffen muss und über die passenden Berechtigungen verfügt. In großen Organisationen kann es verschiedene Administratorrollen geben. Daraus muss jedoch keine zusätzliche Konfigurationsebene entstehen: Häufig genügt es festzulegen, wer Organisationseinstellungen bearbeiten darf.
Außerdem sollten Präferenzen und Richtlinien getrennt betrachtet werden. Bei einer Präferenz, etwa einer Anzeigeoption, ist eine individuelle Wahl meist unproblematisch. Eine Richtlinie drückt dagegen eine Vorgabe aus, die die Organisation verbindlich machen möchte. Werden beide Arten von Einstellungen verwechselt, kann eine persönliche Präferenz eine Entscheidung außer Kraft setzen, die eigentlich verpflichtend sein sollte.
Vorrang und Ausnahmen ausdrücklich festlegen
Eine leicht verständliche Regel lautet: Der jeweils spezifischste anwendbare Wert hat Vorrang – zuerst der Nutzerwert, dann der Organisationswert und schließlich der Produktstandard. Diese Regel funktioniert allerdings nur, wenn die betreffende Einstellung auf allen Ebenen überschrieben werden darf. Sicherheits- oder Compliance-Anforderungen können eine andere Logik erfordern: Die Organisation legt einen verbindlichen Wert fest, den einzelne Nutzer nicht ändern können.
Definiere den Vorrang deshalb je nach Einstellungstyp und stelle ihn nicht als allgemeingültige Zusage dar. Dokumentiere für jedes Feld den Ausgangswert, die bearbeitbaren Ebenen, die Personen mit Änderungsbefugnis und die Frage, ob eine Richtlinie Änderungen sperren kann. Benutzeroberfläche und Serverlogik müssen dieselbe Regel anwenden. Ein ausgeblendetes Steuerelement ersetzt keine Berechtigungsprüfung auf dem Server.
Wichtig ist auch die Unterscheidung zwischen „kein eigener Wert“ und „Wert entspricht dem Standard“. Im ersten Fall wird die Einstellung geerbt und kann sich ändern, wenn die übergeordnete Ebene einen neuen Wert erhält. Im zweiten Fall liegt eine ausdrückliche Auswahl vor, die erhalten bleiben sollte. Behandelt das System beide Zustände gleich, kann es weder die Herkunft des Werts korrekt erklären noch die Absicht des Nutzers bewahren.
Wirksamen Wert und Herkunft anzeigen
Administratoren müssen sowohl den aktiven Wert als auch dessen Quelle erkennen können. Wird nur das Ergebnis angezeigt, bleibt verborgen, ob es geerbt oder ausdrücklich festgelegt wurde. Ein Hinweis wie „Vom Produkt geerbt“ oder „Von der Organisation festgelegt“ macht die Herkunft sichtbar und hilft zu verstehen, was beim Bearbeiten passiert.
Biete entsprechend den jeweiligen Berechtigungen passende Aktionen an: den Wert ändern, ihn zurücksetzen und damit wieder vererben oder erfahren, warum er nicht bearbeitet werden kann. Hat die Organisation eine verbindliche Richtlinie festgelegt, sollte die Oberfläche erklären, dass die Einstellung gesperrt ist, und angeben, welche Ebene oder Rolle sie ändern darf. Vermeide Meldungen, die eine verfügbare Option suggerieren, obwohl der Nutzer sie nicht anwenden darf.
Wird eine Einstellung zurückgesetzt, sollte die Bestätigung die konkrete Folge nennen: Der Wert ist dann keine Ausnahme mehr, sondern richtet sich nach der übergeordneten Konfiguration. Kann sich die Vererbung später ändern, sollte auch das deutlich werden. So wird „Zurücksetzen“ nicht fälschlich als dauerhafte Festlegung des gerade sichtbaren Werts verstanden.
Änderungen verwalten, ohne Ausnahmen zu überschreiben
Eine Änderung des Produktstandards sollte diejenigen betreffen, die diesen Wert erben – nicht Personen, die ausdrücklich eine Ausnahme gewählt haben. Dasselbe gilt, wenn eine Organisation ihre Konfiguration ändert: Nutzer, die von ihr erben, sollten dem neuen Wert folgen. Eigene Nutzerwerte sollten sich nur ändern, wenn solche Ausnahmen zulässig sind und die Änderung eindeutig festgelegt wurde.
Ermittle vor der Einführung einer Änderung, welche Einträge geerbte Werte und welche ausdrückliche Entscheidungen darstellen. Leite die Absicht nicht allein daraus ab, dass ein gespeicherter Wert dem aktuellen Standard entspricht. Der Vererbungsstatus muss so gespeichert werden, dass das System den wirksamen Wert nach einer Aktualisierung neu berechnen kann.
Muss sich das Standardverhalten des Produkts ändern, kommuniziere, welche Gruppen betroffen sind und was mit bestehenden Ausnahmen geschieht. Wenn es angemessen ist, sollten Organisationen die Änderung prüfen können, bevor sie angewendet wird. Bei wichtigen administrativen Vorgängen sollte außerdem nachvollziehbar sein, wer eine Einstellung wann geändert hat – entsprechend dem Support- und Prüfbedarf des Produkts.
Kombinationen, Berechtigungen und Grenzfälle testen
Tests sollten mehr als nur den üblichen Wert abdecken. Prüfe die verschiedenen Kombinationen der Ebenen: Alle Werte werden geerbt, die Organisation wählt eine Option, ein Nutzer legt eine Ausnahme fest und eine Organisationsrichtlinie sperrt diese Ausnahme. Kontrolliere auch, was beim Löschen oder Zurücksetzen eines Werts sowie bei einer Änderung des übergeordneten Standards passiert.
- Berechtigungen: Stelle sicher, dass jede Rolle nur die Einstellungen sehen und bearbeiten kann, für die sie zuständig ist.
- Konsistenz: Prüfe, ob Benutzeroberfläche, APIs und interne Prozesse denselben wirksamen Wert ermitteln.
- Aktualisierungen: Vergewissere dich, dass Änderungen auf einer Ebene an deren nachgelagerte Nutzer weitergegeben werden, ohne ausdrückliche Entscheidungen zu überschreiben.
- Fehlende Daten: Lege fest, was gilt, wenn ein Wert nicht vorhanden ist oder eine ältere Konfiguration das betreffende Feld nicht enthält.
- Nachvollziehbarkeit: Prüfe, ob die Anwendung die Herkunft eines Werts und den Grund für eine Sperre anzeigen kann.
Ein Hinweis auf ein mangelhaftes Design ist, wenn der Support die Frage „Warum sieht diese Person diesen Wert?“ nur beantworten kann, indem mehrere Tabellen manuell geprüft werden. Ebenso problematisch ist es, wenn Administratoren nicht wissen, welche Nutzer von einer Änderung betroffen sind. Treten solche Fälle auf, sollten zuerst das Modell und die Anzeige der Wertherkunft überprüft werden, bevor weitere Ausnahmen hinzukommen.
Checkliste für eine wartbare Hierarchie
- Lege für jede Einstellung eine verantwortliche Person und einen Zweck fest.
- Bestimme die erforderlichen Ebenen und entferne solche, für die kein klarer Anwendungsfall besteht.
- Definiere für jedes Feld Vorrang, Berechtigungen, Sperren und Ausnahmeregeln.
- Stelle den wirksamen Wert und den Vererbungsstatus getrennt dar.
- Erkläre die Herkunft des Werts und die Folgen eines Zurücksetzens.
- Teste Änderungen auf übergeordneten Ebenen, Berechtigungen und unvollständige Konfigurationen.
- Dokumentiere, welche Ausnahmen erhalten bleiben und wie wichtige Änderungen nachvollzogen werden.
Eine gute Vererbung von Einstellungen bietet nicht möglichst viele Optionen. Sie macht verständlich, wer entscheidet, welche Werte vererbt werden und wann eine Ausnahme zulässig ist. Hat jede Einstellung eine nachvollziehbare und überprüfbare Regel, kann sich das Produkt weiterentwickeln, ohne dass seine Präferenzen ständig zu Konflikten führen.