Vorlagen-Management
Versionierung
Versionshistorie, Wiederherstellung und Retry-Zeitpunkt für alle Verwaltungsobjekte
Alle Verwaltungsobjekte im Vorlagen-Management und in der Integration werden versioniert: Vorlagen, E-Mail-Vorlagen, Vorlagen-Bausteine, Standardwerte, Bilder, Diagramme, QR-Codes, E-Mail-Anhänge, E-Mail-Rahmen, Marken, Eingabemasken, Mapping-Regeln, Validierungen, Zugangsdaten, Datensammler, E-Mail-Server und Webhooks.
Das Versionsprinzip
Jede inhaltliche Änderung erzeugt eine neue, unveränderliche Version — die bisherige Version bleibt vollständig erhalten und wird eingefroren. Bereits erzeugte Dokumente und E-Mails referenzieren weiterhin exakt die Version, mit der sie erstellt wurden.
- Sofort gültig: Eine Bearbeitung ohne zukünftiges „Gültig ab"-Datum wird sofort wirksam; die Vorversion gilt bis zu diesem Moment.
- Geplant: Mit einem zukünftigen „Gültig ab"-Datum wird die neue Version erst zum Stichtag wirksam; bis dahin gilt die bisherige Version weiter.
- Das reine Aktivieren/Deaktivieren (Schalter „Aktiv") erzeugt keine neue Version. Das Verschieben des „Gültig ab"-Datums erzeugt nur bei einer geplanten, noch nicht wirksamen Version keine neue Version; bei der aktuell wirksamen Version entsteht dabei eine Nachfolgeversion.
- Eine Version, die noch nie gegolten hat (geplante Version vor ihrem Stichtag), wird beim Bearbeiten direkt angepasst.
API-Token sind von der Versionierung ausgenommen: Sie sind Zugangs-Prinzipale, keine inhaltliche Konfiguration.
Versionshistorie
Jede Zeile der Verwaltungslisten bietet eine Historien-Aktion (Uhr-Symbol). Das Historien-Fenster zeigt alle Versionen des Eintrags mit:
- Versionsnummer und Status (Aktuell, Geplant, Abgelöst, Beendet)
- Gültigkeitszeitraum (Gültig ab / abgelöst am)
- KI-Zusammenfassung der Änderungen (Deutsch und Englisch, automatisch nach dem Speichern erzeugt)
- Ersteller und Erstellungszeitpunkt
Die Listenansicht zeigt pro logischem Objekt genau eine Zeile. Solange eine Version aktuell wirksam ist, repräsentiert sie das Objekt. Gibt es noch keine wirksame Version, erscheint stattdessen die zeitlich nächste Planung. Beendete Objekte bleiben ausgeblendet; abgelöste und weitere geplante Versionen sind über die Historie erreichbar.
Die versionsgruppierte Listenansicht gilt nur für die Weboberfläche. Die maschinell genutzte API (/api/... mit X-AUTH-TOKEN) liefert Collections unverändert wie vor der Versionierung — alle Zeilen, ohne Gruppierung.
Der Status in der Liste trennt zwei unterschiedliche Aussagen:
- Aktuell oder Geplant beschreibt die zeitliche Wirksamkeit der angezeigten Version.
- Aktiviert oder Deaktiviert beschreibt die fachliche Einstellung des Objekts.
Über das Augen-Symbol lässt sich jede Version mit ihrer exakten historischen ID in der objektspezifischen Detailansicht öffnen. Diese Ansicht ist immer schreibgeschützt und steht auch für geerbte Einträge zur Verfügung. Bei DOCX-Dokumentvorlagen kann außerdem die Datei der gewählten Version direkt aus der Historie heruntergeladen werden.
Noch nicht wirksam gewordene Planungen lassen sich aus der Historie bearbeiten oder gezielt verwerfen. Beim Verwerfen werden die Gültigkeitsgrenzen der Nachbarversionen automatisch geschlossen, sodass keine unbeabsichtigte Lücke entsteht.
Wiederherstellen
Aus der Historie lässt sich jede frühere Version wiederherstellen: Dabei entsteht eine neue Version mit dem Inhalt der gewählten alten Version — wahlweise sofort gültig oder geplant zu einem „Gültig ab"-Datum. Die Historie bleibt dabei lückenlos erhalten.
Umgebungs-Mandanten-Benutzer können geerbte Einträge des Hauptmandanten einsehen, aber nicht wiederherstellen.
Löschen
Das Löschen einer Listenzeile beendet das gesamte logische Objekt und entfernt seine noch nicht wirksam gewordenen Planungen. Historische Versionen und deren Dateien bleiben erhalten — bereits erzeugte Dokumente bleiben reproduzierbar. Historische Versionen selbst können nicht gelöscht oder bearbeitet werden.
Retry mit Versions-Zeitpunkt
Beim erneuten Ausführen (Retry) blockierter Render-Anfragen, Dokumente und E-Mails wählen Sie, mit welchem Konfigurationsstand aufgelöst wird:
- Originaler Request-Zeitpunkt (Standard): Vorlagen, Marken, Webhooks, Bausteine, Diagramme usw. werden mit den Versionen aufgelöst, die zum Zeitpunkt des ursprünglichen Requests gültig waren — das Ergebnis ist reproduzierbar wie beim Erstversuch.
- Retry-Zeitpunkt: Es gelten die aktuell gültigen Versionen — sinnvoll, wenn eine Konfiguration korrigiert wurde und der Retry die Korrektur verwenden soll.
Dieselbe Auswahl steht im Prozess-Leitstand zur Verfügung. Sie gilt dort sowohl für die Vorschau als auch für Daten speichern und erneut versuchen. Die Vorschau nutzt den gewählten Zeitpunkt nur transient und ändert den gespeicherten Request nicht.
Zugangsdaten (Credentials) werden aus Sicherheitsgründen immer zum Ausführungszeitpunkt aufgelöst, damit rotierte Secrets Retries nicht brechen.
Verhaltensänderung: Webhook-Definitionen, Diagramme, QR-Codes und Vorlagen-Bausteine werden beim Rendern und bei Retries jetzt konsistent zum Request-Zeitpunkt aufgelöst (bisher teilweise zum Ausführungszeitpunkt). Diagramme und QR-Codes mit zukünftigem „Gültig ab" werden nicht mehr stillschweigend übersprungen: Existiert eine zum Request-Zeitpunkt gültige Version, wird diese gerendert; existiert keine, wird der Rendervorgang mit einer klaren Fehlermeldung blockiert, statt das Diagramm bzw. den QR-Code stillschweigend auszulassen.