Muitos processos internos começam com peças conhecidas: um formulário web, uma caixa compartilhada, uma planilha e algumas notificações. O problema aparece quando uma solicitação é enviada duas vezes, um e-mail não chega ou ninguém consegue explicar por que o responsável mudou.
A resposta não é adicionar mais alertas. É separar captura, estado, regras e execução para que cada parte tenha uma responsabilidade verificável.
1) O e-mail é um canal, não o estado do processo
O e-mail funciona para comunicação humana, mas é uma base frágil para decidir o que está pendente. Encaminhamentos, respostas fora da conversa e caixas pessoais dificultam identificar a versão vigente.
Uma aplicação interna deve registrar a solicitação com identificador, estado permitido, responsável e histórico. O e-mail pode confirmar, alertar ou pedir informações; não deve ser a única evidência.
2) Uma arquitetura com responsabilidades claras
| Camada | Responsabilidade | Não deveria resolver |
|---|---|---|
| Formulário ou e-mail | Capturar dados e contexto inicial | Regras completas ou estado final |
| API / backend | Validar, autenticar e aplicar regras | Depender de tarefas manuais ocultas |
| PostgreSQL | Guardar estado, relações e histórico | Enviar notificações diretamente |
| Workflow | Executar tarefas assíncronas e integrações | Virar a fonte da verdade |
| App interna | Mostrar pendências, decisões e evidências | Duplicar lógica diferente em cada tela |
O n8n pode ser uma boa camada de orquestração para avisos e sincronizações. A integridade do caso, porém, pertence ao backend e ao banco de dados.
3) Desenhar para duplicidades desde o início
Duplicidades não são uma exceção: surgem por clique duplo, retentativas do navegador, webhooks repetidos ou usuários que reenviam o mesmo e-mail. Cada entrada precisa de uma chave de idempotência ou regra explícita de deduplicação.
4) Modelar estados, não cadeias de notificações
Estados como recebido, em validação, requer informação, aprovado e encerrado precisam de transições permitidas. Cada mudança registra ator, data, motivo e versão anterior.
Assim, uma notificação é consequência de uma transição confirmada. Se o e-mail falhar, o caso preserva o estado e o envio pode ser repetido sem refazer a decisão de negócio.
5) Retentativas que não escondem falhas
Um workflow sustentável distingue erros temporários e permanentes. Um timeout pode ser repetido com espera progressiva; um endereço inválido requer correção humana. Depois do limite, o evento deve ficar visível em uma fila de falhas com contexto suficiente.
- Identificadores do caso e do evento.
- Tentativas, datas e resposta técnica resumida.
- Impacto operacional: qual ação ficou pendente.
- Opção segura para reprocessar ou descartar com motivo.
6) A fila operacional que substitui a busca manual
Uma tela útil não mostra apenas registros. Deve filtrar por estado, responsável, idade, prioridade e exceção; abrir o histórico; e oferecer somente as ações permitidas para o papel do usuário.
Next.js, TypeScript, Node.js, Prisma e PostgreSQL podem manter contratos de dados consistentes da interface à persistência, sem supor que a tecnologia substitui o desenho do processo.
7) Observabilidade para operação e suporte
Logs técnicos ajudam no diagnóstico, mas operações precisa de outras respostas: quantos casos aguardam ação, onde envelhecem, qual integração falha e quem pode resolver. Um correlation ID deve conectar solicitação, evento, workflow e chamadas de APIs.
8) Um primeiro escopo que pode ser governado
- Escolher um processo com volume e exceções visíveis.
- Definir dados mínimos, estados, papéis e regras de transição.
- Criar API e registro central com idempotência.
- Conectar um canal de entrada e uma ação de saída.
- Adicionar retentativas, fila de falhas e histórico.
- Medir tempos, pendências e causas de exceção antes de ampliar.
O objetivo não é automatizar tudo. É construir um caminho completo e observável que possa crescer sem perder controle.
9) A decisão arquitetural de fundo
Integrar formulários, e-mail e workflows não significa desenhar mais setas entre ferramentas. Significa decidir onde vive a verdade, como uma transição é protegida e qual evidência uma pessoa precisa para intervir.
Quando essas decisões são explícitas, a automação acelera uma operação compreensível. Quando não são, apenas distribui a ambiguidade entre mais sistemas.