Een SaaS-account beëindigen met een respijtperiode is niet één uitgestelde handeling. Het is een levenscyclusproces dat toegang, facturering, automatische taken, integraties en gegevens op elkaar moet afstemmen. Als de applicatie alleen een sluitingsdatum opslaat en die bij het inloggen controleert, kunnen andere processen blijven werken alsof de organisatie actief is.
Het ontwerp moet expliciet maken wat elke fase inhoudt, wie een overgang mag uitvoeren en welke gevolgen omkeerbaar zijn. Zo is het annuleren van de aanvraag niet hetzelfde als het vanaf nul opnieuw opbouwen van het account, en is het bereiken van de deadline niet afhankelijk van het feit dat een gebruiker opnieuw inlogt.
Aanvraag, opschorting en definitieve sluiting scheiden
De aanvraag geeft een intentie weer: een bevoegde persoon verzoekt het account te sluiten. De opschorting bepaalt wat de organisatie mag doen zolang die aanvraag wordt afgehandeld. Bij de definitieve sluiting worden de laatste acties uitgevoerd. Die kunnen bestaan uit het intrekken van inloggegevens, het stoppen van processen en het toepassen van het gegevensbeleid. Dit zijn verschillende momenten en het is verstandig ze afzonderlijk te modelleren.
Een belangrijke productbeslissing is wanneer de toegangsbeperking ingaat. Als de toegang tot het verstrijken van de termijn behouden blijft, moet dit duidelijk worden gecommuniceerd en moet het gebruik gedurende die periode worden beheerd. Als de toegang onmiddellijk wordt beperkt, dient de respijtperiode om het account te herstellen, niet om de dienst normaal te blijven gebruiken. Er is geen universele keuze: die hangt af van het commerciële model, de risico's en de verplichtingen van het product.
Ook de gevolgen voor facturering en abonnementen moeten worden bepaald. Het beëindigen van een account annuleert niet noodzakelijkerwijs een extern abonnement, en een betalingsannulering mag een organisatie niet verwijderen. Verduidelijk voor elke beslissing wat de bron van waarheid is en leid de operationele status niet af uit één afzonderlijke gebeurtenis van de betalingsprovider.
Toestanden en toegestane overgangen definiëren
Een expliciet model maakt het eenvoudiger om de interface, API en achtergrondtaken dezelfde regels te laten toepassen. Een eenvoudige workflow kan toestanden gebruiken zoals active, deletion_requested, suspended en closed. Als de opschorting tegelijk met de aanvraag plaatsvindt, volstaat mogelijk één aanvraagstatus met kenmerken die de beperkingen beschrijven. Voeg geen toestanden toe die geen werkelijk operationeel verschil vertegenwoordigen.
Leg de geldige overgangen vast. Een actieve organisatie kan bijvoorbeeld om beëindiging verzoeken; een lopende aanvraag kan worden geannuleerd; en een aanvraag waarvan de termijn is verstreken, kan overgaan naar definitieve sluiting. Een gesloten organisatie zou in het algemeen niet opnieuw moeten worden geopend met dezelfde annuleringshandeling: als herstel wordt aangeboden, is daarvoor een andere procedure met duidelijke grenzen nodig.
- Leg vast wie de aanvraag heeft gestart, wanneer en via welk kanaal, en wanneer de respijtperiode afloopt.
- Controleer machtigingen en de huidige status op de server, niet alleen in de interface.
- Weiger herhaalde en gelijktijdige overgangen, of handel ze expliciet af.
- Sla statuswijzigingen atomair op en publiceer neveneffecten via een betrouwbaar patroon, zoals een transactionele outbox.
Centraliseer de overgangsregels in een PHP-applicatie in een domeinservice of een gelijkwaardige laag. Controllers moeten niet rechtstreeks meerdere velden wijzigen in de veronderstelling dat alle afnemers de nieuwe semantiek begrijpen. De database moet voldoende informatie bewaren zodat een proces in behandeling kan bepalen welke actie nodig is, zonder afhankelijk te zijn van de status van een eerder webverzoek.
Toegang beperken en lopende processen beheersen
Bepaal welke mogelijkheden elke rol tijdens de respijtperiode heeft. Een beheerder kan bijvoorbeeld toestemming hebben om de beëindiging te annuleren en informatie te raadplegen die nodig is voor export, terwijl leden van de organisatie worden geblokkeerd. Als alleen-lezen-toegang is toegestaan, specificeer dan op welke resources die van toepassing is en of API's, downloads en beheerfuncties beschikbaar blijven. Dezelfde controle moet gelden in de interface, de API en geautomatiseerde taken.
Alleen het blokkeren van inloggen is niet voldoende. Toegangstokens, API-sleutels, actieve sessies en inloggegevens van integraties kunnen blijven werken. Bepaal welke je intrekt, welke je pauzeert en welke je tijdelijk behoudt. Als je inloggegevens intrekt, leg dan het effect vast zodat reactivering niet afhankelijk is van geheimen die niet meer bestaan; het kan nodig zijn om ze opnieuw te laten aanmaken.
Controleer wachtrijen en geplande taken, zoals verzendingen, synchronisaties, rapporten, webhooks en factureringstaken. Elk proces moet de actuele status van de organisatie controleren vlak voordat het een handeling met externe gevolgen uitvoert. Taken die al in de wachtrij staan, kunnen worden geannuleerd, in de wacht gezet of volgens een expliciet beleid worden voltooid. Ga er niet van uit dat het wijzigen van de accountstatus automatisch berichten uit een gedistribueerde wachtrij verwijdert.
Ook het annuleren van een taak moet idempotent zijn. Een taak die na een netwerkstoring opnieuw wordt geprobeerd, mag geen melding of sluitingshandeling dupliceren. Gebruik gebeurtenis-ID's, idempotentiesleutels of passende uniciteitsbeperkingen en leg de resultaten vast om een veilige nieuwe poging van een nieuwe handeling te onderscheiden.
Het annuleren van de beëindiging en reactiveren veilig maken
Tijdens de respijtperiode moet het annuleren van de aanvraag een gedefinieerde overgang zijn, geen routine die zonder controle “alles ongedaan maakt”. De handeling moet controleren of de termijn nog niet is verstreken, de status precies één keer bijwerken en alleen de mogelijkheden herstellen die waren opgeschort en nog steeds geldig zijn.
Maak niet zonder onderscheid opnieuw abonnementen, webhooks, geplande taken, werkruimten of inloggegevens aan om duplicaten te voorkomen. Behoud stabiele ID's en registreer de status van elk neveneffect. Als een extern onderdeel al is beëindigd, moet de applicatie dit kunnen afstemmen: controleren of het nog bestaat, het gecontroleerd opnieuw aanmaken of melden dat handmatige actie nodig is.
Een idempotente reactivering levert dezelfde eindstatus op, ook als er meer dan één keer om wordt gevraagd. Dit kan worden ondersteund met transacties voor lokale wijzigingen, updatebewerkingen in plaats van onvoorwaardelijke inserts en een strategie voor nieuwe pogingen bij externe systemen. Als de handeling halverwege mislukt, leg dan vast welke stappen zijn voltooid en maak het mogelijk om verder te gaan zonder stappen te herhalen die al zijn geslaagd.
Gegevens, traceerbaarheid en definitieve sluiting afhandelen
Operationele sluiting en gegevensverwijdering zijn verschillende beslissingen. Bepaal wat er gebeurt met de gegevens van de organisatie, back-ups, auditlogs en informatie die vanwege wettelijke of contractuele verplichtingen wordt bewaard. De toepasselijke termijnen en redenen hangen af van de context en jurisdictie; ze moeten worden beoordeeld met de verantwoordelijken voor privacy en compliance. Communiceer volgens het toepasselijke beleid met de klant wat wordt verwijderd, wat wordt bewaard en hoelang.
Wanneer de respijtperiode afloopt, moet een gepland proces openstaande aanvragen vinden en de status en deadline opnieuw controleren voordat het account wordt gesloten. Bij een gedeeltelijke fout moet het systeem de mislukte stap registreren en hervatting mogelijk maken. Een closed-vlag bewijst op zichzelf niet dat inloggegevens zijn ingetrokken of integraties zijn stopgezet.
Houd een traceerbaarheidslog bij van aanvragen, annuleringen, wijzigingen in machtigingen, definitieve uitvoeringen en fouten. Beperk de toegang tot deze logs en neem geen geheimen of onnodige persoonsgegevens op. Waarschuwingen moeten situaties signaleren die langer duren dan verwacht, zoals verlopen organisaties die nog actief zijn of sluitingen die door herhaalde fouten worden geblokkeerd.
Checklist om de workflow te testen
- Iemand zonder de juiste machtigingen kan de beëindiging niet aanvragen of annuleren.
- De beëindiging twee keer aanvragen leidt niet tot dubbele datums, gebeurtenissen of sluitingen.
- Rollen hebben tijdens de respijtperiode precies de bedoelde mogelijkheden.
- Sessies, tokens, API's, wachtrijen en integraties houden rekening met de status van de organisatie.
- Annuleren vóór het verstrijken van de termijn herstelt de beoogde toegang zonder processen of resources te dupliceren.
- Een aanvraag waarvan de termijn is verstreken, wordt niet geannuleerd door een te laat verzoek en wordt niet twee keer afgesloten.
- Gedeeltelijke fouten en nieuwe pogingen maken het mogelijk de sluiting te voltooien zonder externe effecten te herhalen.
- De regels voor gegevensbewaring en -verwijdering worden afzonderlijk gecontroleerd van de operationele blokkering.
Test ook gelijktijdige wijzigingen, vertragingen in de wachtrij en fouten bij externe providers. Een teken van een consistent ontwerp is niet alleen dat het scherm “account gesloten” toont, maar ook dat machtigingen, processen, inloggegevens en gegevens dezelfde beslissing weerspiegelen en dat het systeem kan uitleggen hoe het die status heeft bereikt.
