Desativar uma organização numa plataforma SaaS não deve resumir-se a alterar um campo como active = false. Essa alteração pode ocultar a conta na interface enquanto os utilizadores mantêm sessões válidas, uma integração continua a enviar dados ou um trabalho em fila continua a modificar recursos. Para desativar de forma fiável uma conta de organização em SaaS PHP, é necessário definir o significado de cada estado e coordenar os efeitos sobre a identidade, os processos e os dados.
O objetivo é que a operação tenha um resultado verificável e que, se falhar a meio, possa prosseguir sem duplicar efeitos nem deixar permissões inconsistentes. Para isso, é necessário conceber tanto o ciclo de vida como os procedimentos de execução e recuperação.
Distinguir suspensão, encerramento e eliminação
Estes termos descrevem decisões distintas. A suspensão é geralmente temporária: bloqueia determinadas operações, mantendo a organização preservada para uma possível reativação. O encerramento assinala o fim da relação operacional e pode incluir a revogação de acessos e o cancelamento de tarefas. A eliminação afeta os dados e deve respeitar as regras de retenção, as obrigações legais e as políticas do produto.
Não é aconselhável usar um único indicador para representar as três situações. Um modelo explícito pode incluir estados como active, suspending, suspended, closing, closed e deletion_pending. Os nomes concretos dependem do produto; o importante é que cada estado tenha um significado, condições de entrada e operações permitidas.
- Suspensão: impedir novas ações de negócio, mas manter os dados e permitir as operações administrativas necessárias.
- Encerramento: interromper a atividade normal, invalidar acessos e concluir as tarefas de finalização.
- Eliminação: apagar ou anonimizar os dados de acordo com uma política definida, e não como efeito implícito da suspensão.
Modelar transições e permissões
Defina uma máquina de estados ou regras de transição equivalentes. Por exemplo, uma organização ativa pode passar para o estado de suspensão; um pedido de encerramento pode iniciar o estado closing; e só passa a closed após as verificações correspondentes. Se a transição não for permitida, a aplicação deve recusá-la com um motivo compreensível e registável.
As verificações de autorização devem avaliar o estado da organização no servidor, além dos papéis do utilizador. Ocultar botões na interface não revoga permissões. Numa aplicação PHP, centralize esta decisão em serviços de domínio, middleware ou políticas reutilizáveis, em vez de confiar em validações dispersas pelos controladores.
Especifique o que pode acontecer em cada fase. Durante closing, por exemplo, podem ser permitidas exportações e consultas de faturas, mas não a criação de utilizadores, o início de processos de negócio ou a alteração de integrações. Este contrato evita que diferentes componentes interpretem «desativada» de formas incompatíveis.
Revogar acessos, sessões e credenciais
O encerramento deve abranger todas as formas de acesso associadas à organização: sessões web, tokens de API, chaves de serviço, convites pendentes, credenciais OAuth e acessos delegados. Identifique onde são emitidos e como são invalidados. Um convite não aceite também pode conceder acesso no futuro, pelo que deve ser cancelado ou tornado inutilizável.
A revogação de uma sessão depende da forma como é gerida. Se o sistema usar sessões armazenadas no servidor, pode invalidá-las diretamente; se usar tokens autocontidos, pode ser necessário consultar o estado da organização em cada pedido, usar uma lista de revogação ou adotar uma estratégia de expiração curta. A opção adequada depende do nível de risco e dos requisitos de desempenho, mas o estado de encerramento deve prevalecer sobre um token ainda válido.
Considere também os utilizadores que pertencem a várias organizações. Desativar uma empresa não deve bloquear automaticamente a conta pessoal do utilizador nem o seu acesso legítimo a outros clientes. O controlo deve ser aplicado ao contexto da organização e às permissões efetivas de cada pedido.
Interromper filas, webhooks e integrações
Uma alteração de estado na base de dados não cancela, por si só, os trabalhos já colocados em fila. Reveja os consumidores de filas, as tarefas agendadas, os processos de importação e exportação, as sincronizações e as notificações. Antes de executar uma ação, cada processo deve verificar se a organização continua habilitada para essa operação. Quando for adequado, descarte ou cancele os trabalhos pendentes e registe aqueles que não foi possível interromper.
Para os webhooks de saída, defina se os eventos já gerados são entregues, cancelados ou conservados para auditoria. Para as integrações de entrada, desative as credenciais e recuse novos pedidos, mesmo que o fornecedor remoto ainda não tenha recebido a notificação de encerramento. Evite depender de que terceiros concluam a desconexão a tempo.
Em sistemas distribuídos, não assuma que estas ações e uma atualização da base de dados formam uma transação atómica. Use uma sequência controlada e, se for adequado, um padrão de outbox transacional para publicar eventos de alteração de estado. Faça com que os consumidores tolerem mensagens repetidas através de operações idempotentes.
Tornar o encerramento retomável e auditável
Represente o encerramento como uma operação com identificador, data de início, responsável, motivo quando aplicável, versão do fluxo e resultados por etapa. Algumas etapas possíveis são bloquear operações, revogar credenciais, cancelar tarefas, notificar integrações e concluir verificações. Registe estados como pendente, concluído ou falhado, juntamente com informações úteis para diagnóstico, evitando guardar segredos ou dados pessoais desnecessários.
Se uma etapa falhar, o sistema deve permitir repeti-la sem repetir efeitos prejudiciais. Por exemplo, revogar uma credencial já revogada deve ser uma operação segura. Distinga os erros transitórios, que podem ser objeto de novas tentativas, dos erros que exigem intervenção. Não assinale o encerramento como concluído apenas porque foi iniciada uma tarefa assíncrona.
Defina também o que significa reativar. É possível reverter uma suspensão restaurando as operações permitidas, mas a reativação de uma organização encerrada não deve recriar automaticamente credenciais eliminadas nem repor trabalhos cancelados. A política deve especificar o que é restaurado, o que exige uma ação administrativa e o que já não pode ser revertido.
Decidir o destino dos dados
Antes de eliminar dados, determine quais os registos que dependem exclusivamente da organização, quais devem ser conservados por motivos operacionais ou legais e quais fazem parte de informação partilhada. Esclareça como são tratados os documentos, os registos de auditoria, as faturas, as cópias de segurança e os dados armazenados por fornecedores externos. A eliminação da conta não implica necessariamente que todas as cópias desapareçam de imediato; explique as regras aplicáveis sem prometer prazos que o sistema não possa garantir.
Quando a eliminação for assíncrona, mantenha estados explícitos, como deletion_pending e deleted, e registe o resultado por categoria de dados. Se os dados forem anonimizados, confirme que o procedimento impede uma reidentificação razoável e não quebra referências que devam ser mantidas. A decisão deve estar de acordo com as obrigações e políticas aplicáveis ao produto.
Verificar e testar a operação completa
Deve ser possível comprovar que o encerramento foi concluído através de verificações, e não apenas de uma mensagem de sucesso. Confirme que a organização não permite operações bloqueadas, que as credenciais previstas já não funcionam, que os convites foram invalidados e que não continuam em execução trabalhos incompatíveis. Verifique também o estado das integrações e as exceções que exigem acompanhamento.
Inclua testes automatizados e operacionais para situações representativas:
- Pedidos repetidos de suspensão ou encerramento, que não devem duplicar efeitos.
- Falha após a revogação de acessos, mas antes da interrupção de uma integração.
- Nova tentativa após um erro de rede ou uma resposta falhada de um fornecedor.
- Reativação de uma organização suspensa e limites de uma conta encerrada.
- Utilizadores ativos em várias organizações e trabalhos em fila iniciados antes da alteração.
Uma lista de verificação observável, juntamente com métricas de operações pendentes e falhadas, ajuda a detetar encerramentos bloqueados. A decisão essencial é tratar o encerramento como um processo de negócio com estados, permissões e efeitos definidos. Assim, desativar uma conta de organização em SaaS PHP deixa de ser uma alteração isolada e passa a ser uma transição controlada, recuperável e coerente para todos os componentes.
