👤 Para quem já opera pipes e administra processos
🔐 Recursos conforme o plano e as permissões da empresa
🎯 Para quem quer conectar demandas, definir acessos e facilitar aprovações
Uma solicitação pode envolver mais de uma equipe, gerar tarefas em outro processo e depender da aprovação de alguém que acompanha vários pipes. Essas situações orientaram o treinamento “Pergunte ao time Pipefy: automações e permissões em foco”, realizado pela Pipefy Academy em 28 de outubro de 2026. Felipe Borer conduziu as demonstrações usando um processo de solicitações e outro de tarefas dos analistas.
Ao terminar a leitura, você vai saber como identificar o pipe de origem de uma regra, distinguir gatilho e condição, revisar acessos e avaliar uma visão centralizada para solicitantes e aprovadores.
Para participar das próximas sessões e trazer suas dúvidas, confira a agenda de treinamentos ao vivo da Pipefy Academy.
📖 O que você vai entender aqui:
Conecte a solicitação às tarefas de outro pipe
Uma das dúvidas levantadas na Community era em qual processo configurar a regra quando uma solicitação precisa gerar trabalho em outro pipe. O raciocínio apresentado por Felipe foi começar pelo acontecimento que inicia a ação.
No exemplo, Solicitações era o processo principal e Tarefas dos analistas recebia o trabalho relacionado. Se a criação da solicitação deve gerar uma tarefa, o evento acontece no pipe de Solicitações. A ação cria o card conectado no pipe de tarefas. Se o evento que você acompanha é a criação da tarefa, a origem da regra passa a ser o pipe em que essa tarefa nasce.
Essa distinção ajuda a desenhar a relação entre a demanda principal, chamada de card pai, e o trabalho derivado, chamado de card filho. Antes de configurar, defina onde o evento acontece, qual card será criado ou atualizado e quais informações devem seguir com ele.
Para criar cards conectados, os pipes precisam estar conectados previamente. Confira também a correspondência dos campos e se os dados obrigatórios do destino estarão disponíveis no momento da criação.
Descreva a regra em uma frase antes de abrir a configuração. Por exemplo: “Quando uma solicitação for criada, criar a tarefa conectada para o analista”. Depois, confira se origem, destino e dados transferidos representam essa intenção.
- Saiba mais: consulte como criar automações para conectar cards.
Mova cards quando a condição do processo for atendida
A pergunta seguinte tratava de movimentar cards automaticamente conforme uma informação da triagem. Na demonstração, a classificação da solicitação determinava o caminho. O exemplo usou o valor “Bug” para ilustrar uma movimentação para a fase concluída.
Esse destino serviu à demonstração. Ao adaptar o raciocínio, escolha a fase que representa a próxima atividade ou o encerramento real do seu processo.
Há três decisões nessa regra. O gatilho é a atualização do campo de classificação. A condição verifica se o valor corresponde à categoria desejada. A ação move o card para a fase definida. Apenas acompanhar a atualização do campo não distingue as respostas possíveis.
Outra pergunta abordou onde definir os destinos permitidos a partir de uma fase. As opções de movimentação e os campos obrigatórios também precisam refletir o caminho que o time combinou para a demanda.
Para aprofundar essa lógica, leia Como as automações funcionam no Pipefy. Para executar a configuração, consulte como criar uma automação para mover cards e os controles de movimentação entre fases.
Quer praticar com um fluxo completo? No curso Faça o trabalho rodar sozinho, você trabalha gatilho, condição e ação em exercícios de automação.
Acrescente etiquetas preservando as existentes
Uma solicitação pode carregar mais de uma classificação. A dúvida da Community era como adicionar uma nova etiqueta sem remover as que já estavam no card.
Na sessão, Felipe apresentou uma alternativa em Integrações Pipefy com uma operação de adição. O critério central é distinguir acrescentar um item de substituir o conteúdo do campo. Se a intenção é manter as classificações anteriores, a operação precisa preservar essa lista.
A documentação da API confirma atualizações incrementais de campos com a operação ADD em updateFieldsValues. Para etiquetas, o valor usa o identificador de uma etiqueta existente. Essa referência confirma a possibilidade de adição incremental; a configuração da integração deve considerar os identificadores do card, do campo e da etiqueta no seu processo.
Antes de aplicar ao fluxo real, teste em um card que já tenha etiquetas. Confira se a nova classificação foi acrescentada e se as anteriores permaneceram.
- Saiba mais: veja a documentação de atualizações incrementais de campos, em inglês. Para o uso de etiquetas nas automações nativas, consulte como adicionar etiquetas automaticamente.
Revise quem precisa acessar cada demanda
Participar da empresa no Pipefy e ter acesso a um pipe são situações diferentes. Na sessão, a pergunta “Por que não consigo acessar meus pipes?” levou à revisão da privacidade do processo e dos membros convidados.
Um pipe privado exige verificar o acesso daquela pessoa ao processo. Para o time que trabalha nas demandas, a escolha do papel também deve considerar quais cards cada pessoa precisa consultar ou editar.
A permissão de visão restrita permite criar cards e visualizar ou editar aqueles que a pessoa criou ou pelos quais é responsável. Isso oferece um critério para situações em que um analista acompanha somente suas demandas. A permissão de somente leitura, por sua vez, permite ver todos os cards e comentar, sem editar seu conteúdo.
Na discussão sobre anexos, Felipe orientou começar pelo acesso ao card. Ao revisar um processo com documentos sensíveis, avalie o conjunto de informações que cada perfil precisa consultar e valide a experiência usando esse perfil.
Um filtro aplicado por um administrador não comprova o acesso de outro usuário. No treinamento, o filtro serviu para ilustrar um recorte de cards; a verificação das permissões exige conferir o papel efetivamente concedido.
- Saiba mais: consulte funções e permissões do pipe. A disponibilidade dos níveis de acesso depende do plano contratado.
Organize o acompanhamento com Interfaces
Quem abre uma solicitação e quem trabalha no processo podem precisar de visões diferentes. Para o solicitante, pode bastar acompanhar o andamento do pedido. Para um diretor, o objetivo pode ser encontrar as aprovações que aguardam sua decisão em vários pipes.
Felipe demonstrou Interfaces como um caminho para organizar essas informações. A página pode reunir dados de processos diferentes, com condições para definir os registros exibidos e detalhes personalizados para cada demanda.
Ao adaptar o exemplo, defina quem acessa a Interface, quais registros essa pessoa precisa ver e quais campos ela pode consultar ou editar. A documentação apresenta o filtro de usuário atual para personalizar a visibilidade por pessoa. Um filtro fixo com o nome de um aprovador, usado para ilustrar um cenário, tem uma finalidade diferente de uma página que muda conforme quem a acessa.
Comece pela decisão que a pessoa precisa tomar. Para uma aprovação, identificação do pedido, contexto e campo de decisão podem orientar a visão. Valide esse recorte com quem vai usar a página.
- Saiba mais: consulte primeiros passos com Interfaces.
Perguntas da audiência, respondidas ao vivo
Além das dúvidas levantadas previamente na Community, duas perguntas trouxeram situações da operação de uma participante.
Como definir o título quando a informação vem de campos diferentes?
O caso reunia reembolso e pagamento de terceiros no mesmo pipe. Em um caminho, a identificação vinha do colaborador; no outro, do fornecedor. Selecionar apenas um desses campos para o título deixava o outro cenário sem a identificação esperada.
Felipe propôs centralizar o resultado em um campo auxiliar e usar esse campo como referência do título. No padrão de nomenclatura, ele pode ser identificado como [Auxiliar] Título. A regra deve preencher esse campo com a informação correspondente ao tipo da solicitação.
Na sessão, também foi sugerido combinar os dois valores quando apenas um está preenchido. Antes de adotar essa variação, teste os dois tipos de pedido e defina o tratamento para ambos os campos preenchidos ou vazios. A solução foi proposta ao vivo e ficou para teste no processo da participante.
- Saiba mais: veja a configuração de título do card nas preferências do pipe. A troca do campo de referência é aplicada aos cards novos.
Como centralizar aprovações que estão em vários pipes?
A participante relatou que o CEO e os gestores recebiam comunicações, mas precisavam abrir os pipes para localizar aprovações. Felipe sugeriu revisar o destinatário configurado e apresentou uma Interface para reunir as demandas de interesse dos aprovadores.
O encaminhamento foi criar uma visão de aprovações, selecionar os processos envolvidos e definir o recorte de registros de cada pessoa. A página pode oferecer acesso aos detalhes necessários para a decisão.
O relato sobre itens ausentes em Tarefas e solicitações não teve uma causa confirmada durante a sessão. Para um caso semelhante, reúna um exemplo de card, o destinatário esperado e a regra usada para solicitar a ação. Isso permite investigar o cenário enquanto você avalia se uma Interface atende à necessidade de centralização.
Antes de avançar, confirme que você entende:
☐ Em qual pipe acontece o evento que inicia cada regra.
☐ Qual condição distingue os cards que devem seguir para cada destino.
☐ A diferença entre filtrar uma visualização e conceder uma permissão.
☐ Como validar o título e a visão de aprovação com exemplos do seu processo.
Pronto para aplicar os aprendizados? Escolha uma regra do seu processo, defina o resultado esperado e continue com Como as automações funcionam no Pipefy para organizar gatilho, condição e ação antes de configurar.
Qual dessas situações aparece na sua operação? Compartilhe nos comentários o contexto e o resultado que você quer alcançar para continuar a conversa com a Community.
