modale Vorlagen
E-Mail-Vorlagen
Konfigurieren Sie E-Mail-Vorlagen für die Kommunikation
Die Vorlagen für E-Mails ermöglichen die schnelle und einheitliche Verwaltung von Nachrichten durch zentral hinterlegte, anpassbare Textbausteine und Layouts.
E-Mail-Vorlagen werden im App-Backend erstellt und mit einem eindeutigen Identifier versehen. Sie können für den automatisierten Versand von E-Mails mit dynamischen Inhalten verwendet werden. Schritt-für-Schritt Informationen zur Verwendung von E-Mail-Vorlagen finden Sie in der Einführung zu E-Mails und Anhängen.
E-Mail-Vorlagen können über das Backend-Interface oder programmatisch über die API erstellt werden.
Jede E-Mail-Vorlage benötigt einen eindeutigen Identifier zur Verwendung in Systemen und für den Versand. Verwenden Sie aussagekräftige Namen wie contract_welcome_letter_mail oder invoice_notification_email.
E-Mail-Vorlagen-Liste
Die Übersicht zeigt alle verfügbaren E-Mail-Vorlagen mit ihren wichtigsten Eigenschaften:
ID, Identifier, Gruppen-Identifier, Aktiv ab
| ID | Identifier | Gruppen-Identifier | Aktiv ab | Wert |
|---|---|---|---|---|
| identifier_name | Null |
ID
Eindeutige Nummer zur internen Identifikation des E-Mail-Vorlages.
Identifier
Eindeutiger Name des E-Mail-Vorlages für Rendering und API-Aufrufe.
Eindeutiger Name für eine optionale Gruppierung von verwandten E-Mail-Vorlagen. Elemente einer Gruppe werden gemeinsam verarbeitet und optionale Validatoren können dabei einzelne Elemente aktivieren oder ignorieren.
Aktiv ab
Startdatum eines E-Mail-Vorlages. E-Mail-Vorlages werden erst ab diesem Datum beim Rendern beachtet.
Wert
Der Dateneintrag des E-Mail-Vorlages. Kann Text, Zahlen, Bedingungen oder andere Daten enthalten, die in Vorlagen verwendet werden.
Aktiv, Pausiert, Validatoren, Erstellt am, Aktualisiert am
| Validatoren | Pausiert | Aktiv | Erstellt am | Aktualisiert am |
|---|---|---|---|---|
| Null | NO | Ja | ||
| missing_street | YES | Nein |
Zugewiesene Validierungsregeln für das E-Mail-Vorlage. Prüfen Ihre Bedingungen vor der Verarbeitung und aktivieren/deaktivieren das Rendering entsprechend.
Temporäre Deaktivierung des E-Mail-Vorlages. Pausierte Elemente werden nicht verarbeitet.
Aktivierungsstatus des E-Mail-Vorlages. Nur aktive Elemente werden beim Rendern berücksichtigt.
Erstellt am
Zeitstempel der E-Mail-Vorlage-Erstellung.
Aktualisiert am
Zeitstempel der letzten Änderung. Zeigt wann E-Mail-Vorlage-Konfiguration zuletzt bearbeitet wurde.
Mandant, Standard für Umgebungs-Mandanten
| Umgebungs-Mandant | Standard für Umgebungs-Mandanten | Benutzerdefinierte ID | Farbe |
|---|---|---|---|
| (1880) Submarke 1 | NO | Null | |
| Null | YES | <<payload.value>> |
Zugeordneter Mandant des/der E-Mail-Vorlage. Ermöglicht Mandanten-spezifische Konfiguration.
Kennzeichnet E-Mail-Vorlage als Standard und vererbt (verfügbar) für alle Umgebungs-Mandanten.
Optionale benutzerdefinierte Kennung nach dem Rendering für externe Systeme. Wird als Referenzen des/der E-Mail-Vorlage bei Callbacks übergeben und beherrscht Vorlagen-Syntax inkl. Zugriff auf Payload-Daten.
Visuelle Kennzeichnung für schnelle Identifikation des/der E-Mail-Vorlage. Vor allem nützlich für Dashboard-Statistiken und Charts.
E-Mail-spezifische Eigenschaften
Standard E-Mail-Identifier, Benutzerdefinierte ID, Farbe, Betreff
| Standard E-Mail-Identifier | Benutzerdefinierte ID | Farbe | Betreff |
|---|---|---|---|
| standard_email | <<contract.id>> | ✌️ Vertragsbestätigung |
Standard E-Mail-Identifier
Verweis auf eine Standard-E-Mail-Vorlage, die als HTML-Gerüst dient. Die Standard-E-Mail-Vorlage definiert das Grundlayout und die Struktur der E-Mail.
Benutzerdefinierte ID
Optionale eigene Kennung, die bei Callbacks nach dem Rendering der E-Mail-Vorlage zurückgegeben wird. Unterstützt Platzhalter für dynamische Werte (z.B. <<contract.id>>).
Farbe
Farbkennzeichnung für bessere Übersicht und Kategorisierung der E-Mail-Vorlage im Backend. Dient der visuellen Unterscheidung und schnellen Identifikation.
Betreff
Der E-Mail-Betreff, der beim Versand verwendet wird. Kann Output.Rocks-Platzhalter enthalten, die beim Rendering durch die entsprechenden Werte ersetzt werden.
Bounce-Handling, Maximale Anzahl blockierter Prozesse
| Bounce-Handling | Maximale Anzahl blockierter Prozesse |
|---|---|
| Ja | 100 |
Bounce-Handling
Steuert, ob der E-Mail-Prozess auf eine Zustellbestätigung wartet. Wenn aktiviert, bleibt der E-Mail-Prozess nach dem Versand im Status "sent" und wartet auf Bestätigung (Workflow: sent → wartet → delivered oder bounced). Manuelle Aktionen wie "Mark as Delivered" oder "Mark as Bounced" sind möglich. Verwendet für wichtige E-Mails, bei denen Bounces erkannt werden sollen. Standard: deaktiviert (false).
Maximale Anzahl blockierter Prozesse
Definiert die maximale Anzahl blockierter Prozesse, bevor die E-Mail-Vorlage automatisch pausiert wird. Bei jedem blockierten Prozess wird geprüft, ob das Limit erreicht ist. Wenn die Anzahl blockierter Prozesse ≥ maxBlockedAmount ist, wird die E-Mail-Vorlage automatisch auf "pausiert" gesetzt. Dies verhindert, dass ein fehlerhaftes Template unbegrenzt blockierte Prozesse erzeugt. Standard: 100.
Dateianhang-Identifier, Statische Anhänge
| Dateianhang-Identifier | E-Mail Anhang-Identifier |
|---|---|
| contract_welcome_letter_attachment | Null |
Dateianhang-Identifier
Template-Identifier, die zu RenderProcesses gerendert und als Dokumente (z.B. PDF) an die E-Mail angehängt werden. Beim Rendern werden die Template-Identifier zu Template-Entities aufgelöst, jedes Template wird zu einem RenderProcess gerendert, und die gerenderten Dokumente werden beim E-Mail-Versand angehängt. Verwendet für dynamische Dokumente wie Rechnungen oder Verträge, die Rendering-Daten verwenden. Pro E-Mail-Vorlage können mehrere Template-Identifier definiert werden.
E-Mail Anhang-Identifier
Identifier von EmailAttachment-Entities, die statische Dateien darstellen. Diese Dateien werden direkt an die E-Mail angehängt, ohne Rendering. Beim Versand werden die Identifier zu EmailAttachment-Entities aufgelöst und die Dateien direkt verwendet (z.B. bereits vorhandene PDFs, Bilder, Logos, AGB). Verwendet für statische Dateien, die keinen Rendering-Kontext benötigen.
Kontext-Aktionen
Aktions-Dropdown
Aktions-Dropdown
Klicken Sie auf das Drei-Punkte-Menü am Ende jeder Zeile für Aktionen mit dem jeweiligen E-Mail-Vorlage.
Testen
Öffnet eine E-Mail-Vorlage-Testumgebung zum lokalen Rendern mit bearbeitbaren Validatoren und JSON-Testdaten.
Anzeigen
Öffnet eine reine Detailansicht der kompletten Meta-Informationen und Einstellungen des E-Mail-Vorlage.
Ändern
Öffnet das Bearbeitungsformular für alle Einstellungen und den Upload einer neuen E-Mail-Vorlage-Version.
Löschen
Entfernt das E-Mail-Vorlage dauerhaft aus dem System. Diese Aktion kann nicht rückgängig gemacht werden.
Spalten konfigurieren
Passen Sie die Anzeige der E-Mail-Vorlage-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.
E-Mail-Vorlage erstellen
Aktions-Buttons zum Speichern und Verwalten der E-Mail-Vorlage-Konfiguration.
Verwenden Sie "Erstellen und weiteres Element hinzufügen" für effizientes Batch-Erstellen mehrerer Elemente.
Das Erstellungsformular für E-Mail-Vorlagen ist in vier Tabs unterteilt: Details für grundlegende Konfiguration und E-Mail-Parameter, HTML-Inhalt für den HTML-Inhalt der E-Mail mit Vorschau, TEXT-Inhalt für die Text-Version der E-Mail, und Validierung für die Zuordnung von Validatoren.
Eindeutige Kennung für dieses/r E-Mail-Vorlage 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'.
Zusätzliche Notizen und Hinweise zum/r E-Mail-Vorlage für interne Verwendung.
Verweis auf eine Standard-E-Mail-Vorlage, die als HTML-Gerüst dient. Die Standard-E-Mail-Vorlage definiert das Grundlayout und die Struktur der E-Mail.
Eindeutige Kennung für die Gruppierung und Organisation von E-Mail-Vorlagen.
Elemente einer Gruppe werden gemeinsam verarbeitet und optionale Validatoren können dabei einzelne Elemente aktivieren oder ignorieren.
Gruppen-Identifier sind optional und können bei Bedarf leer gelassen werden.
Gruppen-Identifier sollten 'snake_case' sein, also klein geschrieben und Unterstriche verwenden, z.B. 'kunde_name' oder 'rechnung_nummer'.
Bedingte Logik für die Auswahl des Elements basierend auf Payload-JSON-Daten. Das Element wird angesprochen, wenn der Gruppen-Identifier mit dem Request übereinstimmt. Es wird aber nur gerendert, wenn die Bedingung erfüllt (true) ist.
Aktiviert einen optionalen, manuellen Prüfprozess: Liefert der Ausdruck true, wird das Rendern abgeschlossen, aber Versand und Webhooks bleiben pausiert bis zur Freigabe im Dashboard.
false, also keine Freigabe erforderlich. Beispiel (Symfony Expression Language): data['contract']['id'] > 1000 - ist diese erfüllt, muss das Dokument erst freigeben werden.done ohne Versand.Name für die generierte Datei beim E-Mail-Vorlage-Rendering.
Der Ziel-Dateiname unterstützt Platzhalter für dynamische Dateinamen. Verwenden Sie
<<feldname>> für JSON-Daten und <<or.expression.timestamp({"format":"Y-m-d"})>> für Zeitstempel.Beispiel:
vertragsbestaetigung_<<contract.id>>_<<or.expression.timestamp({"format":"Y-m-d"})>> erzeugt: vertragsbestaetigung_12345_2024-03-15.eml.html Endung verwendet.Optionale eigene Kennung, die bei Callbacks nach dem Rendering der E-Mail-Vorlage zurückgegeben wird.
Die benutzerdefinierte ID unterstützt Platzhalter für dynamische Werte. Verwenden Sie <<feldname>> für JSON-Daten.
Beispiel: rechnung_<<contract.id>>_<<kunde.nummer>>
Interne Beschreibung eines/r E-Mail-Vorlage für Identifikation und bessere Übersicht bzw. Dokumentation. Diese Beschreibung wird im Output.Rocks-Backend verwendet und nicht im Output angezeigt.
Beschreibungen sollten kurz und prägnant sein, um Übersichtlichkeit zu gewährleisten. Längere Erklärungen sollten im Feld 'Kommentar' platziert werden.
Startdatum des E-Mail-Vorlages. E-Mail-Vorlagee 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 E-Mail-Vorlagee 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.
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.
Steuert, ob der E-Mail-Prozess auf eine Zustellbestätigung wartet. Wenn aktiviert, bleibt der E-Mail-Prozess nach dem Versand im Status "sent" und wartet auf Bestätigung (Workflow: sent → wartet → delivered oder bounced). Manuelle Aktionen wie "Mark as Delivered" oder "Mark as Bounced" sind möglich.
Standard: deaktiviert (NO). Verwendet für wichtige E-Mails, bei denen Bounces erkannt werden sollen.
Wenn aktiviert, erzeugt Output.Rocks bei bounced automatisch einen neuen Rendering Request aus dem ursprünglichen Request. Die Konfiguration kann Template, Format, Webhook, E-Mail-Server, External-ID-Pattern und zusätzliche Metadaten überschreiben.
Automatisches Bounce-Re-Rendering wird erst wirksam, wenn auch Bounce-Handling für diese E-Mail-Vorlage aktiviert ist.
- Leere Felder verwenden Template, Format, Webhook und Mailserver des Quell-Requests.
- Ohne External-ID-Pattern wird aus
SOURCEautomatischSOURCE-bounce-EMAIL_PROCESS_ID. - Metadaten werden mit den Quell-Metadaten zusammengeführt; der interne
bounceRerender-Marker verhindert erneute Auto-Schleifen.
Der Empfänger der E-Mail. Häufig aus dem Payload mit Platzhaltern wie <<kunde.email>>; unterstützt Expression-Syntax.
Zusätzliche Empfänger (Carbon Copy). Unterstützt Platzhalter und Expression-Syntax.
Blindkopie-Empfänger (Blind Carbon Copy). Unterstützt Platzhalter und Expression-Syntax.
Absender-Name der E-Mail. Unterstützt Platzhalter und Expression-Syntax.
Antwort-Adresse der E-Mail. Unterstützt Platzhalter und Expression-Syntax.
Der Betreff wird beim Versand verwendet und kann Output.Rocks-Platzhalter enthalten.
Farbkennzeichnung für bessere Übersicht und Kategorisierung der E-Mail-Vorlage.
Farben können genutzt werden, um z.B. Dokument-Arten, Marken, Kampagnen oder Produkttypen im Backend schnell optisch zuzuordnen.
Maximale Anzahl blockierter Rendering-Prozesse für das E-Mail-Vorlage. Ab dieser Anzahl werden weitere blockierte Prozesse (z.B. wegen Seitenzahl-Überschreitung, Syntaxfehlern oder Problemen mit Vorlagen-Dateien) nicht mehr versucht zu rendern, sondern direkt abgewiesen.
Ab der festgelegten Anzahl blockierter Prozesse werden weitere Renderings direkt abgewiesen. Es werden Fehlermeldungen im Dashboard erzeugt.
Temporäre Deaktivierung des E-Mail-Vorlages ohne Löschung.
Template-Identifier, die zu RenderProcesses gerendert und als Dokumente (z.B. PDF) an die E-Mail angehängt werden. Mehrere Identifier können durch Komma getrennt eingegeben werden.
Identifier von statischen Anhängen. Diese Dateien werden direkt angehängt, ohne Rendering. Mehrere Identifier können durch Komma getrennt eingegeben werden.
Anhänge im Backend bearbeiten:
Dynamische Anhänge (Dateianhang-Identifier): Diese werden als docx-Vorlagen im Backend erstellt und verwaltet. Jede Vorlage wird beim Rendern zu einem RenderProcess und als PDF-Dokument an die E-Mail angehängt.
Statische Anhänge: Diese werden unter Statische Anhänge erstellt und verwaltet. Diese Dateien werden direkt angehängt, ohne Rendering-Prozess.
E-Mail-Vorlage testen
Über die Aktion Testen öffnen Sie die Testansicht einer E-Mail-Vorlage. Dort können Sie HTML-Inhalt, Standard-E-Mail-Gerüst, Gruppenbedingung und JSON-Testdaten zusammen rendern.
- Anhänge mit rendern: rendert zusätzlich die dynamischen Dateianhang-Identifier und lädt statische Anhänge auf. Die Vorschau zeigt die erzeugten Anhänge oberhalb des E-Mail-Bodys an.
- PDF herunterladen: konvertiert den aktuell gerenderten HTML-Body in ein PDF und lädt es herunter.
- E-Mail als
.eml: lädt die gerenderte Vorschau als E-Mail-Datei herunter. Wenn die Vorschau mit Anhängen gerendert wurde, enthält die.emldiese Anhänge. - Anhang-Downloads: gerenderte und statische Anhänge können einzeln aus der Vorschau heruntergeladen werden.
- Senden: öffnet ein Modal für E-Mail-Server und Empfängeradresse. Die Mailserver-Auswahl zeigt Identifier, Absender und ID, z.B.
default - service@example.com (#442).
Wenn die Vorschau mit Anhänge mit rendern erzeugt wurde, sendet Senden dieselben Anhänge mit. Ohne gerenderte Anhänge wird nur der aktuelle HTML-Body versendet.
E-Mail-Vorlagen-Integration und Workflow
E-Mail-Vorlagen werden in Output.Rocks in verschiedenen Bereichen verwendet und mit anderen Funktionen kombiniert. Die korrekte Integration ist entscheidend für einen effizienten E-Mail-Versand‑Workflow.
Verwandte Backend-Bereiche
- Standard-E-Mail-Vorlagen: HTML-Gerüste für E-Mail-Vorlagen
- Statische Anhänge: Zusätzliche statische Dateien für E-Mails und PDF-Dokumentvorlagen
- Vorlagen: Dokument-Vorlagen als PDF-Anhänge
E-Mail-Vorlagen-Funktionen
- E-Mail-Templates: Detaillierte Erklärung der E-Mail-Vorlagen-Verwendung
- Statische Anhänge: Anleitung zur Verwendung statischer Anhänge
- Webhooks: Callback-Integration für E-Mail-Events