🔐 Disponível para clientes com o add-on de Custom Integrations
👤 Para quem já tem flows ativos e quer escalar sem comprometer estabilidade, para quem processa alto volume de dados e arquivos pesados
🎯 Nível: intermediário
Quando um flow cresce, um problema silencioso aparece: ele tenta fazer tudo em uma única execução. Lê um arquivo grande, gera um PDF, chama três APIs e ainda atualiza vários cards, tudo dentro do mesmo processo, disputando o mesmo orçamento de tempo e memória. Quanto mais um flow acumula, mais perto ele chega do timeout e do limite de memória, e maior a chance de quebrar no meio do caminho, depois de já ter feito metade do trabalho.
Sub-flows resolvem isso por modularização. Em vez de concentrar todo o peso em um flow monolítico, você quebra as partes mais pesadas ou mais complexas em flows dedicados e os chama a partir do flow principal. Cada sub-flow roda no seu próprio contexto de execução, com um conjunto novo de limites de tempo e memória. O resultado é um processo mais estável, mais fácil de depurar e, como efeito colateral bem-vindo, reutilizável entre diferentes integrações.
📖 O que você vai entender aqui:
O que é um sub-flow
Um sub-flow é um flow configurado especificamente para ser chamado por outros flows, não para rodar de forma independente. Ele tem um trigger do tipo Callable Flow, o que sinaliza ao Pipefy Integrations Hub que esse flow é um componente reutilizável, não um ponto de entrada autônomo.
Do ponto de vista do flow principal, a peça Sub-flow funciona como qualquer outra action: você a insere no flow, seleciona qual flow chamável quer executar e define como quer que a execução aconteça. A diferença que importa está nos bastidores, quando o sub-flow é disparado, ele executa em um contexto separado, com seus próprios limites de timeout e memória zerados. É exatamente isso que permite tirar uma operação pesada de cima do flow principal: ela deixa de consumir o orçamento de quem a chamou e passa a ter o seu.
Um sub-flow precisa estar publicado e ativo para aparecer como opção de seleção. Flows em rascunho ou inativos não ficam disponíveis. Isso é uma proteção: garante que só lógica validada seja reutilizada.
Síncrono ou assíncrono: a decisão que muda tudo
Quando você chama um sub-flow, precisa decidir se o flow principal vai esperar a conclusão ou continuar em paralelo. Essa escolha define o comportamento do processo inteiro e não deve ser feita por acaso.
- Execução síncrona O flow principal pausa e aguarda o sub-flow terminar antes de avançar. Use quando o resultado do sub-flow for necessário para os passos seguintes: uma validação que precisa retornar aprovado ou reprovado, uma consulta externa que alimenta uma decisão, uma criação de registro cujo ID será usado depois. Atenção a um ponto de estabilidade: na execução síncrona, o tempo do sub-flow conta para a percepção de duração do processo como um todo. Se você só precisa isolar a memória de uma tarefa pesada, mas não depende do retorno dela, prefira a forma assíncrona.
- Execução assíncrona O flow principal dispara o sub-flow e segue imediatamente sem esperar. Use quando o sub-flow executa uma tarefa paralela que não bloqueia o caminho principal: enviar uma notificação, registrar um log, processar um arquivo pesado em segundo plano ou gerar um documento que será consumido depois. Aqui o ganho de modularização é máximo, você tira a carga pesada do flow principal e ainda evita que ele fique travado esperando uma operação longa.
Escolher assíncrono quando o flow principal depende do resultado do sub-flow é o erro mais comum. O flow avança antes do dado estar disponível e o processo quebra em silêncio. Se há dependência de dado, a execução deve ser síncrona.
Caso de uso: isolar um processamento pesado
Um cenário frequente em operações que lidam com volume: um flow recebe uma planilha grande, precisa tratar os dados, gerar um PDF e só então criar os registros no Pipefy. Feito tudo em um único flow, esse processo tende a estourar, ora bate no timeout, ora estoura memória ao manipular o arquivo, e quando falha já consumiu o trabalho feito até ali.
Com sub-flows, a etapa pesada, o tratamento do arquivo e a geração do PDF, vira um flow dedicado com trigger Callable Flow. O flow principal valida os dados de entrada, chama esse sub-flow e deixa a parte custosa rodar com seu próprio orçamento de tempo e memória. Se essa etapa também é necessária em outros flows que lidam com arquivos, ela já está pronta para ser reutilizada, um único lugar para manter e ajustar.
O resultado prático: menos risco de timeout e out-of-memory no flow principal, falhas contidas em um escopo menor e mais fácil de depurar, e rastreabilidade centralizada da execução dessa etapa.
Como identificar lógica candidata a sub-flow
Nem todo trecho merece virar sub-flow. Transformar tudo em componentes cria complexidade desnecessária quando não há ganho real de isolamento ou reuso. O critério é direto:
O flow tem chance de rodar por mais de 5 minutos, isolar a etapa longa em um sub-flow dá a ela limites próprios.
Há manipulação de arquivos pesados ou geração de documentos, operações que são a principal causa de erros de memória e merecem rodar em contexto separado.
A mesma sequência de ações aparece em dois ou mais flows e você não quer mantê-la em vários lugares.
Uma parte complexa de um flow extenso atrapalha a leitura e a manutenção, e isolá-la deixa o todo mais simples de depurar.
Se a lógica é curta, leve, usada por um único flow e sem perspectiva de reuso, mantê-la no flow principal é mais simples e igualmente válida.
Sub-flows também funcionam como ferramenta de governança: ao centralizar uma lógica crítica ou uma etapa pesada em um sub-flow controlado por um responsável específico, você evita que cada time reimplemente o mesmo comportamento com variações não intencionais, e garante que o tratamento de recursos siga um padrão validado.
Checklist de conclusão
☐ O que diferencia um sub-flow de um flow comum, e por que ele isola tempo e memória
☐ Quando usar execução síncrona e quando usar assíncrona
☐ Como identificar etapas pesadas ou longas que devem virar sub-flow na sua operação
☐ Por que um sub-flow precisa estar publicado e ativo para ser chamado
