👤 Para usuários com processo ativo que configuraram automações e perceberam que elas pararam de disparar ou de mover cards
🔐 Disponível para todos os planos (o comportamento varia por plano nos limites de automação)
🎯 Para quem quer descobrir sozinho por que uma automação silenciosa parou, sem abrir chamado
Um card entra na fase que deveria disparar a automação, e nada acontece. O processo simplesmente para ali. Ninguém recebeu o e-mail, o card não avançou, e no dia a dia isso vira aquela sensação de que o fluxo “engasgou” sem motivo aparente. A parte mais desconfortável quase nunca é a automação em si: é não saber por onde começar a olhar. Reconfigurar tudo do zero costuma ser a primeira reação, e quase sempre é a mais custosa.
Existe um caminho de diagnóstico que economiza esse retrabalho. Ao terminar este artigo, você vai saber em que ordem investigar, o que o log de automações revela sobre cada execução e como identificar, pela evidência, qual dos motivos mais comuns está por trás do problema.
📖 O que você vai entender aqui:
A regra está lá, mas o processo não anda: por onde olhar primeiro
Quando uma automação para, a causa quase sempre está em uma de três camadas, e vale investigar nessa ordem, da mais provável para a menos provável.
- A condição de disparo. A automação depende de um evento (um card entrou numa fase, um campo foi atualizado). Se o evento não aconteceu exatamente como a regra espera, ela nem chega a rodar.
- O estado do card. Campos obrigatórios em branco, dados em formato inválido ou a fase de destino não habilitada travam a movimentação antes da automação concluir.
- A relação entre regras e pipes. Duas automações com o mesmo gatilho, ou uma conexão entre pipes com opções avançadas ligadas, geram comportamento que parece aleatório mas tem causa.
Antes de mexer na regra, confirme que o evento realmente aconteceu. Uma automação que “não disparou” muitas vezes nunca teve o gatilho satisfeito, e nenhuma reconfiguração resolve isso.
O log de automações: a evidência antes do palpite
O Pipefy registra o que acontece com cada automação, e é por aí que o diagnóstico deveria começar, antes de qualquer alteração. O registro mostra o status de execução do gatilho, quais tarefas foram concluídas com sucesso e quais falharam, e o dia e horário de cada uma, com filtros para segmentar a lista. Em vez de supor por que a regra não rodou, você lê o que de fato aconteceu.
Ler o log muda a lógica da investigação. Se a execução aparece como falha, o problema está no card ou na configuração e você já sabe onde procurar. Se ela nem aparece, o gatilho não foi satisfeito, e o foco passa a ser a condição de disparo, não a ação. Abrir um registro específico revela o detalhe daquela execução, o que costuma apontar direto para a causa.
O recurso de logs de automação está em fase Beta. O comportamento e a nomenclatura da tela podem mudar; confirme o nome exato e a disponibilidade no seu ambiente antes de orientar o time.
Saiba mais: Logs de automação e como funcionam as regras e tarefas de automação.
Os cinco motivos mais comuns e como reconhecer cada um
Quando a automação move cards e ela parou, cinco causas respondem pela maioria dos casos. O que muda entre elas é a evidência que cada uma deixa; é isso que te diz qual investigar.
1. Campo preenchido em formato inválido
Campos de e-mail, telefone e documento precisam de dados válidos no formato esperado. Quando o dado não bate, o campo fica destacado em vermelho e a movimentação não completa. Critério de identificação: abra o card e procure o campo sinalizado; a evidência é visual e imediata.
2. Campo obrigatório em branco
Um card com campo obrigatório não preenchido não se move. Vale para o formulário inicial (uma automação que move o card logo após a criação não convive com campos obrigatórios no formulário inicial) e para o formulário da fase anterior. Critério de identificação: se a automação dispara na entrada do card e nunca funciona, suspeite primeiro de obrigatoriedade no formulário inicial.
3. Fase de destino não habilitada para a movimentação
Toda fase nova nasce sem permissão de movimentação a partir das fases existentes. Se você criou a fase de destino recentemente e a automação nunca rodou para ela, a habilitação de movimentação nas configurações avançadas da fase de origem é o primeiro lugar a checar. Critério de identificação: a regra está correta, o card está completo, mas ele nunca chega no destino recém-criado.
4. Conexão entre pipes com opções avançadas ligadas
Quando os cards passam por um campo de conexão com outro pipe, opções avançadas ativas nesse campo podem bloquear a movimentação. Critério de identificação: a automação envolve pipes conectados e o travamento acontece exatamente no ponto da conexão.
5. Campos de seleção com opções divergentes entre pipes
Em pipes conectados, campos de seleção (única ou lista) precisam ter exatamente as mesmas opções, escritas da mesma forma. Se divergem, o Pipefy não transfere o dado, e uma automação que depende dessa atualização não acontece. Critério de identificação: o problema aparece só no fluxo entre dois pipes, e some quando os campos de seleção são alinhados.
Repare no padrão: as causas 1 e 2 vivem dentro de um único pipe; as causas 4 e 5 só aparecem quando há conexão entre pipes. Saber em qual das duas situações você está corta metade das hipóteses de uma vez.
Quando o problema não é a regra, e sim o consumo do plano
Existe um cenário em que a configuração está impecável e mesmo assim as automações param: o limite de tarefas de automação do plano. Cada disparo ou verificação conta como uma tarefa, e cada plano tem seu limite. O sinal característico é diferente do de uma regra quebrada: não é uma automação específica que falha, são várias parando ao mesmo tempo, tipicamente perto do fim do ciclo de cobrança. Se a evidência aponta para isso, o caminho é acompanhar o consumo, não reconfigurar as regras.
Saiba mais: como o Pipefy contabiliza automações no seu plano.
Se nada disso resolveu
Percorreu as três camadas, leu o log, descartou o consumo do plano e a automação continua parada? Aí a evidência já está reunida: você sabe se a execução falhou ou nem apareceu, em qual pipe, e a partir de qual fase. Com esse retrato pronto, o acionamento do suporte deixa de ser “minha automação não funciona” e passa a ser um relato específico, que resolve mais rápido.
Antes de avançar, confirme que você entende:
☐ Que a investigação começa pela camada mais provável (condição de disparo), não pela reconfiguração da regra
☐ Que o log de automações mostra se a execução falhou ou nem aconteceu, e isso define onde procurar
☐ Que você consegue olhar um card travado e reconhecer, pela evidência, qual dos cinco motivos está em jogo
