Corporate Identity
Marken
Sub-Branding über Marken und Corporate-Identity-Elemente verwalten
Marken dienen in Output.Rocks als die Corporate-Identity-Ebene zwischen einem Rendering-Request und den verwendeten Vorlagen-Elementen. Eine Marke legt fest, welche CI-Variante zu einem Request passt. Danach verwendet Output.Rocks bevorzugt Elemente mit genau diesem Marken-Identifier – oder greift auf default zurück, wenn für die Marke kein spezielles Element existiert.
Marken ersetzen nicht die Umgebungs-Mandanten: Mandanten trennen organisatorische Bereiche und werden direkt über Render-Anfragen ausgewählt. Marken können präziser an einzelne Bedingungen derselben Render-Anfrage gekoppelt werden und bestimmen Corporate-Identity-Verhalten innerhalb des passenden Mandantenkontexts.
Sichtbarkeit: Marken gehören inhaltlich zum Vorlagen-Management und können von Nutzern mit den Rollen CI-Manager und Administrator bearbeitet werden.
Nutzungshinweise: Abgrenzung zu Umgebungs-Mandanten, Markenfindung im Render-Prozess, Bedingungs-Kontext und eine Liste markenfähiger Elementtypen ufinden Sie im Use-Case Mandanten-Management.
Marken-Liste
Die Übersicht zeigt alle Marken der aktuellen Umgebung. Jede Marke hat einen technischen Identifier, einen Anzeigenamen, eine Bedingung, eine Priorität, eine Farbe, ein Aktiv-ab-Datum und optional eine Zuordnung zu einem Umgebungs-Mandanten.
| Identifier | Anzeigename | Bedingung | Priorität | Farbe | CI-Prüfung | Aktiv ab |
|---|---|---|---|---|---|---|
| default | Default | true | 0 | #083E5D | Aus | 01.01.1970 |
| stadtwerk_sued | Stadtwerk Süd | data["versorger_segment"] == "sued" | 20 | #2E7D32 | Aktiv | 15.03.2025 |
Identifier
Technischer Marken-Identifier. Er wird auf Rendering-Requests gespeichert und in markenspezifischen Elementen als brandIdentifier verwendet.
Bedingung
Expression, die entscheidet, ob diese Marke zu einem Rendering-Request passt. Auswertung mit derselben Expression-Logik wie bei Vorlagenbedingungen; verfügbar sind die Kontexte data, metadata, request und standard.
Priorität
Wenn mehrere Markenbedingungen passen, gewinnt die Marke mit der höchsten Priorität. Mehrere Treffer mit derselben höchsten Priorität blockieren den Request, damit keine zufällige CI-Variante verwendet wird.
Farbe
Visuelle Kennzeichnung in Marken-Badges und Übersichten.
CI-Prüfung
Zeigt, ob Uploads von .docx-Vorlagen für diese Marke serverseitig gegen konfigurierte Corporate-Identity-Regeln geprüft werden.
Kontext-Aktionen
Aktions-Dropdown
Aktions-Dropdown
Klicken Sie auf das Drei-Punkte-Menü am Ende jeder Zeile für Aktionen mit dem jeweiligen Marke.
Anzeigen
Zeigt Stammdaten, Bedingung, Aktivierung und verknüpfte Konfiguration.
Ändern
Öffnet das Formular zum Aktualisieren von Anzeigename, Bedingung, Priorität, Farbe und Aktivierung.
Löschen
Löscht die Marke, sofern sie nicht die geschützte Default-Marke ist.
Spalten konfigurieren
Passen Sie die Anzeige der Marke-Liste für bessere Übersichtlichkeit an. Spalten können per Drag-and-Drop neu angeordnet und über Checkboxen ein-/ausgeblendet werden.
Für mich anwenden : Spalten-Konfiguration wird nur für Ihren Account gespeichert und beeinflusst andere Benutzer nicht.
Als Standard anwenden : Konfiguration wird für alle Benutzer der Instanz übernommen und als neue Standard-Ansicht gesetzt.
Marke erstellen
Aktions-Buttons zum Speichern und Verwalten der Marke-Konfiguration.
Verwenden Sie "Erstellen und weiteres Element hinzufügen" für effizientes Batch-Erstellen mehrerer Elemente.
Formularfelder
Eindeutige Kennung für dieses/r Marke zur programmatischen Verwendung, Einbindung in Vorlagen, Lookups und API-Zugriff.
Identifiers sollten 'snake_case' sein, also klein geschrieben und Unterstriche verwenden, z.B. 'kunde_name' oder 'rechnung_nummer'.
Anzeigename
Anzeige-Name für Übersichten, Detailansichten und Auswahlfelder, z.B. Stadtwerk Süd.
Die Bedingung ist eine Expression und wird mit derselben logischen Syntax ausgewertet wie Vorlagenbedingungen. true bedeutet, dass die Marke immer passt.
data["versorger_segment"] == "sued"
In der Expression stehen u.a. Payload/Merge-Daten (data), Metadaten (metadata), Request-Felder (request) und die Map der Standardwerte (standard) zur Verfügung.
Beispiel: Eine Datenmapping-Regel oder das Upstream-System liefert ein normiertes Feld, z.B. versorger_segment. Die Markenbedingung kann dann schlicht lauten: data["versorger_segment"] == "sued".
Höhere Werte gewinnen vor niedrigeren Werten. Verwenden Sie für spezifische Marken höhere Prioritäten als für breite Fallback-Regeln.
Farbkennzeichnung für bessere Übersicht und Kategorisierung der Marke.
Farben können genutzt werden, um z.B. Dokument-Arten, Marken, Kampagnen oder Produkttypen im Backend schnell optisch zuzuordnen.
Startdatum des Markes. Markee werden erst ab diesem Datum beim Rendern beachtet.
Die Aktiv-Checkbox ermöglicht eine sofortige De-/Aktivierung unabhängig vom Datum.
Vor-Terminierung: Mit diesem Feld können Markee vor-terminiert werden. Setzen Sie ein zukünftiges Datum, um das Element automatisch ab diesem Zeitpunkt zu aktivieren.
Mehrere Elemente mit gleichem Identifier: unterschiedliches 'Aktiv ab' staffelt die Version; bei einer Anfrage gilt das aktive Element mit dem spätesten Aktiv ab (nicht Erstell- oder Änderungsdatum).
Zuordnung zu einem spezifischen Umgebungs-Mandanten oder Standard-Verwendung für alle Mandanten.
Dokumenten-Design
Eine Marke kann einen Briefbogen tragen: eine Word-Datei mit Kopf- und Fußzeile, Logo, Seitenrändern und Adressfeld. Beim Rendern wird sie zur Hülle, in die die Inhaltsvorlage eingesetzt wird. Die Inhaltsvorlage enthält damit nur noch den Text des Schreibens und wird einmal gepflegt, statt je Marke dupliziert zu werden.
Der Briefbogen verändert keine E-Mail-Layouts. Für E-Mails sind die markenfähigen E-Mail-Grundgerüste zuständig.
Was der Briefbogen bestimmt
| Bestandteil | Kommt aus |
|---|---|
| Seitenformat, Ränder, Ausrichtung | Briefbogen |
| Kopf- und Fußzeile samt Logos | Briefbogen |
| Seitennummerierung | Briefbogen |
| Text, Tabellen, Bilder im Fließtext, Docmosis-Felder | Inhaltsvorlage |
| Absatz- und Zeichenformate des Inhalts | Inhaltsvorlage |
Ein Briefbogen formatiert den Text der Inhaltsvorlage also nicht um — er setzt den Rahmen, in dem der Text steht.
Anforderungen an die Datei
- Eine makrofreie
.docx. - Genau ein Feld
<<refLookup:or.brandLayoutContentTemplate>>an der Stelle, an der die Inhaltsvorlage erscheinen soll. - Verwendete Schriften müssen auf den Rendering-Servern installiert sein.
Beim Hochladen prüft Output.Rocks diese Punkte und zeigt anschließend, was gefunden wurde: Anzahl der Kopf- und Fußzeilen, Bilder, Seitenränder in Millimetern sowie Hinweise — etwa wenn der Briefbogen mehrere Abschnitte enthält.
Hochladen, prüfen, entfernen
Öffnen Sie die Marke über Bearbeiten und nutzen Sie den Abschnitt Dokumenten-Design:
- Datei wählen — die
.docxauswählen. Sie wird erst beim Speichern hochgeladen und geprüft. - Speichern — dabei entsteht eine neue Version der Marke. Wird die Datei abgelehnt, bleibt der bisherige Briefbogen unverändert.
- Vorschau — rendert den Briefbogen mit einem Beispielinhalt. So lässt sich beurteilen, wie ein Schreiben aussehen wird, ohne eine echte Vorlage auszuwählen.
- Herunterladen gibt die gespeicherte Datei zur weiteren Bearbeitung in Word zurück, Entfernen löscht den Briefbogen mit dem nächsten Speichern; die Marke rendert danach wieder unverändert.
Die Marke default kann keinen Briefbogen tragen. Sie ist der Rückfall für alle Requests, ein Briefbogen dort würde das Rendering sämtlicher Dokumente auf einmal verändern.
Übertragen zwischen Instanzen
Der Konfigurations-Transfer nimmt den Briefbogen mit: Beim Export wird die Datei in die ZIP gelegt, beim Import unter dem Namen der neu angelegten Marke gespeichert. Eine Marke ohne Briefbogen wird unverändert übertragen.
Die Marke default ist vom Konfigurations-Transfer ausgeschlossen. Konfiguration, die nur auf default liegt, kommt nicht mit — das betrifft auch Inhaltsvorlagen, die für einen Briefbogen vorgesehen sind.
Wenn eine Marke keinen Briefbogen hat
Dann wird unverändert wie bisher gerendert. Der Briefbogen kann also Marke für Marke eingeführt werden.
Ausnahmen je Vorlage
Manche Dokumente bringen ihren Rahmen selbst mit — Etiketten, Endlosformulare, Vorlagen mit Querformat-Abschnitten. Für sie lässt sich in der Vorlage Briefbogen nicht anwenden setzen; sie werden dann unverändert gerendert, auch wenn ihre Marke einen Briefbogen hat. Derselbe Schalter dient als Notbremse, falls ein Briefbogen im Betrieb Probleme macht.
Hinweise beim Speichern einer Inhaltsvorlage
Kopf- und Fußzeilen der Inhaltsvorlage entfallen im gerenderten Dokument, weil der Briefbogen seine eigenen mitbringt. Damit das nicht unbemerkt Text kostet, prüft Output.Rocks beim Speichern einer Vorlage, welche Marken einen Briefbogen haben und ob deren Briefbogen denselben Text zeigt. Fehlt er dort, wird die betroffene Zeile im Wortlaut genannt — samt der Marken, in deren Dokumenten sie nicht erscheinen würde. Auch ein zweiter Abschnitt in der Vorlage wird gemeldet, weil dessen Seiteneigenschaften und Kopf-/Fußzeilen entfallen.
Diese Hinweise blockieren nichts. Es gibt zwei saubere Auswege: den Text in die betroffenen Briefbögen übernehmen, oder für die Vorlage Briefbogen nicht anwenden setzen.
Soll eine Inhaltsvorlage sowohl mit als auch ohne Briefbogen richtig aussehen, setzen Sie ihren eigenen Briefkopf in einen bedingten Abschnitt: <<cs_{!or.brandLayoutApplied}>> … <<es_>>. Er wird nur gerendert, wenn kein Briefbogen greift.
Effektive Konfiguration
Eine Marke überschreibt nur, was sie selbst definiert — alles andere übernimmt sie von der Marke default. Das ist der Kern des Marken-Modells, war aber bisher nirgends sichtbar: Wer eine gemeinsame Vorlage änderte, konnte nicht sehen, welche Marken davon profitieren und welche längst eine eigene Zeile haben.
Im Bearbeiten-Dialog einer Marke zeigt der Abschnitt Effektive Konfiguration nach einem Klick auf Ermitteln, wie viele Elemente je Typ geerbt werden und wo die Marke eigene Zeilen hat:
| Zustand | Bedeutung |
|---|---|
| Geerbt | Die Marke verwendet die gemeinsame Zeile und bekommt jede Änderung daran automatisch mit. |
| Überschrieben | Die Marke hat eine eigene Zeile. Änderungen an der gemeinsamen Version erreichen sie nicht mehr. |
| Nur diese Marke | Es gibt nur eine Markenzeile, keine gemeinsame Vorlage dazu. |
Unter Nicht mehr geerbt stehen die betroffenen Identifier einzeln. Trägt einer davon zusätzlich den Hinweis veraltet, wurde die gemeinsame Version geändert, nachdem die Marke sie überschrieben hat — die Marke arbeitet also mit einem älteren Stand.
In den markenfähigen Listen — Vorlagen, Bilder, Standardwerte und den übrigen — lässt sich über Nach Marke filtern eine Marke auswählen. Solange eine Marke gewählt ist, zeigt jede Zeile zusätzlich, ob sie für diese Marke geerbt oder überschrieben ist.
Der Abschnitt wird erst auf Klick geladen: Er liest alle markenfähigen Tabellen und ist damit teurer als die übrigen Felder des Formulars.
Braucht eine Marke nur einen zusätzlichen Absatz statt eines komplett eigenen Dokuments, ist eine markenspezifische Vorlagen-Komponente oder ein markenspezifischer Standardwert der bessere Weg: Die Vorlage bleibt gemeinsam und wird weiter aktualisiert.
CI-Prüfung
Die CI-Prüfung ist eine optionale Upload-Sperre pro Marke. Ist sie aktiviert, analysiert Output.Rocks neue oder geänderte .docx-Vorlagen beim Speichern und vergleicht die gefundenen Corporate-Identity-Merkmale mit den Regeln der gewählten Marke. Vorlagen, die gegen die Regeln verstoßen, werden nicht gespeichert.
Aktivieren Sie die CI-Prüfung erst, wenn mindestens eine Regel konfiguriert ist. Eine aktivierte Prüfung ohne Regeln blockiert Uploads mit dem Hinweis, dass keine CI-Regeln vorhanden sind.
Regeln konfigurieren
Im Markenformular gibt es den Bereich CI-Prüfung aktiviert. Dort verwalten Sie die erlaubten Werte als kommagetrennte Listen:
| Regel | Prüft | Beispiel |
|---|---|---|
| Erlaubte Schriften | Schriftfamilien, die in der .docx-Datei verwendet werden dürfen. | Arial, Aptos |
| Erlaubte Farben | Hex-Farben aus Texten, Formatierungen und Dokumentteilen. Das führende # ist optional. | 083E5D, FFFFFF |
| Erlaubte Formatvorlagen | Word-Formatvorlagen wie Fließtext, Überschriften oder kundenspezifische Styles. | Normal, Heading 1 |
| Erlaubte Ausrichtungen | Seitenorientierungen in den Dokumentabschnitten. | portrait |
| Rand-Toleranz | Toleranz für konfigurierte Seitenränder in Twips. 1 Punkt entspricht 20 Twips. | 120 |
| Erlaubte Bild-Hashes | SHA-256-Hashes für Logos oder Bilder, die exakt freigegeben werden sollen. | sha256... |
Leere Felder werden für die jeweilige Kategorie nicht geprüft. So können Sie z.B. nur Schriften und Farben absichern, ohne Seitenlayout oder Bilder festzulegen.
Aus vorhandenen Vorlagen generieren
Mit Aus Vorlagen generieren erstellt Output.Rocks einen Vorschlag aus aktiven, inspectierbaren .docx-Vorlagen derselben Marke. Berücksichtigt werden Vorlagen im aktuellen Mandantenkontext, deren brandIdentifier zur Marke passt und deren Aktiv-ab-Datum bereits erreicht ist.
Der Vorschlag enthält:
- die erkannten Schriften, Farben, Formatvorlagen und Seitenorientierungen
- die Anzahl der Quellvorlagen
- Hinweise, falls einzelne Vorlagen nicht analysiert werden konnten
- die Information, ob KI für die Verfeinerung genutzt wurde
- eine Konfidenz-Einschätzung
Der Vorschlag wird zuerst in einem Prüfdialog angezeigt. Erst Einstellungen übernehmen schreibt ihn in das Formular, und erst das anschließende Speichern aktualisiert die Marke. Bild-Hashes werden zur Prüfung bewusst nur übernommen, wenn Sie sie explizit in den Regeln eintragen.
Starten Sie konservativ: Aktivieren Sie zunächst Regeln für Schriften und Farben, testen Sie typische .docx-Vorlagen und ergänzen Sie strengere Regeln wie Bild-Hashes oder Seitenränder erst, wenn die vorhandenen Vorlagen bereinigt sind.