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.
Diese Seite zeigt eine Liste aller Elemente, und darüber diverse Aktionen, die du ausführen kannst:
Springe zu:
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.
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.