Como criar condições com IF e Filter no n8n

Escreve a regra antes de configurar o nó

Começa por explicar a decisão numa frase que outra pessoa consiga aplicar aos mesmos dados. Identifica os campos usados, os valores aceites e o que deve acontecer quando a informação está incompleta. Esta preparação ajuda a escolher a condição certa e a reconhecer resultados errados. O desenho do fluxo deve representar uma regra compreendida, com exceções visíveis.

Vamos usar um exercício fictício com tarefas internas. Queremos selecionar tarefas cujo estado seja “aberta” e cuja prioridade seja “alta”. As restantes tarefas completas seguem para uma revisão separada. As tarefas com campos em falta ficam pendentes de classificação, sem receber um estado ou uma prioridade inventados.

Esta frase contém três decisões diferentes: reconhecer dados completos, avaliar dois critérios em conjunto e definir o destino dos outros casos. Se começares por arrastar nós sem separar essas decisões, podes acabar com uma condição que parece funcionar para o primeiro exemplo e falha quando chega uma entrada diferente.

Define também o efeito final. Neste ensaio, vamos apenas observar os itens de cada saída. Não precisamos de enviar mensagens, alterar tarefas reais ou ligar credenciais para perceber se a lógica está correta. Quando o encaminhamento estiver conferido, poderás acrescentar o destino adequado ao teu processo.

Se as tarefas foram extraídas por IA, a presença de campos não prova que os compromissos existem na fonte. Confirma primeiro o conteúdo e distingue decisão de proposta. A condição pode verificar um valor estruturado, mas não substitui a revisão que determina se esse valor representa corretamente o que foi acordado.

Prepara uma pequena entrada com identidades claras

Cria uma amostra sintética que contenha casos diferentes e conserva um identificador em cada item. Usa nomes de campos consistentes e valores fáceis de conferir. A identidade permite acompanhar o mesmo registo ao longo do fluxo, mesmo quando a ordem muda. Antes de avaliar condições, confirma que cada tarefa chega como um item separado no ponto em que será analisada.

Para este exercício, os campos são id, estado e prioridade. Os quatro primeiros itens estão completos. O quinto tem a prioridade por preencher e serve para testar a pendência de dados. Estes valores são apenas exemplos editoriais, sem correspondência com tarefas ou pessoas reais.

Um objeto representativo do primeiro item seria {"id":"T01","estado":"aberta","prioridade":"alta"}. A forma de o introduzir depende do ponto de entrada do teu ensaio. Confere no painel de dados o objeto efetivamente recebido, em vez de assumir que a estrutura do exemplo já corresponde à saída do teu formulário ou da tua API.

Se tens uma lista de tarefas dentro de um único item, precisas de decidir como a vais tratar. O guia para separar listas em tarefas com o Split Out do n8n explica esse caso. Uma condição aplicada ao item exterior não equivale automaticamente a avaliar cada elemento da lista.

Escolhe IF quando precisas de tratar os dois resultados

Usa IF quando a regra precisa de encaminhar os itens para dois percursos distintos. Define o significado de cada saída no teu processo e conserva a identidade dos registos. O resultado falso pode representar um caso perfeitamente válido que exige outro tratamento. Não o confundas com uma falha técnica nem com autorização para eliminar informação que ainda precisa de acompanhamento.

A documentação do nó IF descreve a divisão condicional com operações de comparação. No nosso ensaio, a saída verdadeira corresponde às tarefas abertas com prioridade alta. A saída falsa recebe os outros itens completos, que serão observados separadamente antes de decidir qualquer ação posterior.

Para montar a comparação, escolhe o campo estado como valor de entrada, o tipo de comparação de texto e a igualdade com aberta. Acrescenta a condição de prioridade igual a alta e combina as duas com AND. Confere os valores resolvidos pela expressão no item de teste.

Se a tua expressão usa o item atual, a referência pode ser {{ $json.estado }} para o primeiro campo. O nome precisa de corresponder ao que realmente chega ao nó. Um campo chamado status não passa a chamar-se estado por o exemplo usar esse nome, e uma propriedade dentro de outro objeto exige o caminho correto.

Liga cada saída a um passo de observação sem efeitos externos durante o ensaio. O objetivo é conferir os IDs encaminhados, não apenas ver uma ligação destacada no editor. Se T03 aparecer no percurso das tarefas selecionadas, a regra não corresponde ao que definimos, mesmo que a execução termine sem erro.

Escolhe Filter quando só os itens selecionados devem continuar

Usa Filter quando o percurso seguinte só precisa dos itens que cumprem a condição e não existe uma ação nesse ramo para os restantes. Define o que significa essa exclusão no processo. Se precisas de rever ou registar os casos que não passam, prepara esse tratamento explicitamente. A escolha do nó depende do destino necessário para cada conjunto de dados.

Segundo a documentação do Filter, os itens que cumprem a condição seguem na saída; os outros são omitidos dessa saída. Isto não significa apagar os registos no sistema de origem. A seleção limita os dados que continuam naquele ponto do workflow.

No exercício, poderias usar Filter para alimentar uma lista dedicada às tarefas abertas de prioridade alta. T01 continuaria para essa lista. T02, T03 e T04 não fariam parte da saída filtrada. Se o teu objetivo inclui uma lista separada para os três, o IF torna essa necessidade mais explícita no desenho.

Evita interpretar uma saída vazia como erro automático. Pode significar que nenhum item cumpriu a regra naquele lote. Confere a entrada e o critério antes de alterar a condição para fazer passar alguma coisa. Uma seleção correta pode produzir zero itens, desde que esse caso esteja previsto no processo.

Confere a diferença entre AND e OR com os mesmos dados

Escolhe a combinação das condições pelo significado da regra. AND exige que todas as condições sejam satisfeitas; OR admite que uma delas seja suficiente. Usa a mesma amostra para comparar os conjuntos resultantes. Esta conferência ajuda a detetar uma troca de lógica que pode passar despercebida quando só testas um caso positivo.

Com as tarefas completas T01 a T04, a regra “estado aberta AND prioridade alta” seleciona apenas T01. A regra “estado aberta OR prioridade alta” seleciona T01, T02 e T03. T04 não cumpre nenhuma das condições. A diferença está nos casos que satisfazem apenas um dos critérios.

No contexto do exercício, OR permitiria passar uma tarefa fechada de prioridade alta. Isso contraria a intenção de trabalhar apenas tarefas abertas prioritárias. O problema não estaria na ferramenta, mas na tradução da regra. Por isso é útil escrever a frase de decisão e os resultados esperados antes de configurar.

Estes conjuntos foram conferidos com lógica local sobre a amostra fictícia. Essa verificação confirma a relação esperada entre os valores, mas não equivale a executar os nós numa instalação n8n. Na tua conta, deves repetir o ensaio e observar os dados de entrada, as condições e as saídas efetivas.

Quando a regra combina vários grupos, como “aberta e prioridade alta ou prazo ultrapassado”, esclarece primeiro os parênteses pretendidos. A frase pode ter interpretações diferentes. Divide a decisão em passos compreensíveis ou usa uma expressão revista, sem assumir que uma lista de condições representa qualquer agrupamento lógico.

Trata campos ausentes e tipos antes de tomar decisões

Confirma que os campos necessários existem e que os seus tipos correspondem à comparação. Distingue texto, número, booleano e informação ausente. Decide o tratamento dos casos incompletos antes de aplicar a regra de negócio. Uma conversão automática pode tornar a condição executável e, ainda assim, esconder um problema na origem dos dados ou mudar o significado da entrada.

T05 tem prioridade por preencher. No exercício, essa tarefa fica numa pendência própria antes da comparação entre tarefas completas. Não lhe atribuímos “normal” só para facilitar a passagem pelo fluxo. A ausência pode exigir uma pergunta, uma consulta à origem ou revisão por quem conhece a tarefa.

Um booleano true é diferente do texto "true". Da mesma forma, uma quantidade recebida como texto pode exigir preparação antes de uma comparação numérica. Confere o valor e o tipo reais, em vez de olhar apenas para a forma como aparecem visualmente numa tabela do editor.

O Filter disponibiliza opções de sensibilidade a maiúsculas e de validação de tipos menos estrita, descritas na sua documentação. Se as alterares, regista o motivo e repete os testes. Ignorar maiúsculas pode ser adequado para um campo controlado; não resolve espaços inesperados, valores desconhecidos ou uma prioridade que nunca foi fornecida.

O guia para organizar dados em JSON antes de os enviar à IA ajuda a definir campos e lacunas. Mantém essa disciplina depois da resposta da IA: uma estrutura válida pode conter uma interpretação errada, e uma condição só deve usar o valor depois da revisão necessária ao efeito pretendido.

Distingue o filtro visual da seleção durante a execução

Confirma se estás apenas a mudar o que vês no editor ou a alterar os dados que seguem no workflow. São operações diferentes e podem produzir uma impressão enganadora durante o diagnóstico. Observa a saída da execução e o nó responsável pela transformação. Uma pesquisa que esconde linhas no painel não demonstra que os itens foram retirados do percurso real.

A documentação de filtragem de dados do n8n distingue a pesquisa visual nos painéis da filtragem durante a execução. Também separa selecionar itens inteiros, remover campos e filtrar elementos de uma lista interna. Escolhe a operação pelo nível dos dados que queres alterar.

No exemplo, procurar T01 no painel pode facilitar a sua inspeção. Isso não substitui a condição que seleciona tarefas abertas de prioridade alta. Se o nó seguinte ainda recebe quatro itens, o facto de veres apenas uma linha na pesquisa não muda o conjunto que será processado.

Retirar o campo prioridade também não seleciona tarefas prioritárias. Apenas remove informação de cada item afetado pela transformação. Se precisas desse campo para uma decisão posterior, a remoção pode criar uma falha que só aparece mais à frente. Confere as dependências antes de simplificar a estrutura.

Para investigar referências ao item errado ou campos que desaparecem, consulta o guia para usar expressões no n8n sem perder campos importantes. Mantém o ID durante o diagnóstico, para conseguir comparar o mesmo registo em cada etapa e localizar onde a informação mudou.

Valida o percurso antes de acrescentar efeitos externos

Revê os testes, os IDs de cada saída e as exceções antes de ligar ações que alteram sistemas. Inclui entrada vazia, campo ausente e evento repetido. Regista o que observaste na execução atual. Uma condição correta é parte do processo; o destino ainda precisa de usar os dados certos e lidar com falhas ou repetições.

No ensaio, confirma T01 no conjunto selecionado, T02 a T04 no outro conjunto quando usas IF, e T05 na pendência de dados. Repete com uma entrada sem tarefas. Depois altera apenas um valor e verifica se a mudança de percurso corresponde à regra, conservando os restantes resultados.

Se o workflow veio de um exemplo antigo, confere a versão dos nós e a ordem de execução configurada. A documentação do IF assinala um comportamento histórico com Merge na ordem antiga. Não generalizes uma nota de compatibilidade a todas as instalações atuais nem mudes várias opções sem identificar o problema observado.

Ao acrescentar o destino real, testa primeiro um efeito limitado e verificável. Confirma o registo criado ou atualizado e a sua identidade. Se repetir o evento duplica a tarefa, o encaminhamento pode estar correto e continuar a faltar controlo de repetição. Resolver uma condição não resolve automaticamente todas as propriedades da automação.

Guarda a regra, a amostra e o resultado esperado junto do workflow. Quando mudar o processo, atualiza estes elementos e repete o ensaio relevante. A documentação deve permitir perceber por que um item segue determinado caminho, sem depender de recordar a conversa em que a condição foi criada.

Como podes aprender isto no Laboratório da IA

No Laboratório da IA, podes praticar automações com regras concretas e dados que consegues conferir. As aulas semanais e os Zooms de acompanhamento semanais ajudam-te a trabalhar estrutura, condições e diagnóstico. Leva uma decisão repetitiva do teu processo e prepara alguns exemplos, incluindo um caso incompleto, para começares por um percurso pequeno e verificável.

Aprende a escolher o nó pelo comportamento que precisas e a seguir os dados até ao resultado. Começa por observar as saídas, corrige a lógica e só depois acrescenta as ações necessárias. Esta forma de trabalhar ajuda-te a compreender o fluxo e a manter as exceções visíveis quando o processo cresce.

Referências e data de revisão

Este artigo foi revisto em 14 de outubro de 2026 com base em materiais do Laboratório da IA sobre tarefas estruturadas, testes e diagnóstico de workflows. A documentação oficial confirma o comportamento dos nós. Os dados são fictícios e os conjuntos AND/OR foram conferidos localmente; não foi executado um workflow n8n nem alterado qualquer sistema externo.

• n8n: nó IF e condições.
• n8n: nó Filter e opções de comparação.
• n8n: filtragem visual, itens, campos e listas.