Skip to main content

Automações essenciais no Pipefy: os 5 gatilhos que todo processo precisa

  • August 18, 2026
  • 0 replies
  • 33 views
joao-castro-pipefy
Pipefy Staff

👤  Para admins de pipe que já têm um processo estruturado e querem torná-lo automático
🔐  Recursos de automação disponíveis conforme o plano
🎯  Para quem assistiu ao webinar e quer o conteúdo por escrito, ou para quem quer dominar as automações essenciais sem depender da gravação

 

Sou João Pedro Castro, Customer Success Manager na Pipefy, e há cerca de três anos acompanho de perto o que separa um processo que só está organizado de um que trabalha sozinho. Este conteúdo faz parte da série de treinamentos da Pipefy Academy e usa um processo de reembolso como exemplo, um dos mais horizontais que existem, para mostrar as automações mais essenciais dentro da ferramenta.

 

 

Ao terminar a leitura você vai entender o modelo único que está por trás de qualquer automação e saber configurar as cinco que todo processo precisa, sem decorar receitas soltas.

 

📖  O que você vai entender aqui:

 

O que vem antes de qualquer automação

Uma automação que não funciona quase nunca falha por causa da automação. Falha porque o processo embaixo dela não estava bem desenhado. É o cenário mais comum que vejo com clientes: alguém levanta a mão e diz que a automação não dispara, e a raiz está nas fases mal estruturadas ou no tipo de campo errado.

Um exemplo direto: se a automação precisa fazer um cálculo ou ler uma data, o campo tem que ser de número ou de data. Configurar uma automação para atribuir responsável a partir de um campo de texto não funciona, porque campo de texto e campo de responsável são coisas completamente diferentes. Por isso a base é sempre a mesma: fases corretas, campos corretos e lógica bem definida. Automação, seja básica ou avançada, com agente de IA ou integração, vem depois disso.

 

Antes de automatizar, garanta que as pessoas responsáveis pelas ações já estão adicionadas ao pipe e que os campos suportam o valor que a automação vai manipular. Automação boa em processo mal desenhado só antecipa o erro.

 

O modelo único: evento, condição e ação

O Pipefy nasceu resolvendo um primeiro problema, padronizar processos: campos, fases e a ordem em que os cards percorrem a jornada. Automação é o passo seguinte. Agora que o processo está organizado, como faço para ele funcionar sozinho, com o mínimo de interação possível?

Toda automação no Pipefy é uma regra baseada em um critério definido pela política da empresa, e toda regra segue a mesma anatomia:

  • Evento. O gatilho, o disparo. Algo acontece: um card é criado, um campo é atualizado, um card entra numa fase, um alerta é acionado.
  • Condição. O filtro que decide se a ação segue. É o critério que delimita quando aquele gatilho vale, por exemplo o valor do reembolso ser maior que um número, e o tipo ser alimentação.
  • Ação. O que acontece quando evento e condição batem: mover o card, enviar um e-mail, atribuir responsável, atualizar um campo.

 

Domine esse padrão e você configura qualquer regra em vez de decorar receitas. Num processo de reembolso, você não precisa lembrar que aprovação acima de um valor vai para uma pessoa e abaixo vai para outra: a automação prevê o cenário e executa. O mesmo modelo serve a recrutamento, solicitação de férias, onboarding, qualquer fluxo.

 

Uma condição ampla demais dispara a automação para cards que você não queria atingir. Delimite o cenário exato: quanto mais preciso o filtro, menos efeito colateral.

 

Onde as automações vivem, e quem pode mexer nelas

Dentro do pipe, o menu de Automações reúne, filtra e dá visibilidade de todas as regras daquele pipe. Automações de outros pipes não aparecem ali. Dá para visualizar em card ou em lista mais resumida, útil quando o pipe tem muitas automações, e filtrar por status (ativa ou inativa), por evento ou por ação. Se você quiser ver todas as automações cujo gatilho é card criado, ou todas que fazem movimentação de card, o filtro resolve.

 

Para configurar automação, é preciso ser administrador do pipe. Membro do pipe visualiza e trabalha nos cards, mas não mexe na estrutura do processo, e automação é estrutura. Se você abriu um pipe e não vê os botões de automações, integrações e configurações, provavelmente é uma questão de nível de acesso, não de plano.

 

 

Antes da anatomia da regra, conheça os logs. Toda vez que uma automação dispara, o log registra qual automação rodou, em qual card, o id do card, se deu sucesso ou falha e o horário. Quando uma automação não surtir o efeito esperado, o primeiro lugar a olhar é o log: muitas vezes a gente espera que ela tenha disparado, mas o evento nem chegou a ocorrer.

 

 

Os cinco gatilhos essenciais

Todos foram demonstrados no mesmo pipe de reembolso, com a regra de que solicitações acima de um valor caem automaticamente para a diretoria aprovar.

 

1. Card criado move o card por condição

O primeiro gatilho é o mais direto: sempre que um card for criado no pipe, se ele atender à condição, o card se move sozinho. No exemplo, valor a ser reembolsado maior que um número move o card para a fase de análise de diretoria, porque acima daquele teto quem aprova é o diretor.

A condição pode combinar mais de um critério. Valor maior que quinhentos e tipo igual a alimentação: as duas precisam ser verdadeiras para disparar. Se o card for maior que quinhentos mas não for alimentação, a automação não executa. E dá para criar grupos de condição com lógica ou: um grupo com um par de critérios, outro grupo com outro par, e a automação dispara se qualquer um dos grupos for atendido.

 

 

2. Card criado dispara um template de e-mail

Com o mesmo gatilho, card criado, uma segunda automação pode enviar um e-mail. No teste, ao criar o card a pessoa recebeu na hora a confirmação de que a solicitação foi registrada e está em determinada fase.

O ponto central aqui é o template com campos dinâmicos. Você configura a mensagem uma vez e ela se preenche sozinha com os dados de cada card: "Olá, [nome do formulário], sua solicitação de reembolso de [tipo] no valor de [valor] foi criada com sucesso." O mesmo template serve para o caso de reprovação, com um campo dinâmico onde o financeiro escreve a justificativa (comprovante rasurado, informação faltando, teto excedido). Configurado uma vez, dispara em massa conforme os cards nascem.

 

A ordem importa: o template de e-mail precisa existir antes. Crie o template em E-mails, na seção de templates, e só depois configure a automação que o dispara. Sem o template pronto, a automação de e-mail não tem o que enviar.

 

 

3. Card entra na fase atualiza campo e atribui responsável

Quando o card entra numa fase, a ação pode ser atualizar um campo, e o caso mais útil é a atribuição de responsável. Há três formas:

  • Fixa. Sempre a mesma pessoa. No exemplo, ao entrar na análise de diretoria com tipo igual a itens ergonômicos, o responsável é sempre o mesmo aprovador.
  • Distribuição igualitária (round-robin). O card rotaciona entre as pessoas de um grupo em ordem, equilibrando a carga. Útil quando três analistas do financeiro precisam receber demandas de forma uniforme: primeiro card para uma, o próximo para outra, e assim por diante.
  • Aleatória. Sem regra fixa, o sistema distribui sem ordem definida.

 

Para atribuir responsável por automação, a fase precisa ter um campo do tipo atribuição de responsável. Sem esse campo, não há onde a automação colocar a pessoa. Isso volta ao ponto de partida: o campo certo antes da regra.

 

4. Alerta acionado escalona o card parado

Este é o gatilho que garante que nada trave sem ninguém ver. Quando um card ultrapassa um prazo, um alerta é acionado, e esse alerta é um evento que dispara automação. São três tipos de alerta, e a diferença entre eles importa:

  • Atrasado. O card passou do tempo máximo definido para aquela fase. Se a fase permite no máximo um dia e o card fica mais que isso, ele se torna atrasado.
  • Expirado no pipe. O card passou do tempo máximo definido para o pipe inteiro sem chegar a uma fase final. Se o pipe permite cinco dias e o card não concluiu nesse prazo, expira.
  • Vencido. Baseado em um campo de data específico do card, como uma data de vencimento ou de pagamento. Quando o card atinge aquela data, vence.

No exemplo, um card na fase de informações pendentes com SLA de um dia, se não recebe a informação no prazo, é movido automaticamente. A condição delimita onde: sem condição, a automação de "card atrasado" dispararia em qualquer fase atrasada. Adicionando a condição "fase atual é informações pendentes", ela só age ali.

 

 

O card vencido abre um caminho útil: na fase de aprovado aguardando pagamento, se o card atinge a data de pagamento e o pagamento não foi flagado, provavelmente não foi pago. A automação pode disparar um e-mail avisando o responsável de que aquele card precisa de ação.

 

5. Atividade recorrente aciona lembretes por data

O quinto gatilho é a atividade recorrente: a automação roda numa frequência definida, a cada meia hora, hora, dia, semana ou mês. É o gatilho dos follow-ups e lembretes que precisam se repetir até algo ser resolvido.

Aqui há uma característica importante que vale destacar: por segurança, nem todo gatilho habilita toda ação. A atividade recorrente não permite enviar template de e-mail diretamente, justamente para evitar disparo excessivo e spam. A arquitetura para um lembrete recorrente por e-mail é em duas partes, e está detalhada nas dúvidas frequentes abaixo.

 

 

Nem sempre todos os gatilhos habilitam todas as ações. Card recorrente não envia e-mail direto; card que sai de fase não envia tarefa. Quando um botão de ação aparece desabilitado, é uma trava de segurança e de lógica, não um defeito.

 

Como acompanhar o que a automação fez

Duas camadas de visibilidade sustentam tudo acima.

Dentro do card, a aba de atividades registra tudo o que aconteceu: automação, ação manual, qualquer mudança. Um recurso mais recente é a linha do tempo, uma visão mais didática do histórico: como regra geral, o que está acima da linha são ações automatizadas, o que está abaixo são ações manuais. A linha do tempo também mostra quanto tempo o card passou em cada fase.

No nível da automação, o menu de logs mostra o registro de todas as automações do pipe, e dá para filtrar por uma automação específica e ver se ela executou com sucesso.

 

Um ponto que confunde muita gente: o log considera o gatilho, não a ação. Se o evento aconteceu mas a condição não foi atendida, a automação consta como executada, porque ela foi engatilhada, mesmo que a ação não tenha ocorrido. "Executada com sucesso" significa que a automação disparou, não necessariamente que moveu o card ou mandou o e-mail.

 

Dúvidas frequentes sobre automação

 

O histórico do card registra tudo, não só automações?

Sim. A aba de atividades guarda o registro completo do card: automações, ações manuais, atualizações de campo, mudanças de fase. Pela linha do tempo dá para separar visualmente o que foi automático do que foi manual e ver o tempo gasto em cada fase.

 

Como leio o fluxograma das etapas da automação?

Abra o card, vá em atividades e clique em ver linha do tempo. Como regra geral, tudo acima da linha central é ação automatizada, tudo abaixo é ação manual. Assim você reconstrói, passo a passo, o que a plataforma fez sozinha e o que uma pessoa executou, com a duração de cada fase.

 

Como faço um e-mail recorrente, que dispara todo dia até a pessoa concluir?

Em duas partes, porque a atividade recorrente não envia e-mail diretamente, por proteção contra spam. Primeiro, uma automação recorrente (todos os dias, por exemplo) move o card para uma fase de cobrança, com uma condição: enquanto um campo ou botão de "resolvido" não estiver marcado, o card continua voltando para essa fase. Segundo, uma automação de "card entrou na fase" dispara o template de e-mail. O card circula por aquela fase e o e-mail sai a cada ciclo, até você marcar o botão que interrompe a cobrança, momento em que o card pode seguir para outra fase.

 

Dá para excluir uma automação sem risco?

A exclusão pede confirmação, porque dependendo da automação isso impacta o restante do processo. É uma camada de segurança adicional. Para testar variações, o caminho mais seguro é duplicar a automação: a cópia nasce desativada, e você edita e renomeia sem afetar a original.

 

Antes de avançar, confirme que você entende:

  • Que automação vem depois do processo bem estruturado, com os campos do tipo certo
  • O modelo único: todo evento dispara, toda condição filtra, toda ação executa
  • Os cinco gatilhos: card criado move, card criado envia e-mail, entrada em fase atribui responsável, alerta escalona card parado, atividade recorrente lembra por data
  • A diferença entre atrasado (tempo na fase), expirado (tempo no pipe) e vencido (campo de data)
  • Que o log considera o gatilho, não a ação, e que nem todo gatilho habilita toda ação