Rezygnacja z konta SaaS z okresem karencji nie jest pojedynczą operacją odroczoną w czasie. To przepływ obejmujący cały cykl życia, który musi koordynować dostęp, rozliczenia, zadania automatyczne, integracje i dane. Jeśli aplikacja jedynie zapisuje datę zamknięcia i sprawdza ją podczas logowania, inne procesy mogą nadal działać tak, jakby organizacja była aktywna.
Projekt powinien jasno określać znaczenie każdego etapu, kto może wykonać daną zmianę stanu i które skutki można odwrócić. Dzięki temu anulowanie zgłoszenia nie oznacza odbudowy konta od zera, a nadejście terminu granicznego nie zależy od tego, czy użytkownik ponownie się zaloguje.
Rozdziel zgłoszenie rezygnacji, zawieszenie i ostateczne zamknięcie
Zgłoszenie wyraża zamiar: upoważniona osoba prosi o zamknięcie konta. Zawieszenie określa, co organizacja może robić w trakcie rozpatrywania zgłoszenia. Ostateczne zamknięcie obejmuje wykonanie końcowych działań, które mogą polegać na unieważnieniu danych uwierzytelniających, zatrzymaniu procesów i zastosowaniu zasad dotyczących danych. To różne momenty, które warto modelować oddzielnie.
Ważną decyzją produktową jest określenie, kiedy zaczynają obowiązywać ograniczenia dostępu. Jeśli dostęp pozostaje aktywny do upływu terminu, należy jasno o tym poinformować i kontrolować korzystanie z usługi w tym czasie. Jeśli dostęp zostaje ograniczony od razu, okres karencji służy odzyskaniu konta, a nie dalszemu normalnemu korzystaniu z usługi. Nie ma jednego rozwiązania odpowiedniego dla wszystkich — zależy ono od modelu biznesowego, ryzyka i zobowiązań produktu.
Należy również określić konsekwencje dla rozliczeń i subskrypcji. Rezygnacja z konta nie musi automatycznie anulować zewnętrznej subskrypcji, podobnie jak anulowanie płatności nie powinno usuwać organizacji. Określ źródło prawdy dla każdej decyzji i nie wyciągaj wniosków o stanie operacyjnym na podstawie pojedynczego zdarzenia od dostawcy płatności.
Określ stany i dozwolone przejścia
Jawny model ułatwia stosowanie tych samych reguł przez interfejs, API i zadania działające w tle. Prosty przepływ może wykorzystywać stany takie jak active, deletion_requested, suspended i closed. Jeśli zawieszenie następuje równocześnie ze zgłoszeniem, może wystarczyć jeden stan zgłoszenia oraz atrybuty opisujące związane z nim ograniczenia. Unikaj dodawania stanów, które nie odzwierciedlają rzeczywistej różnicy operacyjnej.
Udokumentuj dozwolone przejścia. Na przykład aktywna organizacja może zgłosić rezygnację, aktualne zgłoszenie można anulować, a zgłoszenie, którego termin upłynął, może przejść do ostatecznego zamknięcia. Co do zasady zamkniętej organizacji nie należy ponownie otwierać za pomocą tej samej operacji anulowania. Jeśli oferujesz jej odzyskanie, wymaga ono odrębnej procedury i jasno określonych ograniczeń.
- Zapisuj, kto zgłosił rezygnację, kiedy i za pośrednictwem jakiego kanału, a także kiedy upływa okres karencji.
- Sprawdzaj uprawnienia i bieżący stan po stronie serwera, a nie tylko w interfejsie.
- Odrzucaj powtarzające się przejścia i równoczesne zgłoszenia albo obsługuj je w jawnie określony sposób.
- Zapisuj zmiany stanu atomowo, a skutki uboczne publikuj za pomocą niezawodnego wzorca, takiego jak transakcyjna skrzynka nadawcza.
W aplikacji PHP centralizuj reguły przejść w serwisie domenowym lub równoważnej warstwie. Kontrolery nie powinny bezpośrednio zmieniać kilku pól i zakładać, że wszyscy odbiorcy zrozumieją nową semantykę. Baza danych musi przechowywać wystarczająco dużo informacji, aby oczekujący proces mógł ustalić właściwe działanie bez polegania na stanie wcześniejszego żądania HTTP.
Ogranicz dostęp i kontroluj oczekujące procesy
Określ uprawnienia poszczególnych ról na czas karencji. Administrator może mieć prawo do anulowania rezygnacji i dostępu do informacji potrzebnych do ich eksportu, podczas gdy członkowie organizacji mogą zostać zablokowani. Jeśli dopuszczasz dostęp tylko do odczytu, sprecyzuj, jakich zasobów dotyczy i czy nadal dostępne są API, pobieranie danych oraz funkcje administracyjne. Te same kontrole muszą obowiązywać w interfejsie, API i zadaniach automatycznych.
Samo blokowanie logowania nie wystarczy. Tokeny dostępu, klucze API, aktywne sesje i dane uwierzytelniające integracji mogą nadal działać. Zdecyduj, które z nich unieważnić, które wstrzymać, a które zachować tymczasowo. Jeśli unieważniasz dane uwierzytelniające, zapisz tę zmianę, aby reaktywacja nie zależała od sekretów, które już nie istnieją; może być konieczne wymaganie ich ponownego wygenerowania.
Sprawdź kolejki i zaplanowane zadania, na przykład wysyłki, synchronizacje, raporty, webhooki i zadania rozliczeniowe. Każdy proces powinien tuż przed wykonaniem operacji wywołującej skutki zewnętrzne sprawdzić aktualny stan organizacji. Zadania już umieszczone w kolejce można anulować, wstrzymać lub dopuścić do zakończenia zgodnie z jawną polityką. Nie zakładaj, że zmiana stanu konta automatycznie usuwa wiadomości z kolejki rozproszonej.
Anulowanie zadania również wymaga idempotencji. Ponowienie zadania po błędzie sieci nie powinno powodować wysłania zduplikowanego powiadomienia ani ponownego wykonania operacji zamknięcia. Używaj identyfikatorów zdarzeń, kluczy idempotencji lub odpowiednich ograniczeń unikalności, a także rejestruj wyniki, by odróżniać bezpieczne ponowienie od nowej operacji.
Zadbaj o bezpieczne anulowanie rezygnacji i reaktywację
W okresie karencji anulowanie zgłoszenia powinno być zdefiniowaną zmianą stanu, a nie procedurą, która „cofa wszystko” bez sprawdzenia, co już się wydarzyło. Operacja musi zweryfikować, czy termin jeszcze nie upłynął, jednokrotnie zaktualizować stan i przywrócić wyłącznie te uprawnienia, które zostały zawieszone i nadal są aktualne.
Aby uniknąć duplikatów, nie twórz ponownie bezwarunkowo subskrypcji, webhooków, zaplanowanych zadań, obszarów roboczych ani danych uwierzytelniających. Zachowuj stabilne identyfikatory i zapisuj stan każdego skutku ubocznego. Jeśli zewnętrzny komponent został już wyłączony, aplikacja musi umieć uzgodnić jego stan: potwierdzić, czy nadal istnieje, odtworzyć go w kontrolowany sposób albo poinformować, że wymaga ręcznej interwencji.
Idempotentna reaktywacja prowadzi do tego samego stanu końcowego, nawet jeśli zostanie zlecona więcej niż raz. Można ją zapewnić przez transakcje dla zmian lokalnych, operacje aktualizacji zamiast bezwarunkowych wstawień oraz strategię ponawiania dla systemów zewnętrznych. Jeśli operacja zakończy się niepowodzeniem w połowie, zapisuj ukończone kroki i umożliwiaj wznowienie bez powtarzania tych, które już się powiodły.
Uwzględnij dane, ścieżkę audytową i ostateczne zamknięcie
Zamknięcie operacyjne i usunięcie danych to odrębne decyzje. Określ, co stanie się z danymi organizacji, kopiami zapasowymi, dziennikami audytu oraz informacjami przechowywanymi ze względu na wymogi prawne lub umowne. Obowiązujące terminy i przyczyny zależą od kontekstu i jurysdykcji; należy je uzgodnić z osobami odpowiedzialnymi za prywatność i zgodność z przepisami. Zgodnie z obowiązującą polityką poinformuj klienta, co zostanie usunięte, co będzie przechowywane i jak długo.
Po upływie okresu karencji zaplanowany proces powinien wyszukać oczekujące zgłoszenia i ponownie sprawdzić ich stan oraz termin graniczny przed zamknięciem konta. W przypadku częściowego niepowodzenia system musi zapisać, który krok się nie powiódł, i umożliwić wznowienie procesu. Flaga closed sama w sobie nie dowodzi, że unieważniono dane uwierzytelniające lub zatrzymano integracje.
Prowadź ścieżkę audytową zgłoszeń, anulowań, zmian uprawnień, końcowych operacji i błędów. Ogranicz dostęp do tych zapisów i nie umieszczaj w nich sekretów ani zbędnych danych osobowych. Alerty powinny wskazywać przypadki przekroczenia oczekiwanego czasu, takie jak organizacje po terminie, które nadal są aktywne, lub zamknięcia blokowane przez powtarzające się błędy.
Lista kontrolna do testowania przepływu
- Osoba bez odpowiednich uprawnień nie może zgłosić ani anulować rezygnacji.
- Dwukrotne zgłoszenie rezygnacji nie tworzy zduplikowanych terminów, zdarzeń ani zamknięć.
- Role mają w okresie karencji dokładnie takie uprawnienia, jakie przewidziano.
- Sesje, tokeny, API, kolejki i integracje respektują stan organizacji.
- Anulowanie przed upływem terminu przywraca przewidziany dostęp bez duplikowania procesów ani zasobów.
- Spóźnione żądanie nie anuluje zgłoszenia po upływie terminu, a zamknięcie nie jest wykonywane dwukrotnie.
- Częściowe błędy i ponowienia umożliwiają dokończenie zamknięcia bez powtarzania zewnętrznych skutków.
- Zasady przechowywania i usuwania danych są weryfikowane niezależnie od blokady operacyjnej.
Testuj również równoczesne zmiany, opóźnienia w kolejce i błędy zewnętrznych dostawców. O spójności projektu świadczy nie tylko wyświetlenie komunikatu „konto zamknięte”, lecz także zgodność uprawnień, procesów, danych uwierzytelniających i danych z tą samą decyzją oraz możliwość wyjaśnienia, jak system osiągnął dany stan.
