Como evitar registos duplicados numa automação
Para evitar registos duplicados numa automação, define uma identidade estável para cada objeto e evento, controla o estado do processamento e verifica o efeito no destino. Distingue repetições de atualizações legítimas. Testa também falhas e execuções simultâneas, porque procurar um registo antes de o criar pode não ser suficiente.
Uma automação recebe uma reunião, extrai tarefas e guarda-as num gestor de trabalho. Na primeira execução, tudo parece certo. Depois o mesmo evento chega outra vez, alguém repete um teste ou o fluxo tenta recuperar de uma falha. A lista passa a ter duas tarefas que representam exatamente o mesmo compromisso.
O problema pode começar na entrada, na transformação ou na escrita final. Por isso, acrescentar um filtro no meio do desenho não resolve necessariamente o percurso completo. Precisas de saber o que consideras repetido, durante quanto tempo o reconheces e como confirmas que a ação já aconteceu.
Vamos usar um exemplo fictício com duas tarefas de uma reunião. O objetivo é explicar o desenho e os casos de teste, sem executar integrações reais. A lógica pode ajudar-te a conversar com a IA sobre um workflow, mas a configuração final depende do contrato das ferramentas e do destino.
Define o que conta como duplicado no teu processo
Começa por distinguir o objeto de negócio, o evento recebido e a ação que pretendes executar. Dois eventos podem referir-se ao mesmo objeto sem serem duplicados. Duas tarefas com texto semelhante podem representar compromissos diferentes. A regra deve preservar trabalho legítimo e impedir apenas a repetição indevida do mesmo efeito.
No exercício, a reunião M01 contém as tarefas T01 e T02. O evento E01 comunica a primeira versão da lista. Se E01 for entregue novamente com o mesmo conteúdo, não queremos criar outras duas tarefas. Se surgir uma correção autorizada a T01, queremos avaliar uma atualização dessa tarefa, não descartá-la só porque já existe.
Uma pessoa pode ter vários pedidos, negócios ou marcações. Por isso, usar apenas o email como identidade de tudo mistura objetos diferentes. O mesmo cuidado aplica-se ao título de uma tarefa: “enviar proposta” pode aparecer em duas reuniões e corresponder a destinatários ou compromissos distintos.
Regista a regra numa frase: “Cada tarefa confirmada da reunião tem um identificador estável e corresponde a um registo no destino.” Depois define como reconhecer uma nova versão e que campos podem ser atualizados. Esta segunda decisão evita que a proteção contra duplicados bloqueie correções necessárias.
Se ainda estás a desenhar o percurso, começa pelo guia para desenhar uma automação antes de abrir o n8n. A identidade deve acompanhar o processo desde a entrada, em vez de ser acrescentada no fim quando já perdeste a relação entre os dados.
Escolhe identificadores estáveis e valida os campos
Usa identificadores que permaneçam associados ao mesmo objeto quando o evento é repetido ou a lista muda de posição. Confirma também a origem e o âmbito desses identificadores. Se um campo obrigatório estiver ausente ou ambíguo, encaminha o caso para revisão, sem inventar uma identidade que pareça válida.
No exemplo, a identidade da tarefa pode combinar conta, reunião e tarefa. Os três componentes importam quando diferentes contas podem usar os mesmos identificadores locais. Uma combinação deve ser construída de forma inequívoca, com campos separados ou uma representação controlada, para evitar colisões acidentais.
A posição na lista é uma escolha frágil. Se a tarefa T02 passa da segunda para a primeira posição, continua a ser T02. Da mesma forma, uma pequena correção de redação não deve criar automaticamente um objeto novo. Preserva a correspondência que foi estabelecida quando a tarefa foi confirmada.
Se as tarefas são extraídas por IA e não trazem IDs estáveis, define uma etapa de reconciliação antes da escrita. Guarda o conjunto aprovado e associa as tarefas seguintes a esse conjunto com revisão dos casos ambíguos. Não assumes que gerar novamente a lista produz os mesmos IDs ou a mesma ordem.
O guia para separar listas em tarefas com o Split Out do n8n explica a passagem de uma lista para itens individuais. Ao aplicar essa transformação, mantém os campos de conta, reunião e origem necessários para reconhecer cada tarefa mais tarde.
Separa duplicados no lote de repetições entre execuções
Verifica se o problema acontece dentro da entrada atual ou entre várias execuções ao longo do tempo. Uma lista pode conter duas cópias do mesmo item, enquanto um webhook pode entregar novamente um evento já recebido. Estas situações exigem comparação em âmbitos diferentes e devem ser testadas separadamente no teu workflow.
O nó Remove Duplicates do n8n distingue a remoção de itens repetidos na entrada atual da comparação com execuções anteriores. Na comparação atual, podes escolher os campos relevantes. No modo entre execuções, configura a identidade, o âmbito do histórico e a sua capacidade conforme a operação utilizada.
O histórico tem limites e pode ser limpo. Por isso, não o trates como memória eterna nem como prova de que uma ação no destino foi concluída. Filtrar um item que já passou pelo nó e confirmar que a tarefa existe corretamente no gestor são verificações diferentes.
No exercício, uma primeira lista com T01, T01 e T02 deve produzir duas identidades de tarefa. Uma segunda entrega do mesmo evento deve reconhecer que a operação já foi tratada ou está em recuperação. O comportamento esperado precisa de incluir o estado, não apenas a presença de um valor no histórico.
Confirma também que a filtragem não elimina campos necessários à escrita. Podes comparar apenas IDs e continuar a precisar do assunto, do prazo e do estado. Inspeciona a saída da etapa com uma amostra pequena antes de ligar ações que criem registos reais.
Controla a escrita quando duas execuções chegam juntas
Não dependas apenas de uma pesquisa seguida de criação quando podem existir execuções simultâneas. Duas execuções podem consultar o destino antes de qualquer uma ter escrito e ambas concluir que o registo não existe. O mecanismo de escrita precisa de impor a unicidade ou coordenar essa decisão de forma adequada.
Imagina que as execuções A e B recebem T01 quase ao mesmo tempo. A pesquisa e não encontra a tarefa. B pesquisa e também não encontra. Se ambas avançam para “criar”, a verificação inicial foi verdadeira nas duas situações e o resultado pode continuar duplicado.
Quando controlas a base de dados, uma restrição de unicidade e uma operação de escrita apropriada podem fazer parte da solução. A documentação de INSERT do PostgreSQL descreve o tratamento de conflitos e o comportamento atómico de ON CONFLICT DO UPDATE, dentro das condições documentadas. Isto protege a operação na base, não todas as ações externas do workflow.
Se usas um CRM ou gestor de tarefas, confirma se a API oferece uma operação equivalente, uma chave externa única ou outro mecanismo documentado. O nome “upsert” num conector não dispensa verificar o que acontece sob concorrência e quais são os campos usados para encontrar o registo.
Pede à IA que explique onde a unicidade é realmente imposta. Uma resposta que aponta apenas para um nó de pesquisa deixa a pergunta por resolver. Se a ferramenta não oferece a garantia necessária, ajusta o desenho, controla a concorrência por um mecanismo adequado ou mantém os casos incertos para reconciliação.
Guarda estados que permitam recuperar de uma falha
Distingue evento recebido, processamento em curso, efeito confirmado e resultado incerto. Guardar apenas uma marca de visto pode bloquear trabalho que ainda não terminou. O registo deve permitir perceber o que aconteceu e qual é a próxima ação segura, incluindo quando uma execução parou entre a escrita e a confirmação.
No exercício, a automação pede ao gestor para criar T01, mas perde a ligação antes de receber a resposta. Não sabes ainda se a tarefa foi criada. Repetir imediatamente a criação pode duplicar o registo; marcar como concluído pode esconder uma tarefa que nunca chegou ao destino.
O próximo passo é reconciliar o estado usando a identidade e os recursos disponíveis no serviço. Pode ser possível consultar a tarefa pelo identificador externo ou recuperar o resultado da operação. Se não houver forma fiável de confirmar, mantém o caso visível para revisão, em vez de escolher sucesso ou falha por suposição.
Um estado “em processamento” também precisa de recuperação. Se a execução termina inesperadamente, essa marca não pode bloquear o item para sempre. Define quem verifica os casos parados, como distingue uma execução ainda ativa e em que condições autoriza uma nova tentativa.
Regista o ID do evento, a identidade do objeto, a etapa e o resultado observado. Evita copiar credenciais ou dados pessoais desnecessários para o histórico. O objetivo do registo é permitir diagnóstico e reconciliação, sem criar uma segunda base de dados sensível apenas para depurar o fluxo.
Usa idempotência quando o destino a suporta
Confirma se o serviço de destino permite repetir uma operação com uma chave de idempotência e quais são as condições dessa funcionalidade. A chave deve representar a mesma operação lógica durante as tentativas. Não assumas que todos os serviços, métodos ou versões de API oferecem o mesmo comportamento ou a mesma retenção.
A idempotência procura evitar que repetir o pedido produza novamente o efeito pretendido. No nosso exemplo, a operação de criar T01 deve continuar identificável quando uma tentativa precisa de ser repetida. Uma alteração legítima a T01 pode corresponder a outra operação, com regras próprias de versão e atualização.
A documentação de pedidos idempotentes da Stripe mostra um contrato concreto, com diferenças entre API v1 e v2. Na v1, a reutilização da chave está sujeita à retenção e à correspondência dos parâmetros. Este é um exemplo técnico de comportamento documentado, não uma regra que possas transferir automaticamente para qualquer integração.
Não uses um email ou outro dado pessoal como chave só por estar disponível. Prefere um identificador adequado à operação e guarda a relação necessária no teu sistema autorizado. Evita também gerar uma chave nova a cada tentativa do mesmo pedido, porque isso pode deixar de o identificar como repetição.
Mesmo com idempotência no destino, continua a verificar o workflow completo. Criar uma tarefa e enviar uma mensagem são efeitos distintos. Uma garantia sobre a criação não impede automaticamente que o envio se repita. Cada efeito relevante precisa da sua identidade, estado e estratégia de recuperação.
Testa repetições, correções e resultados incertos
Prepara casos sintéticos com resultados esperados antes de executar o piloto. Inclui a repetição simples, a alteração legítima, a falta de identificador e a chegada simultânea. Confere a quantidade e a identidade dos registos no destino, sem concluir que o fluxo funciona apenas porque os nós terminaram sem apresentar erro.
No exemplo, usa uma conta fictícia C01, a reunião M01 e as tarefas T01 e T02. Mantém o mesmo evento para a repetição e usa um evento de atualização distinto quando muda um campo autorizado. Se alterares o conteúdo de um evento que deveria ser imutável, trata isso como inconsistência a investigar.
| Caso de teste | Resultado esperado no exercício |
|---|---|
| T01, T01 e T02 na mesma lista | Duas identidades de tarefa |
| Repetição do evento original | Sem segunda criação das mesmas tarefas |
| Atualização autorizada de T01 | Mesmo registo, campos permitidos atualizados |
| T01 noutra reunião | Registo distinto quando é outro compromisso |
| Identificador obrigatório ausente | Pendência explícita, sem criação inventada |
| Duas execuções simultâneas | Unicidade conferida no mecanismo de escrita |
| Resposta perdida após a ação | Reconciliação antes de repetir o efeito |
Uma verificação local da lógica das identidades pode ajudar a detetar colisões e erros de contagem. Continua a ser diferente de executar o nó, testar concorrência na base ou observar o serviço externo. Regista estes níveis de validação separadamente para não dar um ensaio parcial como integração concluída.
Depois de uma falha, repete apenas o necessário e observa o destino. O guia para usar webhooks para receber eventos no workflow ajuda a distinguir receção, resposta e processamento. Um evento aceite na entrada não comprova que todas as ações posteriores terminaram.
Mantém uma rotina de reconciliação e manutenção
Depois do piloto, define como vais detetar itens em falta, estados parados e registos repetidos ao longo do tempo. Revê a retenção do histórico, as mudanças nas APIs e os efeitos de editar o workflow. A proteção depende do percurso em uso e precisa de continuar verificável depois da primeira entrega.
No exercício, uma reconciliação pode comparar as tarefas confirmadas da reunião com as identidades existentes no destino. Se falta T02, investiga a etapa correspondente. Se existem duas cópias de T01, preserva a evidência e define qual registo deve permanecer antes de eliminar ou fundir informação.
Não limpes o histórico de deduplicação apenas para fazer um teste voltar a passar. Essa ação altera a memória usada pelo processo e pode permitir novas repetições. Usa um ambiente de teste separado e documenta o que foi reiniciado, para não confundir dados de ensaio com trabalho real.
Quando mudares a regra de identidade, avalia os registos já existentes. Uma nova combinação de campos pode deixar de reconhecer tarefas antigas ou juntar objetos antes separados. Testa a migração com uma amostra e mantém uma forma de recuperar a correspondência anterior se encontrares um erro.
O processo fica mais robusto quando consegues explicar o destino de cada evento: criou, atualizou, foi reconhecido como repetição ou ficou pendente com motivo. Essa visibilidade ajuda a corrigir falhas sem multiplicar ações e sem esconder trabalho que ainda precisa de ser concluído.
Como podes aprender a construir automações no Laboratório
No Laboratório da IA, podes aprender a desenhar fluxos, organizar dados e testar integrações com critérios claros. As aulas semanais e os Zooms de acompanhamento semanais ajudam a trabalhar casos como tarefas repetidas, falhas de execução e correspondência entre sistemas, ligando o desenho do processo ao efeito que precisas de verificar.
Traz um exemplo sintético da entrada, a regra de identidade e o resultado esperado. Com esse contexto, podes perceber onde testar a repetição, que capacidades confirmar no destino e como manter as pendências recuperáveis antes de aumentar o volume.
Referências e limites da verificação
As referências foram verificadas em 14 de outubro de 2026 e sustentam os comportamentos documentados das ferramentas mencionadas. Os identificadores e tarefas são fictícios. O artigo apresenta desenho e casos de teste; não afirma execução de um workflow n8n, teste de concorrência PostgreSQL ou operação real na Stripe.
Aprende a construir isto no Lab.
Trabalha o processo com aulas, materiais e acompanhamento. Leva o que estás a construir e esclarece as dúvidas da tua implementação.
- Distinguir objeto, evento e efeito numa automação.
- Definir casos de teste para repetições e resultados incertos.
- Praticar integrações nas aulas e Zooms semanais do Laboratório.
Aulas semanais para aprender e aplicar. Zooms de acompanhamento semanais para esclarecer dúvidas. Replay e materiais para retomar o trabalho ao teu ritmo.
Entrar no Laboratório da IA