Die Kündigung eines SaaS-Kontos mit Karenzzeit ist kein einzelner, aufgeschobener Vorgang. Sie ist ein Lebenszyklusprozess, der Zugriff, Abrechnung, automatische Aufgaben, Integrationen und Daten koordinieren muss. Speichert die Anwendung lediglich ein Schließungsdatum und prüft es bei der Anmeldung, können andere Prozesse weiterhin so arbeiten, als wäre die Organisation aktiv.
Im Design muss eindeutig festgelegt sein, was die einzelnen Phasen bedeuten, wer einen Übergang auslösen darf und welche Auswirkungen reversibel sind. So ist das Zurückziehen des Antrags nicht gleichbedeutend damit, das Konto von Grund auf neu aufzubauen, und das Erreichen des Stichtags hängt nicht davon ab, dass sich ein Benutzer erneut anmeldet.
Antrag, Sperrung und endgültige Schließung trennen
Der Antrag bringt eine Absicht zum Ausdruck: Eine autorisierte Person beantragt die Schließung des Kontos. Die Sperrung legt fest, was die Organisation tun kann, während der Antrag bearbeitet wird. Bei der endgültigen Schließung werden die abschließenden Maßnahmen ausgeführt. Dazu können der Widerruf von Zugangsdaten, das Anhalten von Prozessen und die Anwendung der Datenrichtlinie gehören. Das sind unterschiedliche Zeitpunkte, die getrennt modelliert werden sollten.
Eine wichtige Produktentscheidung ist, wann die Zugriffsbeschränkung beginnt. Bleibt der Zugriff bis zum Ablauf der Frist bestehen, muss dies klar kommuniziert und die Nutzung während dieser Zeit kontrolliert werden. Wird der Zugriff sofort eingeschränkt, dient die Karenzzeit der Wiederherstellung des Kontos und nicht der normalen Weiternutzung des Dienstes. Es gibt keine allgemeingültige Lösung: Sie hängt vom Geschäftsmodell, den Risiken und den Verpflichtungen des Produkts ab.
Auch die Folgen für Abrechnung und Abonnements müssen festgelegt werden. Die Kündigung des Kontos beendet nicht unbedingt ein externes Abonnement, und die Stornierung einer Zahlung sollte eine Organisation nicht löschen. Legen Sie für jede Entscheidung die maßgebliche Quelle fest und leiten Sie den Betriebszustand nicht aus einem einzelnen Ereignis des Zahlungsanbieters ab.
Zustände und zulässige Übergänge festlegen
Ein explizites Modell erleichtert es der Benutzeroberfläche, der API und Hintergrundjobs, dieselben Regeln anzuwenden. Ein einfacher Ablauf kann Zustände wie active, deletion_requested, suspended und closed verwenden. Erfolgt die Sperrung gleichzeitig mit dem Antrag, genügt möglicherweise ein einzelner Antragszustand mit Attributen, die dessen Einschränkungen beschreiben. Fügen Sie keine Zustände hinzu, die keinen tatsächlichen betrieblichen Unterschied abbilden.
Dokumentieren Sie die gültigen Übergänge. Beispielsweise kann eine aktive Organisation die Kündigung beantragen, ein gültiger Antrag kann zurückgezogen werden und ein abgelaufener Antrag kann in die endgültige Schließung übergehen. Eine geschlossene Organisation sollte im Allgemeinen nicht durch dieselbe Aktion zum Zurückziehen des Antrags wieder geöffnet werden: Eine Wiederherstellung benötigt, sofern sie angeboten wird, ein separates Verfahren mit klaren Grenzen.
- Protokollieren Sie, wer den Antrag gestellt hat, wann und über welchen Kanal sowie wann die Frist endet.
- Prüfen Sie Berechtigungen und aktuellen Zustand auf dem Server, nicht nur in der Benutzeroberfläche.
- Weisen Sie wiederholte Übergänge und gleichzeitige Anträge zurück oder behandeln Sie sie ausdrücklich.
- Speichern Sie Zustandsänderungen atomar und veröffentlichen Sie Nebenwirkungen über ein zuverlässiges Muster, etwa eine transaktionale Outbox.
In einer PHP-Anwendung sollten die Übergangsregeln in einem Domain-Service oder einer gleichwertigen Schicht zentralisiert werden. Controller sollten nicht direkt mehrere Felder ändern und davon ausgehen, dass alle Verbraucher die neue Semantik kennen. Die Datenbank muss genügend Informationen enthalten, damit ein ausstehender Prozess bestimmen kann, welche Aktion erforderlich ist, ohne vom Zustand einer früheren Webanfrage abzuhängen.
Zugriffe begrenzen und ausstehende Prozesse eindämmen
Legen Sie fest, welche Berechtigungen die einzelnen Rollen während der Karenzzeit haben. Ein Administrator könnte die Kündigung zurückziehen und die für einen Export erforderlichen Informationen einsehen dürfen, während Mitglieder der Organisation gesperrt werden. Wenn ein schreibgeschützter Zugriff erlaubt ist, geben Sie an, welche Ressourcen davon erfasst werden und ob APIs, Downloads und Verwaltungsfunktionen verfügbar bleiben. Dieselbe Kontrolle muss für Benutzeroberfläche, API und automatisierte Jobs gelten.
Die Anmeldung zu blockieren reicht nicht aus. Zugriffstoken, API-Schlüssel, aktive Sitzungen und Zugangsdaten für Integrationen können weiterhin funktionieren. Legen Sie fest, welche widerrufen, pausiert oder vorübergehend beibehalten werden. Werden Zugangsdaten widerrufen, protokollieren Sie diese Auswirkung, damit die Reaktivierung nicht von nicht mehr vorhandenen Geheimnissen abhängt; möglicherweise müssen neue Zugangsdaten erstellt werden.
Überprüfen Sie Warteschlangen und geplante Aufgaben, etwa den Versand von Nachrichten, Synchronisierungen, Berichte, Webhooks und Abrechnungsjobs. Jeder Prozess muss den aktuellen Zustand der Organisation unmittelbar vor einer Operation mit externen Auswirkungen prüfen. Bereits in die Warteschlange eingestellte Jobs können je nach ausdrücklich festgelegter Richtlinie abgebrochen, zurückgehalten oder abgeschlossen werden. Gehen Sie nicht davon aus, dass eine Änderung des Kontozustands Nachrichten automatisch aus einer verteilten Warteschlange entfernt.
Auch das Abbrechen einer Aufgabe muss idempotent sein. Ein Job, der nach einem Netzwerkfehler erneut ausgeführt wird, sollte weder eine Benachrichtigung noch einen Schließungsvorgang duplizieren. Verwenden Sie geeignete Ereignis-IDs, Idempotenzschlüssel oder Eindeutigkeitsbedingungen und protokollieren Sie die Ergebnisse, damit ein sicherer Wiederholungsversuch von einer neuen Aktion unterschieden werden kann.
Das Zurückziehen der Kündigung und die Reaktivierung sicher gestalten
Während der Karenzzeit sollte das Zurückziehen des Antrags ein klar definierter Übergang sein und keine Routine, die ungeprüft „alles rückgängig macht“. Der Vorgang muss prüfen, ob die Frist noch läuft, den Zustand genau einmal aktualisieren und nur diejenigen Funktionen wiederherstellen, die ausgesetzt wurden und weiterhin gültig sind.
Um Duplikate zu vermeiden, sollten Abonnements, Webhooks, geplante Aufgaben, Arbeitsbereiche oder Zugangsdaten nicht wahllos neu erstellt werden. Behalten Sie stabile Kennungen bei und erfassen Sie den Status jeder Nebenwirkung. Wurde eine externe Komponente bereits beendet, muss die Anwendung sie abgleichen können: feststellen, ob sie noch vorhanden ist, sie kontrolliert neu erstellen oder darauf hinweisen, dass ein manueller Eingriff erforderlich ist.
Eine idempotente Reaktivierung führt zum selben Endzustand, auch wenn sie mehrmals angefordert wird. Dies lässt sich durch Transaktionen für lokale Änderungen, Aktualisierungen statt blinder Einfügungen und eine Wiederholungsstrategie für externe Systeme unterstützen. Schlägt der Vorgang mittendrin fehl, protokollieren Sie die abgeschlossenen Schritte und ermöglichen Sie die Fortsetzung, ohne bereits erfolgreiche Schritte zu wiederholen.
Daten, Nachvollziehbarkeit und endgültige Schließung berücksichtigen
Die betriebliche Schließung und die Löschung von Daten sind unterschiedliche Entscheidungen. Legen Sie fest, was mit den Daten der Organisation, Sicherungskopien, Audit-Protokollen und Informationen geschieht, die aufgrund gesetzlicher oder vertraglicher Pflichten aufbewahrt werden. Die geltenden Fristen und Gründe hängen vom Kontext und der Gerichtsbarkeit ab und sollten mit den Verantwortlichen für Datenschutz und Compliance geprüft werden. Informieren Sie den Kunden gemäß der geltenden Richtlinie darüber, was gelöscht und was wie lange aufbewahrt wird.
Nach Ablauf der Karenzzeit muss ein geplanter Prozess ausstehende Anträge ermitteln und Zustand sowie Frist vor der Kontoschließung erneut prüfen. Bei einem Teilausfall muss das System den fehlgeschlagenen Schritt protokollieren und eine Fortsetzung ermöglichen. Ein Flag closed beweist für sich allein nicht, dass Zugangsdaten widerrufen oder Integrationen angehalten wurden.
Sorgen Sie für eine nachvollziehbare Aufzeichnung der Anträge, Zurückziehungen, Berechtigungsänderungen, abschließenden Ausführungen und Fehler. Beschränken Sie den Zugriff auf diese Protokolle und vermeiden Sie unnötige Geheimnisse oder personenbezogene Daten. Warnmeldungen sollten Fälle anzeigen, die länger als erwartet andauern, etwa Organisationen, deren Frist abgelaufen ist, die aber noch aktiv sind, oder Schließungen, die durch wiederholte Fehler blockiert werden.
Checkliste zum Testen des Ablaufs
- Eine Person ohne die erforderlichen Berechtigungen kann die Kündigung weder beantragen noch zurückziehen.
- Ein zweimaliger Kündigungsantrag erzeugt keine doppelten Fristen, Ereignisse oder Schließungen.
- Die Rollen verfügen während der Karenzzeit genau über die vorgesehenen Berechtigungen.
- Sitzungen, Token, APIs, Warteschlangen und Integrationen berücksichtigen den Zustand der Organisation.
- Wird der Antrag vor Ablauf der Frist zurückgezogen, wird der vorgesehene Zugriff wiederhergestellt, ohne Prozesse oder Ressourcen zu duplizieren.
- Ein abgelaufener Antrag wird weder durch eine verspätete Anfrage zurückgezogen noch zweimal abgeschlossen.
- Teilausfälle und Wiederholungsversuche ermöglichen den Abschluss, ohne externe Auswirkungen zu wiederholen.
- Die Regeln zur Aufbewahrung und Löschung von Daten werden getrennt von der betrieblichen Sperrung geprüft.
Testen Sie außerdem gleichzeitige Änderungen, Verzögerungen in Warteschlangen und Fehler externer Anbieter. Ein konsistentes Design zeigt sich nicht nur daran, dass auf dem Bildschirm „Konto geschlossen“ steht, sondern daran, dass Berechtigungen, Prozesse, Zugangsdaten und Daten dieselbe Entscheidung widerspiegeln und das System erklären kann, wie es diesen Zustand erreicht hat.
