Como testar um workflow no GoHighLevel antes de publicar para os clientes

Intermediário6 min de leituraAtualizado em 03/08/2026

Publicar um workflow com erros pode gerar disparos indevidos de e-mails, SMS duplicados ou até cobranças automáticas equivocadas nos contatos dos seus clientes. Por isso, testar antes de ativar é uma etapa indispensável no ciclo de desenvolvimento de qualquer automação no GoHighLevel. Este guia explica os recursos de teste disponíveis na plataforma, como usá-los de forma ordenada e o que fazer quando algo não funciona como esperado.

Por que testar um workflow antes de ativar

O GoHighLevel executa workflows em produção assim que o status é alterado para Published. Diferente de algumas plataformas que oferecem um ambiente de staging separado, aqui não existe um "modo sandbox" nativo e completamente isolado — tudo roda na mesma sub-conta. Isso significa que um gatilho mal configurado pode disparar ações reais para contatos reais.

Além disso, workflows complexos costumam ter ramificações condicionais (branches), esperas (wait steps) e integrações com ferramentas externas via webhook. Cada uma dessas camadas aumenta a superfície de falha. Testar sistematicamente reduz retrabalho e protege a reputação do domínio de envio do seu cliente.

Atenção: este tutorial foi produzido por um site independente de conteúdo. Não somos afiliados, revendedores ou representantes oficiais da HighLevel Inc.

Preparando o ambiente de teste

Antes de executar qualquer simulação, organize o ambiente para que os disparos não atinjam contatos reais.

  1. Crie um contato de teste dedicado. Acesse Contacts > Add Contact e cadastre um e-mail e número de telefone que você controla (pode ser um endereço Gmail pessoal e um número de celular de teste). Marque esse contato com uma tag como teste-workflow para identificá-lo facilmente.
  2. Desative integrações externas temporariamente. Se o workflow envia dados para um CRM externo ou dispara um webhook de cobrança, considere apontar esse webhook para um serviço como o Webhook.site durante os testes, em vez do endpoint real.
  3. Duplique o workflow antes de editar. Em Automation > Workflows, clique nos três pontos ao lado do workflow e selecione Duplicate. Trabalhe sempre na cópia durante o desenvolvimento; o original permanece intocado.
  4. Mantenha o status como Draft. Enquanto o workflow estiver em Draft, ele não dispara automaticamente para ninguém — apenas execuções manuais funcionam.

Como usar o recurso de teste interno (Test Workflow)

O GoHighLevel possui uma funcionalidade nativa para simular a execução de um workflow a partir de um contato específico, sem precisar acionar o gatilho real.

  1. Abra o workflow em modo de edição.
  2. No canto superior direito, localize o botão Test Workflow (o nome pode variar dependendo da versão da interface — em algumas contas aparece como Test ou ícone de "play" com raio).
  3. Clique no botão. Uma janela será exibida pedindo para você buscar um contato.
  4. Digite o nome ou e-mail do contato de teste criado anteriormente e selecione-o.
  5. Clique em Run Test. O sistema irá executar o workflow usando aquele contato como entrada.
  6. Acompanhe a execução em tempo real na aba Execution Logs, acessível dentro do próprio workflow ou em Automation > Workflows > [nome do workflow] > History.

Interpretando o Execution Log

Cada passo executado aparece no log com um status: Completed, Skipped ou Failed.

  • Completed significa que a ação foi realizada com sucesso.
  • Skipped indica que uma condição (branch) não foi atendida e o step foi ignorado — isso é comportamento esperado em ramificações.
  • Failed aponta um erro real: credencial inválida, campo obrigatório ausente, limite de API atingido, entre outros. Clique no step com falha para ver a mensagem de erro detalhada.

Testando gatilhos específicos manualmente

Alguns gatilhos (triggers) não podem ser simulados pelo botão Test Workflow — por exemplo, gatilhos baseados em formulários, páginas de funil ou eventos de agendamento. Nesses casos, siga o processo manual:

  1. Formulários e surveys: abra o formulário publicado em uma aba anônima do navegador, preencha com os dados do contato de teste e envie. Depois volte ao log do workflow para confirmar se o disparo ocorreu.
  2. Funis (Funnels/Websites): acesse a URL da página de captura, realize a ação esperada (opt-in, compra de teste com produto de R$ 0,00 se aplicável) e monitore o log.
  3. Agendamentos (Appointments): crie um agendamento manualmente pelo calendário usando o contato de teste e verifique se o trigger Appointment Status Changed foi acionado corretamente.
  4. Webhooks de entrada: use ferramentas como Postman ou o próprio Webhook.site para enviar um payload de exemplo ao endpoint do workflow e validar o mapeamento de campos.

Se o seu plano não inclui determinado tipo de gatilho ou ação, a funcionalidade simplesmente não estará disponível na interface. Os recursos disponíveis variam conforme o plano contratado junto ao seu provedor de sub-conta.

Erros comuns e como resolver

Esta seção reúne os problemas mais frequentes encontrados ao testar workflows no GoHighLevel.

O workflow não dispara após o teste manual

  • Verifique se o status do workflow está em Draft — em Draft, apenas testes manuais funcionam; o gatilho automático não opera.
  • Confirme se o contato de teste possui todos os campos exigidos pelo filtro do trigger (ex.: tag específica, pipeline stage).

Steps de e-mail aparecem como "Failed"

  • Geralmente indica que o domínio de envio não está verificado ou que o endereço de remetente não foi configurado em Settings > Email Services.
  • Verifique também se o contato de teste tem um endereço de e-mail válido.

SMS não é enviado durante o teste

  • Confirme se o número de telefone do contato de teste está no formato internacional (ex.: +5511999999999).
  • Verifique se o número Twilio ou LC Phone da sub-conta está ativo e com saldo/crédito suficiente.

Branches condicionais sempre caem no mesmo caminho

  • Revise as condições do branch. Uma causa comum é usar o operador is em vez de contains para campos de texto livre, o que exige correspondência exata.
  • Certifique-se de que o contato de teste possui os valores de campo corretos para acionar o branch desejado.

O log não aparece após o teste

  • Aguarde alguns segundos e recarregue a página. Em workflows com steps de espera (Wait), o log só avança quando o tempo configurado esgota — reduza o tempo de espera para 1 minuto durante os testes.
  • Se o log continuar vazio, verifique se há outro workflow ativo com um filtro de Stop on Response que possa estar interrompendo a execução.

Quando o GoHighLevel pode não ser a melhor escolha

Para equipes que precisam de um ambiente de staging completamente isolado do ambiente de produção — com bases de dados separadas e sem risco zero de contaminação — o GoHighLevel não oferece essa estrutura nativamente. Plataformas como Make (Integromat) ou n8n, usadas em conjunto com ambientes de desenvolvimento separados, podem ser mais adequadas para automações críticas que exigem esse nível de isolamento. Avalie o risco do seu cenário antes de optar por qualquer ferramenta.

Checklist final antes de publicar

  • [ ] Contato de teste executou o workflow sem erros no log
  • [ ] Todos os e-mails e SMS chegaram corretamente nos canais de teste
  • [ ] Branches condicionais foram validados para cada caminho possível
  • [ ] Webhooks externos foram testados com payload real
  • [ ] Tempos de espera foram restaurados para os valores definitivos
  • [ ] O workflow duplicado de teste foi arquivado ou excluído
  • [ ] O workflow oficial foi publicado (Published) apenas após todas as validações acima

Seguir esse processo não elimina 100% das falhas em produção — variáveis como volume de contatos e condições de rede podem gerar comportamentos inesperados —, mas reduz significativamente o risco de incidentes antes do lançamento para os clientes.

Ainda com dúvida?

Se este passo a passo não resolveu o seu caso, descreva o cenário exato. Cada dúvida recebida vira um novo tutorial nesta central.

Enviar minha dúvida