Etapas do Workflow
- O que são etapas e como elas formam o corpo de um workflow
- Como adicionar, configurar e gerenciar etapas usando a seção Etapas
- Como depurar etapas individualmente ou todas de uma vez
- Como funciona a ordem de execução das etapas
Etapas são as ações que seu workflow executa após o trigger disparar. Cada etapa representa uma única operação -- como enviar uma mensagem, atualizar um registro ou chamar um serviço externo. As etapas executam em sequência de cima para baixo, o que significa que cada etapa é concluída antes que a próxima comece.
Para um guia detalhado campo a campo de cada tipo de etapa disponível, veja a Referência de Ações.
Adicionando etapas
Para adicionar uma etapa ao seu workflow:
- Abra o formulário de criação ou edição do workflow.
- Role até a seção Etapas.
- Clique no botão Add step (Adicionar etapa).
- Uma nova etapa será adicionada à lista. Configure-a selecionando o tipo de etapa e preenchendo seus parâmetros.
- Repita para adicionar quantas etapas seu workflow necessitar.
Cada etapa adicionada aparece na lista na ordem em que será executada.
Configurando uma etapa
Quando você adiciona uma etapa, precisará configurá-la com base na ação que deseja executar. Cada tipo de etapa tem seu próprio conjunto de campos e opções. Por exemplo:
- Uma etapa de "enviar mensagem" pode exigir que você especifique o texto da mensagem e o destinatário
- Uma etapa de "atualizar registro" pode exigir que você selecione qual campo alterar e qual valor definir
- Uma etapa de "chamar webhook" pode exigir que você forneça uma URL externa e o payload de dados
Os campos de etapa com CEL recebem um valor na forma de objeto {expr: "..."}, em que a expressão é avaliada no contexto de execução atual quando o workflow executa. Por exemplo, {"expr": "contact.name"} em um campo de mensagem resolve para o nome do contato. Para campos com muito texto, você também pode usar a função tpl(), que preenche placeholders de chave única {key}: tpl('Hello {name}', {name: contact.name}). A sintaxe de chaves duplas {{ }} não se aplica aqui — ela existe apenas nos templates de mensagem do WhatsApp. Veja Entradas do workflow para as variáveis que cada trigger expõe.
Depurando etapas
A seção Etapas fornece ferramentas de depuração integradas para ajudar a testar seu workflow antes de ativá-lo:
- Start Debug (Iniciar Debug) -- Clique neste botão para executar todas as etapas pelo painel de depuração. Ele executa o loop de ações real -- o mesmo que o executor ao vivo usa -- então a ação de cada etapa realmente executa: solicitações HTTP, gravações de dados e mensagens de saída reais são disparadas. Não é uma simulação nem um sandbox; as únicas diferenças em relação a uma execução em produção são que ele é invocado manualmente, usa um contato de depuração sintético, retorna o arena CEL e os logs de cada etapa para inspeção, e não é registrado no histórico de execução (o ícone de relógio do histórico) -- revise seus resultados no painel de depuração. Trate seus efeitos colaterais como reais.
- Para isolar um problema em uma parte do workflow, abra o menu de uma etapa e escolha Debug para executar apenas aquela etapa.
A depuração é especialmente útil quando seu workflow inclui múltiplas etapas que dependem umas das outras, pois você pode inspecionar a saída de cada etapa e confirmar que os dados estão fluindo corretamente.
Ao inspecionar a saída de uma etapa, o AutoTalk também pode mostrar um objeto aninhado executionContext com metadados do executor como status, timestamps e valores sanitizados safeError ou safeResult. Use step(N).executionContext quando você quiser fazer ramificação com base em como uma etapa anterior executou, em vez de depender de campos específicos da ação como step(N).status.
Limpando todas as etapas
Se você quiser começar do zero, clique no botão Clear all items (Limpar todos os itens). Isso remove todas as etapas do workflow de uma vez. Use com cuidado, pois não pode ser desfeito.
Ordem de execução das etapas
As etapas executam de cima para baixo na ordem exata em que aparecem na seção Etapas. Pontos importantes a ter em mente:
- Execução sequencial: Cada etapa deve ser concluída antes que a próxima comece.
- Fluxo de dados: A saída de uma etapa pode ser referenciada por etapas subsequentes. Campos específicos da ação ficam em
step(N), enquanto metadados compartilhados do executor ficam emstep(N).executionContext. - Tratamento de falhas: Uma etapa que falha não para o workflow -- as etapas subsequentes ainda executam. O motor marca a etapa que falhou (seu
executionContext.statusse torna"failed"com umexecutionContext.safeErrorsanitizado), mas não aborta a execução, então qualquer etapa posterior que dependa dela deve se proteger, ex.:condition={"expr": "get(step(N), 'executionContext.status') == 'failed'"}ou usarstep_error(N)/step_ok(N). (Apenas o limite de chamadas de ação por execução interrompe uma execução por completo; uma expressão de condição malformada faz com que aquela etapa seja ignorada com o motivocel_eval_error, e a execução continua.) O log de execução ainda registra metadados sanitizados da etapa, incluindoexecutionContext.safeError, para que você possa ver qual etapa falhou e por quê sem expor dados internos brutos na interface.
Construa seu workflow incrementalmente. Adicione uma etapa de cada vez, use Start Debug (Iniciar Debug) para testar após cada adição, e confirme que funciona antes de adicionar a próxima etapa.