👤 Para administradores do pipe
🔐 Disponível para todos os planos
🎯 Para quem quer garantir que cada fase avança pelo responsável certo, no momento certo
Uma dúvida que aparece bastante em processos com múltiplas equipes: como garantir que só o responsável pela fase consegue mover o card? É uma preocupação legítima. Sem um fluxo bem desenhado, qualquer membro pode avançar um card antes da hora, pular etapas ou mover uma demanda que ainda não está pronta para o próximo estágio.
No Pipefy, o controle de movimentação por fase é resolvido pela combinação de quatro mecanismos: botões de ação, funções no pipe, responsável pela fase e campos obrigatórios. Usados em conjunto, eles entregam um fluxo onde cada decisão de avançar é intencional, rastreável e vinculada à pessoa certa.
📖 O que você vai aprender aqui:
Os quatro mecanismos de controle por fase
No Pipefy, controlar quem move um card e em qual condição é uma decisão de arquitetura do processo. Quatro mecanismos trabalham em conjunto para isso:
| Alavanca | O que controla | Observação |
| Botões de ação | Qual ação dispara a movimentação e quem pode acionar | Requer automação vinculada ao botão |
| Função no pipe | O que a pessoa pode fazer em qualquer fase do pipe | Opera globalmente para todas as fases |
| Responsável pela fase | Quem recebe ownership do card ao entrar naquela fase | Define responsabilidade e restringe acionamento de botões |
| Campos obrigatórios por fase | O card não avança enquanto os campos não estiverem preenchidos | Controla movimentação via validação, independente de quem move |
O botão de ação é a alavanca mais poderosa e mais subutilizada. As outras três são camadas que se somam. Um processo bem desenhado usa as quatro em conjunto.
Botões de ação: o que são e o que podem fazer
Um botão de ação é um elemento configurável dentro do card que dispara uma automação específica quando acionado. Ele aparece como um botão visível na interface do card, na fase para a qual foi configurado.
As ações que um botão pode disparar incluem:
- Mover o card para uma fase específica. A ação mais usada para controle de fluxo. O card avança apenas quando alguém aciona o botão, não por arrastar.
- Atualizar um campo no card. Útil para registrar automaticamente data de aprovação, responsável da próxima fase ou status atualizado no momento em que a decisão é tomada.
- Enviar um e-mail ou notificação. Acionar o botão comunica o próximo time sem depender de mensagem manual.
- Criar um card conectado em outro pipe. Quando aprovar no pipe de compras precisa gerar automaticamente um registro no pipe financeiro.
- Distribuir responsável. Atribuir o card ao próximo analista disponível no momento em que a fase avança.
Um único botão pode encadear múltiplas ações ao mesmo tempo. O botão "Aprovar documentação" pode mover o card, atualizar o campo de status, notificar o time de TI e criar o pedido de equipamentos no pipe de TI, tudo em um clique.
O botão de ação é o gatilho visível no card. A automação é o que executa as ações vinculadas. Configure a automação primeiro, defina todas as ações que ela deve executar, e depois associe o botão a ela como evento de disparo.
As três decisões antes de criar um botão
Antes de abrir o editor de automações, vale ter clareza sobre três definições que determinam como o botão vai funcionar. Sem elas, é fácil criar um botão que aparece no lugar errado, para a pessoa errada, disparando a ação errada.
| Decisão | O que define | Exemplo no onboarding |
| Qual ação o botão dispara? | A automação vinculada: mover card, atualizar campo, notificar membro, criar card conectado | Mover card para "Equipamentos solicitados" e atualizar campo Responsável com analista de TI |
| Em qual fase o botão aparece? | A fase onde o botão deve estar visível no card | Aparece apenas na fase "Documentação em análise". Em qualquer outra fase, o botão não existe. |
| Quem pode acionar? | Função do usuário no pipe ou se é o responsável pelo card | Restrito ao responsável pelo card — apenas o analista de RH atribuído à fase vê e aciona. |
Como mapear as três decisões para o onboarding:
Fase "Documentação em análise":
Ação: mover para "Equipamentos solicitados" + atualizar responsável com analista de TI + notificar time de TI.
Fase de aparição: somente em "Documentação em análise".
Quem aciona: responsável pelo card (analista de RH atribuído).
Fase "Aguardando aprovação do gestor":
Ação (botão Aprovar): mover para "Equipamentos solicitados" + registrar campo Decisão = Aprovado.
Ação (botão Reprovar): mover para "Ajuste pendente" + registrar campo Decisão = Reprovado.
Fase de aparição: somente em "Aguardando aprovação do gestor".
Quem aciona: usuários com função de gestor.
Controlando para quais fases o card pode ir
Além do botão de ação, o Pipefy permite configurar diretamente em cada fase quais são os destinos possíveis para movimentação de cards. Por padrão, um card só pode ser movido para a fase seguinte na sequência. Quando você habilita outras fases como destinos possíveis, o botão de movimentação manual passa a oferecer essas opções.
Para configurar os destinos de uma fase, acesse os três pontos ao lado do nome da fase no kanban e selecione Editar "Mover para". No painel que abre, ative ou desative as fases para as quais cards podem ser movidos a partir dali.
Use essa configuração em conjunto com os botões de ação para criar fluxos com ramificações controladas. Exemplo: na fase de aprovação, desabilite o destino padrão (próxima fase) no painel Mover para e configure dois botões: "Aprovar" move para execução, "Reprovar" move para ajuste pendente. O resultado é que toda movimentação passa obrigatoriamente por um dos dois botões, cada um com sua ação vinculada.
Quando uma fase tem o destino restrito a apenas uma fase possível e a movimentação é configurada exclusivamente via botão, membros não-admin perdem a opção de arrastar o card para outras posições no kanban. Isso é intencional: o design do processo controla o fluxo, não o comportamento individual.
Responsável pela fase: ownership que o botão respeita
O responsável pela fase atribui ownership do card automaticamente quando ele entra naquela fase. Combinado com botões de ação restritos ao responsável, cria o controle direto que a maioria dos times busca: o card avança quando a pessoa designada toma a decisão.
O que essa configuração entrega:
- O card chega na fase de aprovação e automaticamente fica atribuído ao gestor responsável
- O botão de ação configurado para "apenas responsável" só aparece para essa pessoa
- O time vê no kanban quem está com cada card sem precisar abrir
Vale saber: a restrição de acionamento precisa estar configurada no próprio botão. O responsável por fase define o ownership, mas é a configuração do botão que determina quem pode acioná-lo.
Campos obrigatórios por fase: ninguém avança sem as informações certas
Campos obrigatórios configurados em uma fase garantem que o card só avança quando aquelas informações estiverem preenchidas. Esse controle vale para qualquer mecanismo de movimentação e para qualquer nível de acesso.
Uso combinado: na fase de aprovação do onboarding, configure o campo "Decisão" (aprovado / reprovado) como obrigatório e o botão "Aprovar e avançar" restrito ao gestor responsável. O gestor precisa registrar a decisão antes de avançar, e ninguém mais consegue avançar sem passar por esse registro.
Campos obrigatórios são por fase, não por formulário inicial. Um campo pode ser opcional na entrada do processo e obrigatório em uma fase específica — útil quando a informação só está disponível depois que o processo avança.
O modelo completo aplicado ao onboarding
Combinando os quatro mecanismos no processo de onboarding de colaboradores:
Fase: Documentação em análise
Responsável: Analista de RH (atribuído automaticamente ao entrar na fase).
Campos obrigatórios: checklist de documentos recebidos.
Botão "Documentação aprovada": move para Equipamentos solicitados, notifica TI. Restrito ao responsável pelo card.
Botão "Solicitar ajuste": move para Ajuste pendente, notifica colaborador. Visível para todos os membros.
Destinos configurados no Mover para: apenas Equipamentos solicitados e Ajuste pendente.
Fase: Aguardando aprovação do gestor
Responsável: Gestor da área (atribuído automaticamente).
Campos obrigatórios: campo Decisão (aprovado / reprovado) + justificativa se reprovado.
Botão "Aprovar": move para Equipamentos solicitados, registra Decisão = Aprovado. Restrito a gestores.
Botão "Reprovar": move para Ajuste pendente, registra Decisão = Reprovado. Restrito a gestores.
Destinos configurados no Mover para: apenas Equipamentos solicitados e Ajuste pendente.
Fase: Acessos em configuração
Responsável: Analista de TI (atribuído automaticamente).
Campos obrigatórios: checklist de acessos configurados.
Botão "Acessos concluídos": move para Concluído, notifica RH. Restrito ao responsável pelo card.
Destinos configurados no Mover para: apenas Concluído.
Como testar se o controle está funcionando
Antes de lançar o processo para o time, teste cada fase com uma conta de membro, não de admin. O que verificar:
- Os botões de ação aparecem apenas nas fases configuradas
- O botão restrito ao responsável não aparece para membros sem essa função
- O card não avança se os campos obrigatórios da fase estiverem em branco
- O painel Mover para só oferece os destinos configurados
- O responsável pela fase é atribuído corretamente quando o card entra nela
Admins têm permissões que membros não têm. O que parece funcionando na conta de configuração pode se comportar de forma diferente para o time operacional. Reserve alguns minutos para testar com o perfil real antes de lançar.
Antes de lançar, confirme:
☐ As três decisões de cada botão estão definidas: ação, fase de aparição e quem aciona
☐ Os destinos possíveis de cada fase crítica estão configurados no Mover para
☐ Campos obrigatórios de cada fase refletem o que o processo precisa antes de avançar
☐ Responsável por fase está atribuído em todas as etapas com ownership definido
☐ O processo foi testado com uma conta de membro
