Automações entre pipes: conectando processos

Compras aprova o pedido, mas o financeiro só fica sabendo quando alguém lembra de avisar. TI recebe a solicitação de acesso, mas o card de onboarding continua na fase errada porque ninguém atualizou. Dois processos que deveriam se comunicar ficam dependendo de intervenção manual para trocar informação.

Automações entre pipes resolvem isso. Ao final deste artigo, você vai saber quando conectar dois pipes faz sentido, como o modelo pai-filho funciona na prática e quais decisões de configuração determinam se a orquestração vai funcionar ou vai gerar retrabalho.

📖  O que você vai aprender aqui:

Quando conectar pipes faz sentido (e quando não faz)

Conectar dois pipes é a resposta certa quando o processo muda de escopo ou de time responsável. Um pedido de compra aprovado que precisa virar uma despesa registrada no financeiro. Um candidato contratado no pipe de recrutamento que precisa iniciar o onboarding em outro pipe. Um chamado de TI resolvido que precisa notificar o processo de gestão de ativos.

O sinal de que você precisa de pipes conectados é claro: uma equipe precisa agir sobre informações que nasceram em outro processo, e hoje isso depende de alguém copiar, colar ou avisar manualmente.

Conectar pipes não faz sentido quando o processo é o mesmo, apenas com mais fases. Se um único time acompanha o fluxo do início ao fim e as etapas têm continuidade natural, o caminho certo é adicionar fases ao pipe existente. A conexão introduz complexidade de configuração e manutenção que não se justifica quando um pipe único resolve.

O modelo pai-filho: como funciona

Quando dois pipes estão conectados, um card em um pipe pode criar automaticamente um card no outro. O card que dispara a criação é chamado de pai. O card criado no segundo pipe é o filho.

O card filho não é uma cópia do pai. Ele é uma nova demanda, em outro processo, com seu próprio ciclo de vida. O que os une é o vínculo de conexão: o pai sabe que tem filhos, e os filhos sabem de qual pai vieram.

Três comportamentos essenciais antes de configurar:

• Campos transferidos são apenas os mapeados na automação

A conexão entre os pipes não transfere campos automaticamente. Você define, campo a campo, o que passa do card pai para o filho no momento da criação. Campos não mapeados chegam em branco no filho.

• O card filho não acompanha mudanças no pai

Depois que o filho é criado, ele tem vida própria. Se o pai avança ou volta de fase, o filho não é atualizado a menos que haja uma automação explícita configurada para isso.

• O gatilho "todos os filhos em uma fase" exige 100% de conclusão

O evento que dispara quando todos os cards conectados chegam a uma fase exige exatamente isso: todos os filhos naquela fase. Se dois de três filhos chegarem, o gatilho não dispara. Cards filhos deletados deixam de contar para esse cálculo.

Exemplo: recrutamento que dispara onboarding

Um time de RH tem dois pipes: Recrutamento e Onboarding. Quando um candidato é aprovado, o onboarding precisa começar em um pipe separado, com outro time e outro fluxo de trabalho.

A automação configurada: quando um card entrar na fase "Aprovado" no pipe de Recrutamento, criar um card conectado no pipe de Onboarding. Campos mapeados: nome do colaborador, data de início, área e gestor responsável.

O que acontece: o card filho é criado no pipe de Onboarding com as informações essenciais já preenchidas. O time responsável pelo onboarding recebe a demanda sem precisar que ninguém avise. O card pai mantém o vínculo com o filho, permitindo acompanhar o status do onboarding sem sair do pipe de Recrutamento.

O que não acontece automaticamente: se o card pai voltar para "Documentação Pendente" porque faltou um documento, o card filho em Onboarding não para. Para pausar ou atualizar o filho, é necessário configurar uma segunda automação explícita.

Boas práticas para dependência entre pipes

Mapeie os campos antes de começar

Abra os dois pipes lado a lado e decida quais campos do pai precisam chegar ao filho antes de configurar qualquer automação. Campos em branco no card filho geram retrabalho manual, que é exatamente o que a automação deveria eliminar.

Evite loops entre pipes

Se o pipe filho tem uma automação que, ao criar um card, dispara algo no pipe pai, que por sua vez cria outro filho, você tem um ciclo. Use condições ou campos de controle para garantir que automações entre pipes só disparam uma vez por demanda.

• Estratégia recomendada: crie um campo de seleção no card filho com o valor "originado por automação" e use isso como condição negativa nas automações do pipe pai.
• Alternativa: adicione uma condição na automação que verifica se o card filho já existe antes de criar outro.

Teste com cards reais antes de ativar

Crie um card de teste no pipe pai, acione a fase gatilho e verifique se o card filho foi criado com os campos corretos. Erros de mapeamento só aparecem na prática e, em processos de alto volume, podem gerar dezenas de cards com dados incorretos antes de serem percebidos.

Documente os mapeamentos de campo

Um pipe pode estar conectado a múltiplos outros pipes ao mesmo tempo. Quanto mais conexões e automações cruzadas, maior a complexidade de manutenção. Qualquer mudança em um campo mapeado pode quebrar silenciosamente o fluxo. Registre quais campos de quais pipes estão conectados e por qual automação.

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

☐ Quando faz sentido conectar dois pipes versus adicionar fases ao pipe atual

☐ A diferença entre o card pai e o card filho e o que os conecta

☐ Que campos transferidos precisam ser mapeados explicitamente na automação

☐ Que o card filho não atualiza automaticamente quando o pai muda de fase

☐ A ordem correta: configurar a conexão antes de criar a automação