👤 Para todos os usuários
🔐 Disponível para planos Business, Enterprise e Unlimited
🎯 Para quem já tem ao menos uma automação ativa e quer afinar as regras do processo
Você cria uma automação para mover um card quando um campo é atualizado. Ela funciona. Mas logo percebe que dispara em casos que não deveria: o campo foi preenchido, mas faltavam outras informações críticas. Ou então a regra deveria valer para dois perfis diferentes de solicitação, e você acabou criando duas automações separadas para fazer o mesmo trabalho.
Condições múltiplas existem exatamente para fechar essa lacuna. Ao final deste artigo, você vai saber quando usar AND (mais condições no mesmo grupo) e quando usar OR (grupos de condições diferentes), e como aplicar cada lógica a processos reais de aprovação e notificação.
📖 O que você vai entender aqui:
Por que automação simples às vezes não basta
Uma automação sem condição é uma instrução incondicional: sempre que X acontecer, faça Y. Para muitos casos, isso resolve. Mas quando o processo tem regras de negócio, uma automação sem condição vira ruído.
Pense em um processo de compras. Você quer mover automaticamente um pedido para a fase de aprovação gerencial, mas só quando o valor superar um limite específico. Sem condição, todo pedido vai para aprovação gerencial, independente do valor. O gestor recebe notificações irrelevantes e começa a ignorá-las.
O mesmo acontece com notificações segmentadas: se você quer avisar times diferentes conforme o tipo de solicitação, uma única regra sem condição vai notificar todo mundo o tempo todo.
Condições transformam automações de instruções genéricas em regras de negócio precisas. Quanto mais o processo amadurece, mais as condições fazem a diferença.
AND e OR no contexto do processo
A distinção entre AND e OR no Pipefy não é lógica booleana abstrata. É a diferença entre dois tipos de regra de negócio.
-
AND: minha regra exige que tudo aconteça ao mesmo tempo
Você adiciona mais condições dentro do mesmo grupo. A automação só dispara quando o card atende todas elas simultaneamente.
Exemplo: aprovar automaticamente um pedido de compra apenas quando o valor for inferior a R$ 5.000 E o fornecedor já estiver cadastrado. Se uma das duas condições não for verdadeira, a automação não executa. Isso evita aprovar pedidos de fornecedores não cadastrados, mesmo que estejam dentro do limite de valor.
-
OR: basta que um caso seja verdadeiro
Você cria grupos de condições separados. A automação dispara se o card atender ao menos um dos grupos.
Exemplo: notificar o time de compliance quando o pedido for de alto valor OU quando o fornecedor for internacional. São dois perfis de risco diferentes. Qualquer um deles, isoladamente, já justifica a notificação.
Antes de configurar, pergunte: a minha regra de negócio usa "e" ou "ou"? Se a resposta for "e", é o mesmo grupo. Se for "ou", são grupos separados.
Exemplo 1: aprovação condicional por valor e perfil
Processo de referência: Solicitação de Compras.
O time financeiro quer um fluxo de aprovação em dois níveis:
- Pedidos abaixo de R$ 5.000 feitos por fornecedores já cadastrados: aprovação automática pelo analista.
- Pedidos acima de R$ 5.000 ou de fornecedores não cadastrados: encaminhar para aprovação do gestor.
Para o primeiro caso: evento "campo for atualizado" no campo de valor. No mesmo grupo de condições, adicione: valor inferior a 5.000 E fornecedor igual a "cadastrado". Ação: mover o card para a fase "Aprovação analista".
Para o segundo caso: crie uma segunda automação. Grupo 1: valor superior a 5.000. Grupo 2 (separado): fornecedor igual a "não cadastrado". Ação: mover o card para "Aprovação gerencial" e notificar o gestor por e-mail.
O resultado: o volume de aprovações gerenciais cai porque a triagem acontece automaticamente. O gestor só recebe o que realmente precisa da atenção dele.
Cada disparo do gatilho conta como uma tarefa de automação, mesmo quando a condição não é atendida e a ação não executa. Em processos de alto volume, isso impacta o consumo mensal do plano.
Exemplo 2: notificações segmentadas por perfil de solicitação
Processo de referência: Onboarding de colaboradores.
O time de RH quer que cada área receba notificações apenas sobre o que é de sua responsabilidade:
- TI: quando o card entrar na fase "Acessos" e o campo "cargo" for igual a "desenvolvedor" OU "analista de sistemas".
- Facilities: quando o card entrar na fase "Acessos" e o campo "modalidade" for igual a "presencial".
Para TI: evento "card entrar em uma fase" (Acessos). Grupo 1: cargo igual a "desenvolvedor". Grupo 2 (separado): cargo igual a "analista de sistemas". Ação: notificar o canal do time de TI.
Para Facilities: mesma fase, grupo único com condição "modalidade igual a presencial". Ação: notificar Facilities.
O que isso resolve: cada time deixa de receber alertas que não são da sua alçada. A confiança nas notificações aumenta porque elas chegam contextualizadas.
Como depurar condições que não disparam como esperado
Quando uma automação com condições não executa, os três problemas mais comuns são:
O campo referenciado ainda não estava preenchido quando o gatilho disparou
Se o evento é "card entrar em uma fase" mas o campo é preenchido depois, a condição já foi avaliada como falsa. Solução: mudar o evento para "campo for atualizado" no campo relevante.
A condição usa "igual a" mas o valor tem variação de escrita
"Desenvolvedor" e "desenvolvedor" podem não ser equivalentes dependendo do tipo de campo. Prefira campos de seleção (select, radio) a campos de texto livre quando precisar usar condições.
Os grupos de condições estão invertidos
Você configurou AND onde queria OR, ou vice-versa. Antes de salvar, releia em voz alta: "a automação deve disparar quando A e B acontecem juntos, ou quando acontece A ou B separadamente?"
Toda vez que você editar campos, fases ou alertas no pipe, reavalie as automações com condições. Alterações estruturais podem quebrar regras que dependem de valores específicos de campos que mudaram.
Antes de avançar, confirme que você entende:
☐ Quando usar AND (mesmo grupo) e quando usar OR (grupos separados)
☐ Como configurar condições múltiplas em uma automação existente
☐ Por que o tipo de campo impacta o funcionamento das condições
☐ Como verificar nos logs se uma condição está sendo avaliada corretamente
