Skip to main content

O que é clonado quando você duplica um pipe: o que está pronto e o que precisa ser reconfigurado

  • June 25, 2026
  • 0 replies
  • 38 views
vinicius.pereira
Community Manager

👤  Para administradores de pipe que replicam processos entre organizações ou BUs
🔐  Disponível em todos os planos
🎯  Para quem acabou de receber um pipe clonado e precisa entender o que está pronto e o que ainda precisa ser configurado

 

Clonar um pipe é uma das formas mais rápidas de replicar um processo que já funciona para uma nova organização. Mas há uma distinção importante que quem recebe o clone precisa entender: clonar não é duplicar tudo. É duplicar a estrutura.

A diferença fica clara quando o time começa a operar e percebe que automações não disparam, conexões com bases de dados não existem e os membros precisam ser convidados do zero. Não é falha do processo: é o comportamento esperado da clonagem, e saber o que vem junto e o que não vem evita horas de investigação.

Ao terminar, você vai saber exatamente o que checar antes de colocar o pipe clonado em produção.

 

📖  O que você vai aprender aqui:

 

O que vem junto no clone?

A clonagem transfere a estrutura do processo. Tudo que define como o pipe funciona, mas não quem o opera nem os dados que já existem nele.

 

✅ O que é copiado:

  • Fases: todas as fases do pipe original, com seus nomes e configurações.
  • Campos: todos os campos de cada fase e do formulário inicial, incluindo tipo, nome e configurações de obrigatoriedade.
  • Etiquetas: os campos do tipo etiqueta são clonados. As configurações de cada etiqueta (nome, cor) podem variar conforme o plano e a organização de destino. Revise e ajuste após a clonagem se necessário.
  • Campos condicionais: as regras de exibição condicional de campos são clonadas. Atenção: se a condicional referência é um campo de conexão, ela chega em branco no clone.
  • Templates de e-mail: os modelos de e-mail configurados no pipe são transferidos.
  • Automações nativas: as regras de automação criadas diretamente no pipe são clonadas, incluindo seus nomes, incluindo seus nomes, que também recebem o sufixo "(Copy 1)". Há exceções importantes, cobertas na seção sobre automação abaixo.
  • Configurações de SLA: os SLAs configurados no pipe (tempo até expiração) e nas fases (tempo até atraso) são clonados junto com a estrutura.

 

O pipe clonado recebe o sufixo "(Copy 1)" no nome para facilitar a identificação. Renomeie antes de compartilhar com o time para evitar confusão com o pipe original.

 

O que não é transferido e precisa ser reconfigurado?

Tudo que conecta o pipe ao mundo externo (pessoas, sistemas e dados) não é clonado. Esses elementos são específicos de cada organização e precisam ser configurados manualmente no destino.

 

  • Membros e permissões: o pipe clonado chega sem nenhum membro além de quem fez a clonagem. Convide o time e defina os níveis de permissão antes de colocar em operação.
  • Conexões com databases: as bases de dados conectadas ao pipe são clonadas e permanecem conectadas na organização de destino. O que não é transferido é o conteúdo: os registros existentes nas bases de dados não vêm com o clone. As bases chegam vazias e precisam ser "populadas" na nova organização.
  • Integrações via Integration Hub: integrações configuradas pelo Pipefy Integration Hub precisam ser refeitas do zero no pipe clonado. Inclui download e upload dos arquivos de integração e criação das conexões com as credenciais da nova organização.
  • Formulários públicos: o link público do formulário de entrada não é transferido. Se o processo recebe demandas via formulário público, é necessário ativar e compartilhar o novo link no pipe clonado.
  • Cards e histórico: o clone começa sem dados. Cards existentes em pipes conectados não são transferidos. Registros das bases de dados chegam zerados. O histórico de atividades não é clonado. O pipe clonado é uma estrutura limpa, pronta para operar com dados novos.
  • Descrição do pipe: o texto de descrição configurado nas informações do pipe não é transferido. Reescreva a descrição no pipe clonado para contextualizar o time de destino.
  • Interfaces: interfaces configuradas no pipe original não são clonadas e precisam ser criadas novamente no destino.
  • Portal: portais associados ao pipe não são transferidos. Configure o portal novamente na organização de destino.
  • Assistente de IA: configurações do AI Agent vinculadas ao pipe não são clonadas. O assistente precisa ser configurado do zero no pipe clonado.
  • Dashboards e relatórios: painéis e relatórios criados no pipe original não vêm com o clone. Recrie as visualizações necessárias na organização de destino.
  • Configurações do PipeSign: configurações de assinatura digital não são transferidas. Reconfigure o PipeSign no pipe clonado conforme necessário.

 

Antes de convidar o time e iniciar a operação, complete a configuração de conexões e integrações. Um pipe com automações que leem conteúdo das bases de dados vai funcionar estruturalmente, mas as regras que dependem de registros específicos não encontrarão dados até que as bases sejam "populadas" na nova organização.

 

Por que as automações podem chegar quebradas?

Este é o ponto que mais gera confusão após uma clonagem. As automações são copiadas, mas podem não funcionar corretamente no pipe clonado por dois motivos:

 

Automações que dependem de campos de conexão

Se uma automação usa um campo de conexão como gatilho ou como condicional, ela é clonada sem esse campo. A regra existe no pipe, mas a referência ao campo está vazia. Resultado: a automação não dispara quando deveria, ou dispara de forma incorreta.

Como identificar: abra as automações do pipe clonado e procure por regras com campos em branco nas condições ou nas ações. Automações com ações HTTP (chamadas para APIs externas) também são clonadas, mas os tokens de autenticação e credenciais não vêm junto. Reconfigure os tokens antes de ativar essas automações no destino. Qualquer campo vazio onde deveria haver uma referência é um sinal de automação quebrada por dependência de conexão.

 

Automações com campos obrigatórios em conflito

Se um campo do formulário foi marcado como obrigatório depois que a automação foi criada, e o autofill desse campo na regra está em branco, o Pipefy não clona essa automação. Ela simplesmente não aparece no pipe clonado.

Como identificar: compare o número de automações no pipe original com o número no clone. Se houver diferença, uma ou mais regras foram descartadas na clonagem.

 

Antes de clonar um pipe com automações complexas, faça um levantamento de quais automações dependem de campos de conexão. Essas precisarão ser reconfiguradas manualmente no destino.

 

Como funciona a clonagem de pipes conectados?

Se o pipe que você está clonando tem conexões com outros pipes, o comportamento é o seguinte:

Pipes conectados são "clonados" juntos automaticamente: quando dois pipes estão conectados entre si, a clonagem de um arrasta o outro. Você não precisa clonar cada um separadamente.

Automações entre pipes conectados não arrastam pipes: se uma automação refere-se a outro pipe mas os dois não têm uma conexão de campo configurada, apenas o pipe original é clonado. O pipe referenciado na automação não vem junto.

Pipe com conexão consigo mesmo bloqueia a clonagem: se o pipe tem um campo conectado a si mesmo, a clonagem é impedida. Exclua essa conexão, clone o pipe e reconfigure a autoconexão no destino.

 

Verifique se o pipe possui campos condicionais que referenciam campos de conexão antes de iniciar a clonagem. Essas condicionais chegam em branco no clone e precisam ser reconfiguradas manualmente.

 

Checklist pós-clonagem: o que configurar antes de colocar em produção

Use esta lista depois de receber o pipe clonado e antes de iniciar a operação:

 

Estrutura

☐  Renomear o pipe (remover o sufixo "Copy 1" e adaptar para a nova organização)

☐  Revisar fases e campos: confirmar que fazem sentido para o contexto da BU de destino

☐  Verificar campos condicionais: reconfigurar os que chegaram em branco por dependência de conexão

 

Automações

☐  Comparar número de automações no original e no clone: identificar quais foram descartadas

☐  Abrir cada automação e verificar se há campos em branco nas condições ou ações

☐  Reconfigurar automações quebradas por campos de conexão ausentes

☐  Ajustar gatilhos de e-mail, alertas de SLA e regras de movimentação para as regras de negócio da nova organização

 

Conexões e integrações

☐  Verificar se as bases de dados foram clonadas e estão conectadas corretamente

☐  Popular o conteúdo das bases de dados clonadas na organização de destino

☐  Reconfigurar integrações via Integration Hub (download, upload e reconexão com credenciais da nova organização)

☐  Recriar interfaces, portal e dashboards necessários na organização de destino

☐  Configurar AI Agent e PipeSign se o processo utiliza esses recursos

 

Acesso e operação

☐  Convidar membros do time e definir níveis de permissão

☐  Ativar e compartilhar o link do formulário público, se o processo recebe demandas por esse canal

☐  Fazer um teste completo com um card de exemplo antes de comunicar o pipe ao time