Een organisatie op een SaaS-platform uitschakelen zou niet moeten neerkomen op het wijzigen van een veld zoals active = false. Die wijziging kan het account in de interface verbergen terwijl gebruikers geldige sessies behouden, een integratie gegevens blijft versturen of een taak in de queue resources blijft wijzigen. Om een organisatieaccount in SaaS PHP betrouwbaar uit te schakelen, moet duidelijk zijn wat elke status betekent en moeten de gevolgen voor identiteit, processen en gegevens op elkaar worden afgestemd.
Het doel is dat de operatie een controleerbaar resultaat oplevert en, als deze halverwege mislukt, kan worden voortgezet zonder effecten te dupliceren of inconsistente rechten achter te laten. Dat vereist een ontwerp voor zowel de levenscyclus als de uitvoerings- en herstelprocedures.
Opschorting, sluiting en verwijdering onderscheiden
Deze termen beschrijven verschillende beslissingen. Een opschorting is doorgaans tijdelijk: bepaalde handelingen worden geblokkeerd, terwijl de organisatie behouden blijft voor een mogelijke heractivering. Een sluiting markeert het einde van de operationele relatie en kan het intrekken van toegangsrechten en het annuleren van taken omvatten. Een verwijdering heeft gevolgen voor de gegevens en moet voldoen aan bewaartermijnen, wettelijke verplichtingen en productbeleid.
Gebruik bij voorkeur niet één indicator om alle drie de situaties weer te geven. Een expliciet model kan statussen bevatten zoals active, suspending, suspended, closing, closed en deletion_pending. De precieze namen hangen af van het product; belangrijk is dat elke status een betekenis, voorwaarden voor de overgang naar die status en toegestane handelingen heeft.
- Opschorting: nieuwe zakelijke handelingen blokkeren, maar gegevens behouden en de benodigde administratieve handelingen toestaan.
- Sluiting: de reguliere activiteit stopzetten, toegangsrechten ongeldig maken en afrondende taken voltooien.
- Verwijdering: gegevens verwijderen of anonimiseren volgens een vastgelegd beleid, niet als impliciet gevolg van een opschorting.
Statusovergangen en rechten modelleren
Definieer een toestandsmachine of gelijkwaardige overgangsregels. Een actieve organisatie kan bijvoorbeeld worden opgeschort; een sluitingsverzoek kan de status closing in gang zetten; en pas na de bijbehorende controles wordt de status closed bereikt. Als een overgang niet is toegestaan, moet de applicatie deze afwijzen met een begrijpelijke reden die kan worden geregistreerd.
Autorisatiecontroles moeten de status van de organisatie op de server beoordelen, naast de rollen van de gebruiker. Knoppen in de interface verbergen trekt geen rechten in. Centraliseer deze beslissing in een PHP-applicatie in domeinservices, middleware of herbruikbare policies, in plaats van te vertrouwen op verspreide controles in controllers.
Leg vast wat er tijdens elke fase mag gebeuren. Tijdens closing zijn exports en het raadplegen van facturen bijvoorbeeld mogelijk toegestaan, maar niet het aanmaken van gebruikers, starten van bedrijfsprocessen of wijzigen van integraties. Dit contract voorkomt dat verschillende componenten “uitgeschakeld” op onverenigbare manieren interpreteren.
Toegangsrechten, sessies en credentials intrekken
De sluiting moet alle toegangsmethoden omvatten die bij de organisatie horen: websessies, API-tokens, serviceaccountsleutels, openstaande uitnodigingen, OAuth-credentials en gedelegeerde toegang. Breng in kaart waar deze worden uitgegeven en hoe ze ongeldig worden gemaakt. Ook een nog niet geaccepteerde uitnodiging kan in de toekomst toegang verlenen en moet daarom worden ingetrokken of onbruikbaar worden gemaakt.
Hoe een sessie wordt ingetrokken, hangt af van de manier waarop deze wordt beheerd. Als het systeem sessies op de server opslaat, kunnen ze rechtstreeks ongeldig worden gemaakt. Bij self-contained tokens kan het nodig zijn om bij elk verzoek de status van de organisatie te controleren, een intrekkingslijst te gebruiken of een strategie met korte vervaltijden toe te passen. De juiste keuze hangt af van het risiconiveau en de prestatievereisten, maar de sluitingsstatus moet zwaarder wegen dan een token dat nog niet is verlopen.
Houd ook rekening met gebruikers die bij meerdere organisaties horen. Het uitschakelen van één bedrijf mag niet automatisch hun persoonlijke account of legitieme toegang tot andere klanten blokkeren. De controle moet worden toegepast op de organisatiecontext en de effectieve rechten van elk verzoek.
Queues, webhooks en integraties stopzetten
Een statuswijziging in de database annuleert op zichzelf geen taken die al in een queue staan. Controleer queue-consumers, geplande taken, import- en exportprocessen, synchronisaties en meldingen. Voordat een handeling wordt uitgevoerd, moet elke worker controleren of de organisatie die handeling nog mag uitvoeren. Annuleer of verwijder waar passend openstaande taken en registreer welke niet konden worden stopgezet.
Bepaal voor uitgaande webhooks of reeds gegenereerde events worden afgeleverd, geannuleerd of voor auditing bewaard. Schakel voor inkomende integraties credentials uit en wijs nieuwe verzoeken af, ook als de externe provider nog geen sluitingsmelding heeft ontvangen. Vertrouw er niet op dat een derde partij de verbinding op tijd verbreekt.
Ga er in gedistribueerde systemen niet van uit dat deze handelingen en een database-update samen één atomaire transactie vormen. Gebruik een gecontroleerde volgorde en, waar passend, het transactional outbox-pattern om statuswijzigingsevents te publiceren. Zorg ervoor dat consumers dubbele berichten aankunnen met idempotente handelingen.
De uitschakeling hervatbaar en controleerbaar maken
Modelleer de uitschakeling als een operatie met een operatie-ID, startdatum, uitvoerende actor, eventuele reden, versie van de workflow en resultaten per fase. Mogelijke fasen zijn het blokkeren van handelingen, intrekken van credentials, annuleren van taken, informeren van integraties en uitvoeren van controles. Registreer statussen zoals in afwachting, voltooid of mislukt, met nuttige diagnostische informatie, maar sla geen geheimen of onnodige persoonsgegevens op.
Als een fase mislukt, moet het systeem de mogelijkheid bieden deze opnieuw uit te voeren zonder schadelijke effecten te herhalen. Zo moet het intrekken van een al ingetrokken credential een veilige handeling zijn. Maak onderscheid tussen tijdelijke fouten, die opnieuw kunnen worden geprobeerd, en fouten waarvoor interventie nodig is. Markeer de sluiting niet als voltooid alleen omdat een asynchrone taak is gestart.
Bepaal ook wat heractivering inhoudt. Een opschorting kan ongedaan worden gemaakt door toegestane handelingen te herstellen, maar bij het heractiveren van een gesloten organisatie mogen verwijderde credentials niet automatisch opnieuw worden aangemaakt en geannuleerde taken niet opnieuw worden ingepland. Het beleid moet vastleggen wat wordt hersteld, waarvoor een administratieve handeling nodig is en wat niet meer kan worden teruggedraaid.
Bepalen wat er met de gegevens gebeurt
Bepaal voordat gegevens worden verwijderd welke records uitsluitend van de organisatie afhankelijk zijn, welke om operationele of wettelijke redenen moeten worden bewaard en welke deel uitmaken van gedeelde informatie. Leg vast hoe documenten, auditlogs, facturen, back-ups en gegevens bij externe providers worden behandeld. Het verwijderen van een account betekent niet noodzakelijk dat alle kopieën onmiddellijk verdwijnen; licht de toepasselijke regels toe zonder termijnen te beloven die het systeem niet kan garanderen.
Houd bij asynchrone verwijdering expliciete statussen aan, zoals deletion_pending en deleted, en registreer het resultaat per gegevenscategorie. Controleer bij anonimisering of de procedure redelijke heridentificatie voorkomt en geen verwijzingen verbreekt die behouden moeten blijven. De beslissing moet aansluiten op de verplichtingen en het beleid die voor het product gelden.
De volledige operatie controleren en testen
Een afgeronde uitschakeling moet met controles kunnen worden aangetoond, niet alleen met een succesmelding. Controleer of de organisatie geen geblokkeerde handelingen meer accepteert, de beoogde credentials niet meer werken, uitnodigingen ongeldig zijn gemaakt en er geen onverenigbare taken meer actief zijn. Controleer ook de status van integraties en de uitzonderingen die opvolging vereisen.
Neem geautomatiseerde en operationele tests op voor representatieve situaties:
- Herhaalde verzoeken om opschorting of sluiting, die geen effecten mogen dupliceren.
- Een fout nadat toegangsrechten zijn ingetrokken, maar voordat een integratie is stopgezet.
- Een nieuwe poging na een netwerkfout of een mislukte reactie van een provider.
- Heractivering van een opgeschorte organisatie en de beperkingen van een gesloten account.
- Gebruikers die actief zijn bij meerdere organisaties en taken in een queue die vóór de wijziging zijn gestart.
Een controlelijst waarvan de status zichtbaar is, samen met metrieken voor openstaande en mislukte operaties, helpt vastgelopen sluitingen op te sporen. De kern is om de uitschakeling te behandelen als een bedrijfsproces met gedefinieerde statussen, rechten en effecten. Zo wordt het uitschakelen van een organisatieaccount in SaaS PHP geen geïsoleerde wijziging, maar een gecontroleerde, hervatbare en consistente overgang voor alle componenten.
