Bloco Workflow

O que ele faz

Use um bloco Workflow quando quiser chamar um workflow filho como parte de um fluxo maior. O bloco executa a última versão em deploy desse workflow, espera que ela termine e então segue com o workflow pai.

Como configurar

  1. Escolha um workflow no dropdown (auto-referências são bloqueadas para evitar loops).
  2. Mapeie as entradas: se o workflow filho tiver um trigger Input Form, você verá cada campo e poderá conectar variáveis do pai. Os valores mapeados são o que o filho recebe.
  1. Saídas: depois que o filho termina, o bloco expõe:
    • result – a resposta final do workflow filho
    • success – se ele executou sem erros
    • error – mensagem quando a execução falha
    • childWorkflowName – o nome do workflow filho (string)
    • childWorkflowId – o ID do workflow filho (string)

Selo de status de deploy

O bloco Workflow exibe um selo de status de deploy para você acompanhar se o workflow filho está pronto para executar:

  • Deployed – O workflow filho teve deploy e está pronto para uso. O bloco vai executar a versão atualmente em deploy.
  • Undeployed – O workflow filho nunca teve deploy. Você precisa fazer o deploy antes que o bloco Workflow consiga executá-lo.
  • Redeploy – Foram detectadas mudanças no workflow filho desde o último deploy. Clique no selo para refazer o deploy do workflow filho com as mudanças mais recentes.

O bloco Workflow sempre executa a versão em deploy mais recente do workflow filho, não a versão do editor. Refaça o deploy depois de fazer mudanças para garantir que o bloco use a lógica mais recente.

Notas de execução

  • Workflows filhos executam no mesmo contexto de workspace, então variáveis de ambiente e ferramentas são mantidas.
  • O bloco usa versionamento de deploy: qualquer execução via API, agendamento, webhook, manual ou Chat chama o snapshot em deploy. Refaça o deploy do filho quando você o alterar.
  • Se o filho falhar, o bloco lança um erro, a menos que você trate isso mais adiante no fluxo.

Mantenha os workflows filhos focados. Fluxos pequenos e reutilizáveis são mais fáceis de combinar sem criar aninhamentos profundos.

Common Questions

Não. O seletor de workflow bloqueia auto-referências para evitar loops infinitos. Além disso, o Studio rastreia a cadeia de chamadas entre execuções aninhadas usando um header interno e impõe uma profundidade máxima de 25 saltos na cadeia. Se o limite for excedido, a execução é rejeitada com um erro 409.
A profundidade máxima da cadeia de chamadas é 25. Isso significa que o workflow A pode chamar B, que chama C, e assim por diante até 25 níveis. Esse limite vale para todas as chamadas em cadeia, não apenas para relações diretas entre pai e filho.
O workflow filho herda o contexto de execução do pai. Se o pai está executando em um contexto de deploy (API, agendamento, webhook), o filho também usa a versão em deploy. Se o pai está executando em modo rascunho (execução manual pelo editor), o filho também usa o estado de rascunho. Isso permite testar workflows aninhados de ponta a ponta antes do deploy.
Use o campo Inputs no bloco Workflow. Se o workflow filho tiver um trigger Input Form, cada campo aparece na configuração do bloco e você pode mapear variáveis do pai para eles. Os valores mapeados ficam disponíveis como start.input no workflow filho.
O bloco retorna um booleano success, o result do workflow filho (a saída da resposta final dele), o nome e o ID do workflow filho e uma mensagem de erro se a execução falhar. Você pode referenciar essas saídas em blocks posteriores usando a sintaxe de tags.
O bloco Workflow lança um erro que se propaga para o workflow pai. Se você precisa tratar falhas com elegância, conecte um caminho de erro do bloco Workflow a um block posterior que processe o erro.
WebhookEvaluator