Einführungen
Mandanten-Management und Corporate-Identity: Multi-Client Element-System
Verwalten Sie Templates, Komponenten, Standardwerte und weitere Elemente für verschiedene Mandanten mit zentraler Kontrolle und individuellen Anpassungen sowie Corporate-Identity-Varianten
Das Mandanten-Management von Output.Rocks ermöglicht es Ihnen, mehrere Umgebungs-Mandanten innerhalb einer Output.Rocks-Instanz zu verwalten.
Dies ist besonders nützlich für:
- Versorger mit mehreren Marken (z.B. Regionalmarken)
- Dienstleister, die Elemente für verschiedene Kunden verwalten
- Konzerne mit dezentralen Geschäftsbereichen
- Service-Provider, die White-Label-Lösungen anbieten
Element-Typen, ihre Vererbung und Sichtbarkeiten
Das System unterscheidet zwischen zwei Element-Typen: vererbbar Standardelemente für alle Mandanten eines Accounts und private Elemente für einen bestimmten Mandanten, unterscheidbar durch zwei Icon-Symbole:
| 'ID' Icon | Element-Typ | 'Mandant' Spalte | 'Standard für Umgebungs-Mandanten' Spalte |
|---|---|---|---|
Nutzer-Elemente (Priorität 1) | Null | NO | |
Mandant-spezifische Elemente (Verwaltungsansicht) | (ID) Name des Mandanten | NO | |
Standard-Element (Priorität 2) | Null | YES |
Icon-Symbolik:
= Vererbung an alle Mandanten
= Privat für einen bestimmten Mandanten (eigenes Element oder von einem spezifischen Mandanten)
Hierarchie-Ebenen
Es gibt dabei nur zwei Hierarchie-Ebenen pro Output.Rocks-Kunde:
- Hauptmandant (Master-Ebene mit voller Übersicht)
- Beliebig viele Umgebungs-Mandanten (Eine Ebene darunter, beschränkte Sicht)
Sichtbarkeits-Unterschiede zwischen Haupt- und Umgebungs-Mandanten:
Als untergeordneter Umgebungs-Mandant sehen Sie:
- ✅ Eigene Elemente als private und geerbte Standard-Elemente
- ✅ Nur eigene Testdaten-Sets für spezifische Template-Tests
- ❌ KEINE 'Umgebungs-Mandanten' Spalte in Element-Übersichten und keine Elemente anderer Umgebungs-Mandanten
Als Hauptmandant sehen Sie:
- ✅ Eigene Elemente und verwaltbare, zu vererbende Standard-Elemente
- ✅ Zusätzlich die 'Umgebungs-Mandanten' Spalte mit allen Elementen aller Umgebungs-Mandanten
- ✅ Alle Testdaten-Sets aller Mandanten für umfassende Template-Tests
Unterstützte Element-Typen
Das Mandantensystem funktioniert für folgende Output.Rocks Elemente:
| Element-Typ | Vererbbare Standards | Mandant-Zuweisung |
|---|---|---|
| Templates | ✅ | ✅ |
| Vorlagenkomponenten | ✅ | ✅ |
| Standardwerte | ✅ | ✅ |
| Bilder | ✅ | ✅ |
| QR-Codes | ✅ | ✅ |
| Validierungen | ✅ | ✅ |
| Diagramme | ✅ | ✅ |
| E-Mail-Vorlagen | ✅ | ✅ |
| E-Mail-Anhänge | ✅ | ✅ |
| Benutzerdefinierte Zugangsdaten | ✅ | ✅ |
| Webhooks | ✅ | ✅ |
| Formular(masken) | ❌ | ✅ |
| API-Token | ❌ | ✅ |
| Benutzer | ❌ | ✅ |
| Testdaten-Sets | ❌ | ✅ |
Standard-Elemente und private Mandant-Elemente
Output.Rocks implementiert eine intelligente Element-Vererbung, bei der Standard-Elemente automatisch an alle Umgebungs-Mandanten vererbt werden.
Aber eigens erstellte private Mandant-Elemente haben Vorrang vor Standard-Elementen. Das bedeutet, dass ein Umgebungs-Mandant sein eigenes, privates Element statt des geerbten Standard-Elements verwendet, wenn es den gleichen Identifier (oder Gruppenidentifier) hat wie ein Standard-Element.
Vererbung und Überschreibung
1. Vererbung: Standard-Elemente stehen automatisch allen Umgebungs-Mandanten zur Verfügung
2. Überschreibung: Sobald ein Mandant ein eigenes Element mit identischem Identifier erstellt, wird das Standard-Element beim Rendering ignoriert
Beispiel:
• Hauptmandant: Verteilt Vorlage kundenrechnung (Standard )
• Umgebungs-Mandant: Erstellt eigene kundenrechnung (eigenes Element)
• Rendering-Ergebnis: eigenes Mandant-Template wird verwendet, Standard-Template wird ignoriert
Identifier-Logik: Die Überschreibung funktioniert auch mit Gruppenidentifiern bei Template-Komponenten und Standardwerten. Ein privates Element mit identischem Gruppenidentifier überschreibt alle Standard-Elemente dieser Gruppe.
Praktisches Anwendungsbeispiel
Szenario: Energieversorgungsgruppe mit Regionalmarken
Mandant Sicht: Stadtwerke Nord
Vorlagen
| ID | Identifier | Gruppen-Identifier |
|---|---|---|
6390 | agb_aktualisierung | Null |
6357 | agb_aktualisierung | Null |
Vorlagenkomponenten
| ID | Identifier | Gruppen-Identifier |
|---|---|---|
2105 | footer_stadtwerkeNord | footer |
2098 | footer_standard | footer |
Standardwerte
| ID | Identifier | Gruppen-Identifier |
|---|---|---|
1205 | datenschutzbeauftragter | Null |
1210 | firmenname | Null |
Bilder
| ID | Identifier | Gruppen-Identifier |
|---|---|---|
890 | firmen_logo | Null |
885 | firmen_logo | Null |
Das System kombiniert automatisch Elemente nach Priorität. Nutzer müssen nicht alle Komponenten neu definieren - das System nutzt intelligent die verfügbaren Fallback-Ebenen.
Marken und Mandanten: zwei Achsen
Umgebungs-Mandanten strukturieren Organisation und Vererbung von Elementen (Standard vs. mandantenspezifisch). Marken definieren zusätzlich Corporate-Identity-Varianten auf Client-Ebene: Zu einem Rendering-Request wird passend zur Nutzlast eine Marke ermittelt; markenfähige Vorlagen-Elemente können pro Marke unterschiedliche Inhalte bereitstellen. Marken ersetzen Untermandanten nicht — sie ergänzen sie, etwa für besondere CI-Varianten, Kampagnen, Zielgruppen-spezifische Inhalte, etc.
Die Verwaltung und Anlage der Marken finden Sie in der App unter Vorlagen-Management → Marken.
| Aspekt | Umgebungs-Mandanten | Marken |
|---|---|---|
| Zweck | Organisatorische Trennung, Nutzer-Sicht, Vererbung von Standard-Elementen | CI-Auswahl pro Request (Logos, Farben, Textvarianten, …) |
| Steuerung in Elementen | Dropdown „Umgebungs-Mandant“, Checkbox „Standard für Umgebungs-Mandanten“ | Feld brandIdentifier (z.B. default vs. eigene Marke) |
| Typisches Szenario | Konzerne mit mehreren rechtlich/inhaltlich getrennten Einheiten | Ein Mandant mit mehreren sichtbaren Marken (z.B. Regional- und Hausmarke) |
Bei der Markenfindung wertet Output.Rocks pro aktiver Marke eine Bedingung (dieselbe Expression-Logik wie bei Vorlagenbedingungen) aus, berücksichtigt dabei Priorität und Aktiv ab, und begrenzt den Kandidatenpool auf den passenden Scope (Ihr Client, ggf. in Kombination mit dem im Request gewählten Umgebungs-Mandanten). Es gibt immer eine geschützte Default-Marke default als stabile Basis.
Auflösung markenfähiger Elemente: Stimmt der am Request gespeicherte brandIdentifier mit dem einer Vorlage, eines Bildes, einer Komponente usw. überein, wird dieses Element bevorzugt. Fehlt eine markenspezifische Variante, bleibt default als Fallback.
Rendering-Auswahl und Regeln
Beim Rendern wird die Marke als eigener Workflow-Schritt zwischen Datenmapping und Template-Auswahl bestimmt. Das Ergebnis wird als brandIdentifier am Rendering-Request gespeichert und in Dokument- sowie E-Mail-Übersichten als Marken-Badge angezeigt.
Die Auswahl folgt diesen Regeln:
- Berücksichtigt werden aktive Marken im passenden Scope (Ihr Client; bei gesetztem Request-Umgebungs-Mandanten ggf. zusätzlich markenspezifische Zeilen für diesen Mandanten und client-weite Marken ohne Mandantenbindung).
Aktiv abmuss vor oder auf dem Erstellzeitpunkt des Requests liegen.- Alle passenden Markenbedingungen werden gesammelt.
- Die höchste Priorität gewinnt.
- Der Request wird blockiert, wenn keine aktive Marke im Gültigkeitsbereich existiert, keine Bedingung passt, oder mehrere Marken dieselbe höchste Priorität haben.
Bedingungs-Kontext zum Zeitpunkt „Marke bestimmen“
Markenbedingungen nutzen dieselbe Expression-Umgebung wie andere Vorlagenbedingungen. Wichtig zum Zeitpunkt „Marke bestimmen“ (vor der Template-/App-Daten-Aufbereitung):
| Kontext | Inhalt |
|---|---|
data | Zusammenführung der Rendering-Rohdaten: Payload (value) und was zu diesem Zeitpunkt bereits im Render-Objekt unter app liegt — nicht das vollständige, später von der Map-Phase aufgebaute App-Datenpaket für Docmosis (Standardwerte/Komponenten-Auflösung für das finale Rendering folgen erst danach). |
metadata | Metadaten des Requests |
request | Request-Kontext wie externalId, template, format, webhook, comment, emailServer; bei der Prüfung einer Kandidaten-Marke ist brandIdentifier hier die Kennung dieser Marke |
standard | Verfügbar: Map der Standardwerte (identifier → Wert), geladen im Kontext der jeweils geprüften Kandidaten-Marke (immer einschließlich default, plus die Marke, die gerade getestet wird) |
Halten Sie Markenbedingungen möglichst eindeutig. Eine Default-Marke mit true und Priorität 0 sorgt für einen stabilen Fallback, während spezifische Marken höhere Prioritäten erhalten.
Markenspezifische Elementtypen
Folgende Elemente sind markenfähig und besitzen ein Feld brandIdentifier:
- Standardwerte
- Komponenten
- Bilder
- Diagramme
- QR-Codes
- docx-Vorlagen
- E-Mail-Vorlagen
- E-Mail-Grundgerüste
- E-Mail-Anhänge
Wenn ein Rendering-Request z.B. die Marke stadtwerk_sued erhält, sucht Output.Rocks bei markenfähigen Elementen bevorzugt nach brandIdentifier = stadtwerk_sued. Gibt es kein passendes Element für diese Marke, bleibt brandIdentifier = default als Fallback verfügbar.
Für Varianten derselben Vorlage oder desselben Elements verwenden Sie denselben fachlichen Identifier und unterscheiden nur den Marken-Identifier. Beispiel: logo mit brandIdentifier = default und logo mit brandIdentifier = stadtwerk_sued.
In der Marken-Detailansicht zeigt die SPA verknüpfte Konfiguration pro Elementtyp. Die Links führen direkt in die jeweilige Liste und setzen dort den Filter brandIdentifier, damit alle Elemente dieser Marke sichtbar sind.
Export und Import
Der Template-Konfigurations-Exporter enthält Marken als eigene Kategorie. Markenfähige Elemente exportieren zusätzlich ihren brandIdentifier, sodass CI-Varianten zwischen Umgebungen übertragen werden können.
Beim Import wird die geschützte Default-Marke nicht doppelt angelegt, wenn sie im Zielmandanten bereits existiert. Importieren Sie markenspezifische Elemente zusammen mit den dazugehörigen Marken, damit die Validierung des brandIdentifier erfolgreich ist.
Verwaltung im Backend
Einrichtung von Umgebungs-Mandanten
Bevor Sie Elemente Umgebungs-Mandanten zuweisen können, müssen diese Mandanten im System eingerichtet werden:
1. Umgebungs-Mandant erstellen
Im Hauptmenü unter Untermandanten → Umgebungs-Mandant erstellen
• Externe ID: Optionale Referenz für Ihr internes System
• Beschreibung: Sprechender Name des Umgebungs-Mandanten (z.B. "Stadtwerke Nord")
• Farbe: Identifikationsfarbe für bessere Übersicht im Backend
2. Benutzer-Zugang einrichten
Im Hauptmenü unter Benutzer → Neuen Benutzer erstellen (oder vorhandenen Benutzer bearbeiten)
• Im Dropdown Untermandant den erstellten Umgebungs-Mandanten auswählen
• Benutzer erhält automatisch die eingeschränkten Mandant-Berechtigungen der Instanz statt Master-Zugang
Nach der Einrichtung kann der Mandant sich mit eigenen Zugangsdaten anmelden und sieht nur seine eigenen Elemente plus die vom Hauptmandant geteilten Standard-Elemente .
Element-Zuweisung
Zuordnung zu einem spezifischen Umgebungs-Mandanten oder Standard-Verwendung für alle Mandanten.
Markiert Element als Standard-Element, das automatisch an alle Umgebungs-Mandanten vererbt wird.
Fehlermeldung: Die Kombination "Standard für Umgebungs-Mandanten" + ausgewählter "Umgebungs-Mandant" erzeugt die Fehlermeldung: Tenant defaults can not be set on tenant assigned entities. Ein Element kann entweder für einen spezifischen Mandant ODER als Standard für alle Umgebungs-Mandanten konfiguriert werden.
Element-Typ-Bestimmung:
• Mandant = None + Standard = ✗ → Nutzer-Element (nur für aktuellen Nutzer)
• Mandant = None + Standard = ✓ → Standard-Element (für alle Umgebungs-Mandanten)
• Mandant = (Spezifischer Umgebungs-Mandant) + Standard = ✗ → privates Mandant-Element (nur für gewählten Umgebungs-Mandanten)
Best Practices für Mandanten-Management
• Compliance-kritische Elemente als Standard bereitstellen
• Gruppen-Identifier für Komponenten-Familien nutzen (z.B. footer für alle Footer-Varianten)
• Bei Konflikten: Präfix-basierte und sprechende Identifiers verwenden (shared_, subClientX_, ...)
• Versionsnummern in Identifiern für Updates und...
• ...koordinierte Rollouts aller aktualisierten Elemente über zeitgesteuerte Aktivierung
• Regelmäßige Tests in verschiedenen Mandanten-Kontexten
• Release Notes für Umgebungs-Mandanten bereitstellen
• Langfristige Mandanten-Strategie definieren
• Element-Hierarchien vor Implementierung planen
Wartungshinweis: Je mehr ein Mandant von Master-Standards abweicht, desto höher der individuelle Wartungsaufwand. Wägen Sie Anpassungen gegen Effizienz ab.
Nächste Schritte: