Come progettare la disattivazione di un account SaaS con periodo di grazia

La disattivazione di un account SaaS con periodo di grazia non è una singola operazione rinviata. È un flusso del ciclo di vita che deve coordinare accessi, fatturazione, attività automatiche, integrazioni e dati. Se l’applicazione salva solo una data di chiusura e la verifica al momento del login, altri processi potrebbero continuare a operare come se l’organizzazione fosse attiva.

La progettazione deve chiarire il significato di ogni fase, chi può eseguire una transizione e quali effetti sono reversibili. In questo modo, annullare la richiesta non equivale a ricostruire l’account da zero e il raggiungimento della data limite non dipende dal fatto che un utente effettui nuovamente l’accesso.

Separare richiesta, sospensione e chiusura definitiva

La richiesta esprime un’intenzione: una persona autorizzata chiede di chiudere l’account. La sospensione determina cosa può fare l’organizzazione mentre la richiesta viene gestita. La chiusura definitiva esegue le azioni finali, che possono includere la revoca delle credenziali, l’interruzione dei processi e l’applicazione della policy sui dati. Sono momenti distinti ed è opportuno modellarli separatamente.

Una decisione importante per il prodotto riguarda il momento in cui iniziano le restrizioni di accesso. Se l’accesso resta disponibile fino alla scadenza, occorre comunicarlo chiaramente e controllare l’utilizzo durante questo periodo. Se viene limitato immediatamente, il periodo di grazia serve a recuperare l’account, non a continuare a usare normalmente il servizio. Non esiste un’opzione valida per tutti: dipende dal modello commerciale, dai rischi e dagli obblighi del prodotto.

È inoltre necessario definire le conseguenze per la fatturazione e gli abbonamenti. La disattivazione dell’account non comporta necessariamente la cancellazione di un abbonamento esterno, così come una cancellazione del pagamento non dovrebbe eliminare un’organizzazione. Chiarisci qual è la fonte di verità per ogni decisione ed evita di dedurre lo stato operativo da un singolo evento del provider di pagamenti.

Definire stati e transizioni consentite

Un modello esplicito facilita l’applicazione delle stesse regole da parte dell’interfaccia, dell’API e dei processi in background. Un flusso semplice può usare stati come active, deletion_requested, suspended e closed. Se la sospensione avviene insieme alla richiesta, potrebbe bastare un unico stato di richiesta con attributi che ne descrivano le restrizioni. Evita di aggiungere stati che non corrispondono a una differenza operativa concreta.

Documenta le transizioni valide. Per esempio, un’organizzazione attiva può richiedere la disattivazione; una richiesta in corso può essere annullata; una richiesta il cui termine è scaduto può passare alla chiusura definitiva. In generale, un’organizzazione chiusa non dovrebbe essere riaperta con la stessa azione di annullamento: se è possibile recuperarla, serve una procedura distinta con limiti chiari.

• Registra chi ha avviato la richiesta, quando, da quale canale e quando scade il periodo.
• Verifica le autorizzazioni e lo stato attuale sul server, non solo nell’interfaccia.
• Rifiuta o gestisci esplicitamente le transizioni ripetute e le richieste simultanee.
• Salva le modifiche di stato in modo atomico e pubblica gli effetti collaterali tramite un pattern affidabile, come una transactional outbox.

In un’applicazione PHP, centralizza le regole di transizione in un servizio di dominio o in un livello equivalente. I controller non dovrebbero modificare direttamente più campi dando per scontato che tutti i consumer conoscano la nuova semantica. Il database deve conservare informazioni sufficienti affinché un processo in sospeso possa determinare l’azione da eseguire senza dipendere dallo stato di una precedente richiesta web.

Limitare gli accessi e contenere i processi in sospeso

Definisci le capacità consentite a ciascun ruolo durante il periodo di grazia. Un amministratore potrebbe essere autorizzato ad annullare la disattivazione e a consultare le informazioni necessarie per esportarle, mentre i membri dell’organizzazione potrebbero essere bloccati. Se è consentito l’accesso in sola lettura, specifica quali risorse comprende e se restano disponibili API, download e funzioni amministrative. Lo stesso controllo deve essere applicato nell’interfaccia, nelle API e nei processi automatizzati.

Bloccare il login non basta. Token di accesso, chiavi API, sessioni attive e credenziali delle integrazioni potrebbero continuare a funzionare. Decidi quali revocare, quali sospendere e quali conservare temporaneamente. Se le credenziali vengono revocate, registra l’effetto affinché la riattivazione non dipenda da segreti che non esistono più; potrebbe essere necessario richiederne la generazione.

Esamina code e attività pianificate: per esempio, invii, sincronizzazioni, report, webhook e processi di fatturazione. Ogni processo deve verificare lo stato aggiornato dell’organizzazione subito prima di eseguire un’operazione con effetti esterni. I processi già accodati possono essere annullati, sospesi o portati a termine secondo una policy esplicita. Non dare per scontato che modificare lo stato dell’account rimuova automaticamente i messaggi da una coda distribuita.

Anche l’annullamento di un’attività deve essere idempotente. Un processo ritentato dopo un errore di rete non dovrebbe duplicare una notifica o un’operazione di chiusura. Usa identificativi di evento, chiavi di idempotenza o vincoli di unicità adeguati e registra i risultati per distinguere un retry sicuro da una nuova azione.

Rendere sicuri l’annullamento della disattivazione e la riattivazione

Durante il periodo di grazia, annullare la richiesta dovrebbe essere una transizione definita, non una routine che “annulla tutto” senza verificare cosa è successo. L’operazione deve verificare che il termine non sia scaduto, aggiornare lo stato una sola volta e ripristinare solo le capacità che erano state sospese e che sono ancora valide.

Per evitare duplicati, non ricreare indiscriminatamente abbonamenti, webhook, attività pianificate, spazi di lavoro o credenziali. Mantieni identificativi stabili e registra lo stato di ogni effetto collaterale. Se un componente esterno è già stato disattivato, l’applicazione deve poterlo riconciliare: verificare se esiste ancora, ricrearlo in modo controllato oppure segnalare che è necessario un intervento manuale.

Una riattivazione idempotente produce lo stesso stato finale anche se viene richiesta più di una volta. Questo risultato può essere supportato da transazioni per le modifiche locali, operazioni di aggiornamento invece di inserimenti alla cieca e una strategia di retry per i sistemi esterni. Se l’operazione fallisce a metà, registra i passaggi completati e consenti di riprenderla senza ripetere quelli già riusciti.

Gestire dati, tracciabilità e chiusura definitiva

La chiusura operativa e l’eliminazione dei dati sono decisioni distinte. Definisci cosa succede ai dati dell’organizzazione, ai backup, ai log di audit e alle informazioni conservate per obblighi legali o contrattuali. I termini e le motivazioni applicabili dipendono dal contesto e dalla giurisdizione; vanno esaminati con i responsabili della privacy e della compliance. Comunica al cliente cosa viene eliminato, cosa viene conservato e per quanto tempo, in base alla policy applicabile.

Alla scadenza del periodo di grazia, un processo pianificato deve individuare le richieste in sospeso e verificare nuovamente lo stato e la data limite prima di chiudere l’account. In caso di errore parziale, il sistema deve registrare il passaggio non riuscito e consentire di riprendere il processo. Un flag closed non dimostra, da solo, che le credenziali siano state revocate o le integrazioni interrotte.

Conserva la tracciabilità delle richieste, degli annullamenti, delle modifiche alle autorizzazioni, delle esecuzioni finali e degli errori. Limita l’accesso a questi log ed evita di includervi segreti o dati personali non necessari. Gli alert dovrebbero segnalare i casi che superano i tempi previsti, per esempio le organizzazioni scadute ancora attive o le chiusure bloccate da errori ripetuti.

Checklist per testare il flusso

• Una persona senza le autorizzazioni necessarie non può richiedere né annullare la disattivazione.
• Richiedere la disattivazione due volte non genera date, eventi o chiusure duplicati.
• I ruoli dispongono esattamente delle capacità previste durante il periodo di grazia.
• Sessioni, token, API, code e integrazioni rispettano lo stato dell’organizzazione.
• Annullare prima della scadenza ripristina l’accesso previsto senza duplicare processi o risorse.
• Una richiesta scaduta non viene annullata da una richiesta tardiva né chiusa due volte.
• Errori parziali e retry consentono di completare la chiusura senza ripetere gli effetti esterni.
• Le regole di conservazione ed eliminazione dei dati vengono verificate separatamente dal blocco operativo.

Testa anche le modifiche simultanee, i ritardi delle code e gli errori dei provider esterni. La prova della coerenza della progettazione non è soltanto la dicitura “account chiuso” visualizzata sullo schermo: autorizzazioni, processi, credenziali e dati devono riflettere la stessa decisione e il sistema deve poter spiegare come è arrivato a quello stato.