Automatisierungen ("Flow")

Stand: 2026-08-14. Referenz: n8n-Instanz flow.wjknh.de (WJ Konstanz-Hegau), erhoben 2026-08-13.

Warum dieses Kapitel

Ein Kreisvorstand ist ein Ehrenamt neben dem Beruf. Jede Stunde, die in das Abtippen von Anmeldelisten, das Nachhalten von Geburtstagen oder das Anlegen von Foto-Ordnern fließt, fehlt bei dem, wofür ihr eigentlich angetreten seid: Events, Mitglieder, Wirkung. Automatisierung heißt hier nicht "Roboter statt Mensch", sondern: die immer gleichen Handgriffe zwischen euren Systemen erledigt ein Kurier, und ihr entscheidet nur noch dort, wo Urteilsvermögen gefragt ist. Auf der Referenz-Instanz laufen dafür 10 aktive Workflows (plus 5 inaktive Scaffolds als Ausbaurichtung), die zusammen den Mitglieder- und Event-Lebenszyklus tragen.

Der Kurier ist n8n, im Standard "Flow" genannt. Die Architektur-Regel aus Kapitel 01 gilt für jeden einzelnen Flow: VereinOnline (VO) ist System of Record für Mitglieder und Events, Nextcloud liefert Dateien, Identity und Talk, n8n verbindet beides. Kein Flow hält eigene Stammdaten, alles wird bei Bedarf frisch aus der VO-API gepollt. Die VO-API ist pull-only (keine Webhooks), Polling nicht häufiger als alle 5 Minuten.

Dieses Kapitel besteht aus drei Teilen: dem Flow-Katalog (was ihr bauen könnt, in welcher Reihenfolge, mit welchem Aufwand), den Bauplänen der aktiven Referenz-Flows (wie die Node-Ketten konkret aussehen) und den Betriebs-Basics für eure n8n-Instanz.

Ihr müsst keinen dieser Flows nachbauen: Alle Referenz-Flows liegen als importierbare, kreis-neutrale Templates in flows/ (Instanz-Werte als Platzhalter nach der kreis.conf-Konvention). Import-Weg, Credential-Anlage und Übersicht je Flow: flows/README.md.

Der Flow-Katalog

Status: aktiv = läuft produktiv auf der Referenz-Instanz. scaffold = als inaktives Gerüst angelegt, Ausbaurichtung dokumentiert. idee = noch nicht angelegt, Bauplan liegt vor.

Tier: basis = gehört in jede Kreis-Installation, deckt den Mitglieder- und Event-Lebenszyklus ab. aufbau = zweite Welle, setzt teils Basis-Flows voraus. kuer = optional, erst sinnvoll wenn die Datenbasis steht. Innerhalb jedes Tiers ist nach Wirkung sortiert, nicht nach Status.

Tier Basis: der Kern jeder Installation

1. Mitglieder-Sync VO zu NC (Kern-Flow). Der strategisch wichtigste Flow des Standards: neue aktive Mitglieder in VO bekommen automatisch einen Nextcloud-Account mit den richtigen Themen-Gruppen, Quota und Welcome-Mail mit 2FA-Hinweis; Ausgetretene werden deaktiviert (nie gelöscht) und verlieren ihre Gruppenrechte; Gruppenmitgliedschaften folgen den VO-Rollen. Ohne ihn bleibt jede NC-Berechtigung Admin-Handarbeit, und Austritte hinterlassen verwaiste Accounts mit Zugriff auf interne Dateien, ein DSGVO- und Sicherheitsthema. Das Scaffold auf der Referenz-Instanz erkennt heute nur neue Mitglieder und meldet per Talk; die Anlage wartet auf Vorstands-Sign-off, ein separates NC-Admin-Credential (der Automations-User hat bewusst keine User-Create-Rechte) und geklärte Status-Semantik in VO. Bauweise: GetMembers-Diff gegen die NC-Userliste via OCS, zuerst wochenlang im Dry-Run-Modus (nur Talk-Report, kein Write), Dedup als sichtbare JSON-Datei in Nextcloud statt unsichtbarer staticData. Für vorsichtige Kreise gibt es eine Zwischenstufe beim Onboarding: Statt der Direkt-Anlage schickt der Flow eine Talk-Nachricht mit Bestätigungs-Link (n8n-Webhook), und erst der Klick legt den Account an. Die Offboarding-Stufe braucht zwingend Human-in-the-Loop: Gegenrichtungs-Diff mit False-Positive-Schutz (Abbruch bei Massen-Verschwinden, Username-Check gegen den stillen Anonym-Fallback der VO-API), Talk-Bestätigung durch den Vorstand vor jedem Disable, endgültige Löschung frühestens nach 90 Tagen mit zweiter Bestätigung.

2. Event-Anmeldung Website zu VO. Anmeldungen vom Website-Formular landen direkt in VereinOnline: Mitglieder werden per E-Mail-Match (g_email/p_email) am eigenen Datensatz angemeldet, Unbekannte als Gast. Kein Excel, keine Mail-Kette, VO bleibt einzige Teilnehmerliste. Läuft produktiv, beide Pfade E2E verifiziert. Beim Nachbau sind zwei Fallen Pflicht: ein Verifikations-Schritt gegen den stillen Anonym-Fallback der VO-API (die Anonym-Rolle darf eventAnmelden, ein kaputtes Token schreibt sonst unbemerkt anonym weiter) und das Latin-1-Form-Encoding mit Token als URL-Parameter. Der Schreibzugriff läuft über einen separaten VO-Write-Service-User, nicht über den Lese-Zugang.

3. Erstkontakt Mitglied werden (Website). Der Eintritt in den Lebenszyklus: das Mitglied-werden-Formular der Website schreibt Interessent:innen via CreateSubscriber in eine dedizierte VO-Gruppe, VO verschickt selbst die Double-Opt-In-Mail, das Digital-Team bekommt eine Ping-Mail. Jeder Interessent landet ab Sekunde eins im System of Record statt in einem Mail-Postfach. Beim Nachbau nur Gruppen-ID, CORS-Domains und SMTP tauschen.

4. Event-Reminder-Kette 7d und 24h. Das Team wird 7 Tage und 24 Stunden vor jedem Event mit mindestens einer Anmeldung per Talk erinnert, inklusive vorbereitetem wa.me-Link zum Weiterreichen in die WhatsApp-Gruppe. Der Mensch bleibt im Loop, die ToS-Grauzone einer WhatsApp-Vollautomation wird vermieden. Technik: Zeitfenster jeweils plus/minus 2 h, Dedup getrennt nach reminded7d/reminded1d, Titel-Blacklist für Stammtische und abgesagte Events, Skip bei 0 Anmeldungen.

5. Montagsdigest. Jeden Montag um 08:00 ein Talk-Digest für den Vorstand: Geburtstage und WJ-Jubiläen der kommenden 7 Tage, das Jubiläum errechnet aus dem VO-Feld aufnahmemitglied. Fällt nichts an, wird nichts gesendet. Bewusst ein interner Talk-Kanal mit Mensch im Loop statt WhatsApp-Vollautomation, weil hier personenbezogene Daten (Geburtstage) fließen. Ausbaustufe: die Events der Woche samt Anmeldestand anhängen (GetEvents, Fenster 7 Tage, ca. 0,5 Tage). Voraussetzung je Kreis: api.getmembers=alle in der VO-Basiskonfiguration, sonst fehlen nicht freigegebene Datensätze im Digest.

6. Foto-Drop manuell (Form). Auf Zuruf einen Upload-Ordner für Event-Fotos anlegen und den Share-Link fertig formatiert per Talk liefern. Der Share ist ein File-Drop (shareType=3, permissions=4, nur Upload, kein Lesen), damit Teilnehmende ohne Account und ohne Einblick in fremde Fotos hochladen. Tag-1-tauglich, weil keine VO-Anbindung nötig: nur der NC-Service-User nach wj-bot-Muster mit App-Token und ein Foto-Group-Folder.

7. Neumitglieder-Welcome. Der Übergang von Interessent zu Gast: neue Interessent:innen in VO werden binnen 2 h ans Team gemeldet, damit Begrüßung, Stammtisch-Einladung und Pate sofort passieren statt nach Wochen. Das Scaffold existiert; bis aktiv fehlen vor allem der Nachrichtentext mit Quellenangabe und eine Welcome-Checkliste für das Team. Etwa 1 Tag Restaufwand, keine neuen Credentials nötig.

8. Talk-Event-Ankündigung bei neuem VO-Event. Sobald ein neues Event in VO angelegt wird, geht automatisch eine Ankündigung mit Datum, Ort und Anmeldelink in den Talk-Kanal, wieder mit wa.me-Link zum Weiterreichen. Schließt die Lücke am Anfang der Event-Kommunikation: heute erfährt die Basis erst vom 7-Tage-Reminder davon. Reiner Klon der Reminder-Mechanik, nur der Diff-Filter neuer Event-IDs ist neu. Darum trotz Status idee im Basis-Tier: 0,5 Tage Aufwand bei hoher Sichtbarkeit.

Tier Aufbau: zweite Welle

9. Foto-Drop automatisch nach Event. Der vollautomatische Zwilling des manuellen Foto-Drops: pollt VO-Events und legt pro Event genau einmal den Foto-Drop an, eintägige Events 2 h nach Start, mehrtägige 30 min vor Start. Niemand muss mehr an Fotos denken, der Link liegt fertig im Talk. Läuft produktiv; die Trigger-Logik wurde 2026-06-26 überarbeitet, nachdem genau die GetEvents-Feld-Gotchas (zeit stunde-only, anzahltage fehlend, freieplaetze als String) silent skips verursacht hatten. Der Parser des Nachbaus muss diese Edge-Cases von Anfang an abdecken; Dedup gegen staticData.pushedIds mit Kappung bei 1000 Einträgen.

10. Lead-Formular für Event-Auftritte. Wiederverwendbarer Lead-Funnel für Messen, IHK-Auftritte und eigene Events: ein generisches n8n-Formular, pro Anlass ein QR-Code mit quelle-Parameter als Hidden Field, damit Leads nach Event sortierbar bleiben. Jeder Lead geht als Mail ans Team (Reply-To auf den Absender) und als Zeile in eine n8n-Data-Table. Live seit 2026-07-27, kein VO-Zugriff nötig, der DSGVO-Hinweis im Formular reicht.

11. Datenpflege-Reminder. Das Datenqualitäts-Fundament für alle anderen Flows: ohne geburtstag kein Montagsdigest, ohne aufnahmemitglied kein Jubiläum, ohne aktuelle E-Mail kein Onboarding. Halbjährlich prüft der Flow die Pflichtfelder des Kreises per GetMembers mit felder-Parameter auf leere oder unplausible Werte und schickt dem Vorstand einen nach Feld sortierten Lücken-Digest per Talk. Ausbaustufe: freundliche Mail an betroffene Mitglieder mit Link zum eigenen VO-Profil.

12. Amtsübergabe-Automatik. Beim Vorstandswechsel ziehen die Rollen-Gruppen (Vorstand, Finanzen, AK-Leitungen) in Nextcloud automatisch um: scheidende Amtsträger raus, neue rein, die Group-Folder-Rechte folgen der Gruppenmitgliedschaft von selbst. Der klassische Januar-Blindflug entfällt, in dem der alte Vorstand noch alles sieht und der neue noch nichts. Quelle ist das rollen-Feld aus VO. Ablauf mit Human-in-the-Loop: Rollen-Snapshot alt/neu diffen, Änderungsliste als Talk-Nachricht an die Kreissprecherin, Gruppen-Moves erst nach Bestätigung, danach Abschluss-Report. Setzt den Kern-Flow und dessen NC-Admin-Credential voraus.

13. Protokoll-Pipeline für Sitzungen. Vor jeder Sitzung legt der Flow den Sitzungsordner im Group Folder des Gremiums an und kopiert die Protokoll-Vorlage hinein, der Talk-Raum bekommt den Direktlink zur Bearbeitung in Collabora. Protokolle entstehen am selben Ort, an dem sie abgelegt werden, immer im Schema YYYY-MM-DD, nichts versandet in Mail-Anhängen. Die Sitzungs-Erkennung nutzt per Titel-Whitelist genau die Events, die der Foto-Drop als Blacklist wegfiltert; alle Bausteine existieren bereits und werden nur neu verdrahtet. Ausbaustufe: 48 h nach der Sitzung ein PROPFIND-Check auf das Änderungsdatum, und solange das Dokument beim Template-Stand steht, erinnert der Flow das Gremium.

14. Kennzahlen-Snapshot Mitgliederentwicklung. Am Monatsersten einen Kennzahlen-Schnitt ziehen: aktive Mitglieder, Interessenten, Ein- und Austritte seit Vormonat, grobe Altersstruktur (relevant für die WJ-Altersgrenze). Der Kurzreport mit Vormonats-Delta geht in den Vorstands-Talk, zusätzlich hängt der Flow eine Zeile an eine CSV-Zeitreihe im Vorstands-Group-Folder. So wird die Entwicklung über Jahre sichtbar und ist für Mitgliederversammlung wie WJD-Meldung abrufbar. Reiner Read-Flow ohne neue Credentials; der max-Parameter von GetMembers wird ignoriert, Eingrenzung nur über filter. Voraussetzung: api.getmembers=alle.

15. Alumni-Übergang (Altersgrenze 40). Die harte WJ-Lebenszyklus-Kante planbar machen: ein monatlicher Report, wer im laufenden Kalenderjahr 40 wird, mit Checkliste für Verabschiedung, Förderkreis-Angebot und VO-Gruppenwechsel. Zum Jahreswechsel folgt als Ausbaustufe der bestätigte NC-Gruppen-Umzug von Mitglieder- auf Alumni-Gruppen: Archiv-Lesezugriff bleibt, operativer Schreibzugriff endet. Der Umzug folgt dem Bestätigungs-Muster des Offboardings und setzt das NC-Admin-Credential des Kern-Flows voraus. Report allein: 1 Tag, ohne neue Abhängigkeiten.

16. Feedback-Bogen nach Event. 24 h nach Event-Ende liegt ein vorbereiteter Feedback-Link im Talk, den das Orga-Team per Tap in die Teilnehmer-Gruppe weiterreicht. Antworten landen anonym in einer Data-Table, ein Montags-Digest fasst die Vorwoche zusammen. Damit bekommt der Vorstand erstmals systematische Event-Qualitätsdaten ohne Zettelwirtschaft. Personenbezug wird bewusst vermieden: anonymes Formular ohne Pflicht-Namensfeld.

17. Jahresplanungs-Scaffold. Einmal im Q4 per Formular das neue Geschäftsjahr aufsetzen: Jahresordner-Bäume in den Group Folders (Sitzungen, Events, Finanzen, Fotos) und auf Wunsch die wiederkehrenden Jour-fixe- und Stammtisch-Termine als Serie direkt in VO anlegen. Der neue Vorstand startet in eine fertige Struktur statt in leere Ordner, und VO bleibt führend für alle Termine. Der CreateEvent-Pfad ist auf der Referenz-Instanz mit einem eigenen Event-Service-User verprobt; die Encoding-Falle gilt auch hier, und sichtbar:0 ist bei API-angelegten Events der Normalzustand, nicht reparieren.

18. Gast-Aktivierungs-Radar. Den Blindflug im Gast-zu-Mitglied-Funnel beenden: der Flow kreuzt die Interessenten-Gruppe mit Event-Teilnahmen und meldet dem Team einmalig, wenn ein Gast den Schwellwert erreicht (Vorschlag: zweite Teilnahme) und reif für das Mitgliedschafts-Gespräch ist. Wichtige Einschränkung: Ein VO-Endpoint für Teilnehmerlisten ist im dokumentierten Wissen nicht verifiziert. Vor dem Bau steht deshalb eine API-Probe; liefert VO die Listen nicht, fällt der Flow auf den Anmelde-Webhook als Datenquelle zurück.

Tier Kür: optional, wenn die Datenbasis steht

19. Social-Media-Vorlagen aus Eventdaten. Für jedes anstehende Event generiert ein LLM Entwürfe für Instagram und LinkedIn aus den VO-Eventdaten und legt sie dem Marketing-Team per Talk zur Freigabe vor. Kein Auto-Posting: der Mensch redigiert und veröffentlicht, der Flow liefert nur den Rohtext. Das Scaffold existiert, die LLM-Anbindung ist als TODO markiert. Die Kreis-Tonalität gehört als Systemprompt in den Workflow, nicht hart in den Code, damit jeder Kreis sie ohne Programmierung anpasst.

20. Aktivierungs-Score (quartalsweise). Quartalsweise ein einfacher Engagement-Score über die Mitgliederbasis (Event-Teilnahmen gewichtet, Ämter aus dem rollen-Feld, Beitrittsdatum), als Talk-Digest an den Vorstand: Top-Engagierte für Wertschätzung, stille Mitglieder fürs Nachfassen, bevor der Austritt kommt. Ehrliche Einordnung: erst sinnvoll, wenn die Lifecycle-Flows laufen und der Kennzahlen-Snapshot einige Monate Daten geliefert hat, vorher misst der Score nur Datenlücken. Die Teilnahme-Historie je Mitglied ist als VO-Fähigkeit unverifiziert und braucht vor dem Bau eine API-Probe. Ergebnis bleibt intern und rollenbasiert formuliert, keine Ranglisten in breite Kanäle.

Baupläne der aktiven Referenz-Flows

Die folgenden Node-Ketten sind der Serverstand der Referenz-Instanz (erhoben 2026-08-13). Sie sind als Nachbau-Vorlage gedacht: gleiche Kette, eigene Credentials, eigene Kreis-Parameter (Domains, Gruppen-IDs, Talk-Raum). Den Ziel-Raum für Talk-Nachrichten sprecht ihr über sein Raum-Token an; ihr findet es in der URL des Raums (/call/<token>) oder legt den Raum geskriptet per occ talk:room:create an. Der Bot-User muss Mitglied des Raums sein, bevor er hineinschreiben kann.

Foto-Drop manuell: Form Trigger (Event-Name, Event-Datum) → Code "Build Paths" (Slug, Ordnerpfad /09_Fotos/<datum>_<slug>) → HTTP MKCOL auf WebDAV (remote.php/dav/files/<bot-user>/...) → HTTP POST OCS Share API (shareType=3, permissions=4) → Code "Build Message" (wa.me-Link mit vorbefülltem Text) → HTTP POST Talk-Chat-API (interner Team-Raum).

Foto-Drop automatisch: Schedule alle 10 min → HTTP POST VO ?api=GetEvents (Filter datum >= now-14d) → Code "Filter: Window+Blacklist+Pushed" (Zeitfenster, Blacklist-Regex, Dedup gegen staticData.pushedIds, max. 1000 Einträge) → Build Paths → WebDAV MKCOL → OCS File-Drop-Share → Build Message → Talk-DM → Code "Mark as Pushed".

Event-Reminder 7d/24h: Schedule alle 4 h → VO ?api=GetEvents (datum >= heute) → Code "Filter: 7d + 1d Windows" (Fenster jeweils +/- 2 h, Dedup getrennt nach reminded7d/reminded1d, Skip bei 0 Anmeldungen) → Code "Build Reminder" → Talk-DM → Code "Mark as Reminded".

Montagsdigest: Schedule Mo 08:00 → VO ?api=GetMembers (felder: vorname, nachname, geburtstag, aufnahmemitglied, rollen) → Code "Filter: Birthdays + Anniversaries" → Code "Build Combined Digest" → Talk-DM.

Event-Anmeldung Website: Webhook POST /webhook/event-anmeldung (CORS-Allowlist auf die Kreis-Domains) → IF "Eingaben gültig?" (Pflichtfelder, E-Mail-Plausibilität, DSGVO-Consent) → VO ?api=GetMembers → Code "Mitglied matchen" (g_email/p_email) → VO ?api=CreateRegistration (Write-Credential) → IF "VO Erfolg?" → Respond-Nodes (200 OK / 502 VO-Fehler / 400 Eingabefehler).

Erstkontakt Mitglied werden: Webhook POST /webhook/erstkontakt → IF-Validierung (Pflichtfelder, DSGVO, Honeypot) → VO ?api=CreateSubscriber (dedizierte Interessenten-Gruppe, VO macht Double-Opt-In) → IF "VO Erfolg?" → emailSend "Ping ans Digital-Team" → Respond 200 / 502 / 400.

Kontaktformular und Newsletter-Anmeldung sind strukturgleiche Vereinfachungen: das Kontaktformular ist ein reines Mail-Relay (Webhook → IF-Validierung inkl. Honeypot-Feld website → emailSend mit Reply-To auf den Absender → Respond), die Newsletter-Anmeldung ist der Erstkontakt-Flow ohne Ping-Mail mit eigener VO-Zielgruppe.

Lead-Formular: n8n Form Trigger unter /form/wj-kontakt; pro Event ein QR-Code auf ?quelle=<event-slug>, ein Hidden Field übernimmt den Query-Param. Felder: Name, Unternehmen, E-Mail, Telefon, Interesse, Nachricht, DSGVO-Hinweis. Jeder Lead geht als Mail ans Team und als Zeile in die Data-Table.

Vier Muster ziehen sich durch alle Ketten und gelten im Standard als Bauregeln. Erstens: VO bleibt System of Record, kein Workflow hält eigene Mitglieder- oder Eventdaten. Zweitens: Talk ist der interne Push-Kanal, oft mit vorbereitetem wa.me-Link, damit ein Mensch die Nachricht per Tap in die WhatsApp-Gruppe weiterreicht statt sie zu automatisieren. Drittens: Einmaligkeit (schon gepusht, schon erinnert) wird über staticData-Listen mit Kappung bei 1000 Einträgen gesichert; für kritische Flows empfiehlt sich als Ausbaustufe eine sichtbare JSON-Datei in Nextcloud. Viertens: jedes Formular-Backend hat CORS-Allowlist, Pflichtfeld-Validierung, DSGVO-Consent-Prüfung, Honeypot und saubere JSON-Fehlerantworten (400/502).

n8n-Betriebs-Basics

Credentials-Hygiene

Der wichtigste Grundsatz: getrennte Service-User mit minimalen Rechten statt eines Admin-Accounts, auf beiden Seiten der Brücke.

Auf VO-Seite hat sich ein Drei-User-Muster bewährt: ein Lese-User für Sync und Anzeige, ein Write-User nur für Anmeldungen und Kontakte, ein Event-User nur für Event-Verwaltung. API-User dürfen ausdrücklich nicht Admin sein. Das VO-Token hängt am Passwort-Hash des Service-Users (Format A/<username>/<md5(passwort)>); MD5 ist kryptografisch schwach, deshalb sind starkes Passwort plus HTTPS Pflicht, und Token-Rotation heißt Passwortwechsel.

Auf Nextcloud-Seite läuft alles über einen dedizierten Bot-User (Muster wj-bot) in einer eigenen Automation-Gruppe, mit App-Token statt Login-Passwort und bewusst ohne Admin- oder User-Create-Rechte. Der einzige Group Folder mit Schreibrecht für diese Gruppe ist der Foto-Ordner. Ein Hinweis zur Token-Erzeugung: Per occ user:auth-tokens:add --no-interaction erzeugte App-Token haben eingeschränkte Fähigkeiten (Datei- und API-Operationen ja, Admin-Operationen mit Login-Passwort-Pflicht nein); wo volle Rechte nötig sind, gehört ein über die Weboberfläche erzeugtes App-Passwort her.

In n8n selbst gelten vier Regeln. Erstens: N8N_ENCRYPTION_KEY ist der kritischste Einzelwert der Instanz; sein Verlust macht alle gespeicherten Credentials unentschlüsselbar (die Workflows bleiben intakt). Sicher ablegen, nie in Doku oder Chat. Zweitens: Secret-Werte gehören ausschließlich in n8n-Credentials bzw. serverseitige Dateien, niemals in Workflow-JSON, Doku oder den Standard-Text; dokumentiert werden nur Credential-Namen. Drittens: Workflow-Edits laufen chirurgisch per REST (GET → lokal patchen → PUT, wobei das settings-Objekt beim PUT auf {"executionOrder":"v1"} reduziert werden muss), nicht über Werkzeuge, die Credential-Referenzen aus HTTP-Nodes strippen; passiert es doch, Credentials via UI neu anhängen. Viertens: beim JSON-Import hängt das Credential oft als "Referenz da, Auth None" im Node und liefert 401 trotz grünem Haken; Fix ist Credential löschen und neu anlegen.

Webhook, Schedule oder Form?

Die Trigger-Wahl folgt der Frage, wer den Anstoß gibt. Webhook, wenn ein fremdes System (eure Website) aktiv anklopft: sofortige Reaktion, aber öffentlich erreichbar, deshalb immer mit CORS-Allowlist, Validierung, Honeypot und Fehlerpfaden. Schedule, wenn ihr VO abfragen müsst: die VO-API kennt keine Webhooks, alles Ereignis-artige (neues Event, neues Mitglied) wird durch Polling plus Diff simuliert, nicht häufiger als alle 5 Minuten, und braucht deshalb immer eine Dedup-Logik. Form Trigger, wenn ein Mensch aus dem Team etwas anstößt (Foto-Drop, Leads): n8n hostet das Formular selbst, keine Website-Änderung nötig.

Testen

Vier Praktiken aus dem Referenz-Betrieb, die Fehlersuche von Stunden auf Minuten verkürzen:

1. Dry-Run vor Write. Jeder Flow, der schreibt (VO-Registrierungen, später NC-Accounts), läuft zuerst im Nur-Melden-Modus: gleiche Logik, aber statt des Writes nur ein Talk-Report. Beim Kern-Flow heißt das: wochenlang Dry-Run, bevor der erste Account angelegt wird.
2. Beide Pfade E2E. Ein Webhook-Flow ist erst fertig, wenn Erfolgs- und Fehlerpfad mit echten Requests verifiziert sind (die Event-Anmeldung der Referenz wurde so 2026-07-03 abgenommen: Mitglied-Pfad und Gast-Pfad).
3. Anonym-Fallback prüfen. Ein ungültiges VO-Token erzeugt keinen Auth-Fehler, die API antwortet mit anonymen Basisrechten weiter. Nach jedem Credential-Wechsel gehört deshalb ein Verifikations-Call dazu, der den erwarteten Usernamen in der Antwort prüft.
4. Formulare im Browser testen. n8n-Formulare mit ignoreBots:true beantworten curl-Tests mit 401; zum Testen Browser oder Browser-User-Agent verwenden.

Dazu die Umlaute-Regel für alle VO-Write-Endpoints: application/x-www-form-urlencoded mit Latin-1-prozentkodierten Werten, Token als URL-Parameter (der Authorization-Header wird bei Form-Encoding ignoriert). UTF-8-JSON führt zu doppelkodierten Umlauten, Latin-1-JSON zu Parser-Fehlern.

Betrieb der Instanz

Das Referenz-Deployment ist bewusst klein: n8n als Docker-Container mit SQLite, gebunden nur auf 127.0.0.1, public über einen Apache-Reverse-Proxy mit Let's-Encrypt-TLS und WebSocket-Upgrade. Beim Public-Schalten müssen N8N_HOST, N8N_PROTOCOL, WEBHOOK_URL, N8N_EDITOR_BASE_URL und N8N_SECURE_COOKIE konsistent umgestellt werden; das Daten-Verzeichnis bleibt unangetastet. Härtung: Diagnostics aus, genau ein Owner-Account auf einer Vereins-Adresse (nicht auf einer persönlichen), 2FA für den Owner. Als Empfehlung für jeden Kreis, auf der Referenz-Instanz selbst noch offen: ein Backup-Cron für das n8n-Datenverzeichnis, Egress-Restriktion und eine dokumentierte Update-Strategie.

Checkliste

VO-Vorbereitung je Kreis:

• api.getmembers=alle in der VO-Basiskonfiguration gesetzt? (Sonst fehlen nicht freigegebene Datensätze; in der Referenz waren es 95 von 162 Mitgliedern.)
• api.events.alledaten=ja gesetzt?
• Drei VO-Service-User angelegt (Lesen / Anmeldungen / Events), keiner davon Admin?
• Verifikations-Call nach Credential-Anlage: erwarteter Username in der API-Antwort?

n8n-Instanz:

• N8N_ENCRYPTION_KEY sicher abgelegt, Konsequenz bei Verlust dokumentiert?
• Genau ein Owner, auf Vereins-Adresse, 2FA aktiv, Diagnostics aus?
• Instanz bindet nur auf localhost, public nur via Reverse-Proxy mit TLS?
• Backup-Cron für das n8n-Datenverzeichnis eingerichtet?
• NC-Bot-User in Automation-Gruppe mit App-Token, ohne Admin-Rechte?

Jeder einzelne Flow vor dem Aktivieren:

• VO-Write-Endpoints: form-urlencoded in Latin-1, Token als URL-Parameter?
• Write-Flow hat Verifikations-Schritt gegen den Anonym-Fallback?
• GetEvents-Parser deckt zeit (stunde-only), anzahltage (String/fehlend), freieplaetze (String) ab?
• Schedule-Flow: Polling-Intervall nicht unter 5 Minuten, Dedup mit Kappung vorhanden?
• Webhook-Flow: CORS-Allowlist, Pflichtfeld-Validierung, DSGVO-Consent, Honeypot, JSON-Fehler 400/502?
• Personenbezogene Digests (Geburtstage) gehen nur in einen internen Talk-Kanal, nicht in breite Kanäle?
• Erfolgs- und Fehlerpfad E2E getestet, Formulare im Browser?
• Nach JSON-Import: Credentials neu angelegt und im Node verifiziert (kein "Auth None")?

Referenz KNH

So läuft es bei Konstanz-Hegau konkret (Stand 2026-08-13): Die n8n-Instanz läuft als Docker-Container auf dem Server hafen, gebunden auf 127.0.0.1:5678, öffentlich als flow.wjknh.de hinter einem Apache-vHost mit Let's-Encrypt-Zertifikat. Darauf liegen 15 Workflows, 10 aktiv und 5 inaktive Scaffolds; die aktiven decken die Katalog-Flows 2, 3, 4, 5, 6, 9 und 10 ab, dazu Kontaktformular, Newsletter-Anmeldung und ein projektspezifischer Newsletter-Klon für die LAKO29-Website. Die Scaffolds entsprechen den Katalog-Flows 1, 7, 19 und 20 plus einem Presse-Monitoring-Platzhalter ohne funktionierende Quelle.

Vier Credentials tragen den Betrieb (nur Namen, Werte liegen ausschließlich in n8n bzw. serverseitig): VO Header Auth (KNH-Prod) für den lesenden VO-Service-User der Lese-User (read-only seit dem Lockdown 2026-05-13), ein VO-Write-Zugang (der Write-User) für CreateRegistration und CreateSubscriber, Hafen wj-bot für die Nextcloud-APIs (WebDAV, OCS Share, Talk) über den NC-User wj-bot in der Automation-Gruppe, und Hafen@ SMTP für Mailversand als hafen@wj-konstanz-hegau.de. Für Event-Anlage existiert zusätzlich der Service-User der Event-User (Token im HQ-SOPS-Vault als WJ_VO_EVENTS_API_TOKEN). Alle proaktiven Benachrichtigungen gehen als Talk-DM an die Stabsstelle Digitales, die sie bei Bedarf per wa.me-Link in die WhatsApp-Gruppe weiterreicht.

JSON-Snapshots von 9 der 15 Workflows liegen im Repo unter wj/Nextcloud/n8n-workflows/ (Stand 2026-05-13; die Website- und Lead-Workflows vom Juli 2026 und der Foto-Drop-Fix vom 2026-06-26 fehlen dort, für Nachbauten gilt der Serverstand). Die Build-Doku zum Foto-Drop-Trigger inklusive aller VO-Feld-Gotchas steht in wj/Nextcloud/n8n-event-photo-drop.md, das Public-Endpoint-Runbook in wj/Nextcloud/setup-flow-public-endpoint.md. Offen auf der Referenz-Instanz sind Backup-Cron, Egress-Restriktion, der Abschluss der Owner-2FA und die Klärung, ob die VO-Anonym-Rolle das Recht eventAnmelden verlieren kann.