Regras de automação: gatilhos, condições e ações

Visão geral

Uma regra de automação executa ações automaticamente quando um evento acontece e as condições que você definiu são atendidas. É a forma mais direta de eliminar trabalho repetitivo: atribuir conversas, adicionar etiquetas, enviar mensagens, resolver conversas, mover negócios no CRM ou notificar sistemas externos por webhook.

Toda regra segue a estrutura gatilho → condições → ações:

• Gatilho: o evento que inicia a avaliação (por exemplo, "conversa criada").
• Condições: filtros que precisam ser verdadeiros para a regra agir.
• Ações: o que a plataforma faz quando o gatilho dispara e as condições passam.

Pré-requisitos

• Permissão de administrador para acessar a área de Automação em Configurações.
• Pelo menos uma caixa de entrada com conversas, para que os gatilhos tenham o que avaliar.
• Para ações que dependem de outros módulos (CRM, Catálogo, Tarefas, Follow-ups), o módulo correspondente precisa estar ativo na conta.

Passo a passo

Se ainda não houver regras, o estado vazio da página resume o objetivo da automação e permite criar a primeira regra sem procurar outra ação na tela.

1. Em Configurações, abra a área de Automação e crie uma nova regra.
2. Dê um nome e uma descrição claros à regra.
3. Escolha como a regra roda. O seletor Quando esta regra deve ser executada? aparece quando a execução com espera está habilitada na conta:
   • Executar imediatamente — "É executada no momento em que um evento ocorre, desde que as condições sejam atendidas." É o comportamento clássico, com o seletor de gatilho e a lista de condições logo abaixo.
   • Executar após um período de espera — "Aguarda o tempo definido e executa a regra apenas se as condições continuarem as mesmas. Caso algo mude durante esse período, a regra será ignorada." Nesse modo, o gatilho e as condições dão lugar ao bloco Condição de espera, detalhado em Configurações & opções.
4. Escolha o gatilho (evento). Os principais são:
   • Conversa criada, Conversa atualizada, Conversa resolvida, Conversa aberta;
   • Mensagem criada (recebida ou enviada);
   • Contato criado, Contato atualizado, Contato mesclado, Contato excluído — regras que agem direto no cadastro do contato, sem depender de uma conversa;
   • Pedidos: pedido registrado, status do pedido alterado, pedido pago, reembolso parcial ajustado, pedido reembolsado, pagamento revertido e negócio com pedidos totalmente pagos (com os módulos de Pagamentos/Comércio ativos);
   • Pagamentos: cobrança criada, confirmada, paga, parcialmente reembolsada, vencida, reembolsada, falhou ou foi cancelada. Confirmada significa que o cliente concluiu o pagamento, embora o gateway possa disponibilizar o saldo ao vendedor depois; paga/recebida registra essa etapa posterior do provedor. Não crie duas regras com as mesmas ações para os dois eventos;
   • Contratos: contrato visualizado, signatário assinou e contrato expirado (com o módulo de Contratos ativo);
   • Agenda — dois níveis, e a diferença importa:
     • Agendamento criado / remarcado / cancelado: o cliente agendou, remarcou ou cancelou pela página pública de agendamento (ou seja, existe uma reserva por trás);
     • Evento de agenda criado / remarcado / cancelado: o compromisso mudou na agenda — inclusive quando um agente edita, arrasta ou cancela pelo painel, ou pela aba Agendar de dentro da conversa. Um compromisso com reserva dispara os dois níveis quando você mexe nele pelo painel; um compromisso criado direto na agenda, sem reserva, dispara apenas o nível de evento.
   • eventos de CRM, Catálogo e Tarefas, quando esses módulos estão ativos.
5. Adicione condições. Combine campos (status, prioridade, caixa de entrada, etiquetas, idioma do navegador, atributos de contato/conversa, campos do CRM) com operadores como igual a, diferente de, contém ou não contém. Nos gatilhos de contato e de pedidos há condições específicas: cidade, tipo de contato (visitante, lead ou cliente), bloqueado, status do pedido, gateway do pedido e valor do pedido — além dos atributos personalizados do contato.
6. Defina uma ou mais ações (veja a lista abaixo).
7. Salve e ative a regra. Teste com uma conversa real para confirmar o comportamento.

Configurações & opções

Ações disponíveis (variam conforme o gatilho e os módulos ativos):

Quando os módulos estão ativos, surgem ações específicas: mover negócio de etapa, atribuir e definir valor/prioridade no CRM, adicionar produto a um negócio no Catálogo, criar tarefas, e inscrever o contato em uma sequência de Follow-ups.

Nos gatilhos de contato (criado/atualizado/mesclado) a regra roda sobre o contato — e agora oferece todo o catálogo ancorado no contato: além das ações de contato (etiquetas, nota, atributo), você pode criar um negócio no CRM já vinculado ao contato, mover etapa, criar uma tarefa ou agendamento ligados ao contato, enviar cobranças e assinaturas, inscrever em follow-ups e contratos, ações de engajamento e de grupo do WhatsApp (o participante padrão é o próprio contato), disparar webhook e lançar um fluxo em massa. As ações que agem sobre uma conversa (atribuir agente/equipe, resolver, enviar mensagem/nota/anexo, SLA, IA/Maestro, template do WhatsApp) continuam indisponíveis nesses gatilhos porque não há conversa — use Criar conversa para encadear em um gatilho de conversa.

• Condições "E": todas as condições precisam ser verdadeiras para a regra agir.
• Ordem: as ações são executadas na ordem em que aparecem na regra.
• Ativar/desativar: você pode pausar uma regra sem excluí-la.

Ações por gatilho

A lista de ações é escopada pelo assunto do gatilho: cada gatilho oferece todas as ações que o seu assunto consegue executar de fato — assim você monta a regra completa sem combinações que nunca rodariam.

• Gatilhos de conversa e de mensagem (conversa criada, atualizada, aberta, resolvida e mensagem criada) oferecem o catálogo completo de ações.
• Gatilhos de contato (criado/atualizado/mesclado) oferecem todo o catálogo ancorado no contato: CRM (criar negócio já vinculado ao contato, mover etapa), tarefas e agendamentos ligados ao contato, cobranças e assinaturas, follow-ups, contratos, engajamento, ações de grupo do WhatsApp (participante padrão = o contato), webhook e disparo em massa de fluxo. As ações que agem sobre uma conversa ficam de fora (não há conversa) — encadeie com Criar conversa.

Assinaturas: o que dispara e o que não dispara

Uma assinatura criada no painel do gateway é adotada aqui e dispara a regra: para a plataforma ela está acontecendo agora, já filtrada pela data de corte da conexão. Uma assinatura trazida por uma importação de histórico nunca dispara — ela é passado, e reprocessá-la abriria negócios e notificações para vendas antigas.

A assinatura adotada pode chegar sem cliente vinculado. Ações que dependem de uma pessoa (abrir negócio, mensagem, pontuação) não têm a quem se dirigir, e um negócio sem contato, empresa nem conversa é recusado em vez de virar um card inútil no funil. Para agir só quando houver alguém do outro lado, adicione a condição Contato vinculado à assinatura com "está presente".

• Gatilho de contato excluído: como o cadastro deixou de existir, oferece apenas webhook e ações totalmente controladas por parâmetros.
• Gatilhos de pedidos ancoram no contato do pedido — todas as ações ancoradas no contato ficam disponíveis.
• Gatilhos de tarefas, agenda, grupos do WhatsApp, assinaturas, comércio, contratos, engajamento, CRM e anúncios ganharam o catálogo completo que o assunto suporta — inclusive ações de conversa quando o assunto tem uma conversa vinculada (por exemplo, tarefa com conversa vinculada ou grupo com a conversa do grupo).

Ao criar uma regra nova (ou trocar o gatilho), o seletor já vem com a primeira ação válida daquele gatilho pré-selecionada — você nunca mais abre uma regra nova e encontra "Atribuir ao Agente · Indisponível para este gatilho".

Se você editar uma regra antiga que tenha uma ação que não pertence mais ao gatilho atual, essa ação continua visível com a marca "Indisponível para este gatilho". Ela não é apagada: a regra segue salvável e você pode trocá-la por uma ação compatível quando quiser.

Ações sem parâmetros

Algumas ações não pedem nenhum campo extra porque resolvem o contexto sozinhas a partir do gatilho. Elas salvam sem exigir parâmetros, tanto em Automações quanto em Macros:

• Cancelar, pausar, retomar e pular etapa de follow-up;
• Enviar cobrança e cancelar assinatura;
• Enviar cartão de produto;
• Pausar campanha de anúncios, enviar conversão e marcar como lead de anúncio.

Quando uma ação não se aplica

Se uma ação depende de algo que não existe naquele contexto — por exemplo, uma ação de conversa em um gatilho que não tem conversa associada — ela é ignorada e registrada, sem quebrar a regra: as demais ações continuam sendo executadas normalmente.

Variáveis nas ações ({ } Inserir)

Todo campo de texto que a plataforma resolve na execução mostra o botão { } Inserir e abre a lista de variáveis quando você digita {{. A variável escolhida entra na posição do cursor e a janela da regra continua aberta. Os mesmos campos aceitam variáveis em Automações, Macros e no Flow Builder — no fluxo, esses campos também resolvem {{ vars.* }} e {{ steps.* }}.

Campos que não aceitam variáveis, de propósito:

• Seletores (agente, time, etiqueta, funil, etapa, caixa de entrada, conexão): o valor vem da lista.
• URL do webhook: o destino é fixo por segurança; os dados da conversa ou do contato já seguem no corpo do webhook.
• Valor de cobranças e assinaturas: é dinheiro enviado ao gateway e nunca vem de um texto.
• Gateway do pedido, idioma e namespace do template: são identificadores.
• Atributos adicionais e os campos numéricos e de data do editor de regras (por exemplo, o valor do negócio em "Definir valor"): no formulário do Flow Builder o valor do negócio aceita variável.

Quais variáveis a lista oferece depende do gatilho:

• Conversa e mensagem: contato, conversa, caixa de entrada, agente, time, SLA, conta e os módulos (CRM, empresa, pagamento, pedido, agenda, tarefa, contrato e outros).
• Contato e empresa: não há conversa — a lista esconde conversa, caixa de entrada, agente, time e SLA.
• Pagamentos: {{ payment.* }} descreve a cobrança que disparou a regra. CRM: {{ crm.* }} descreve o negócio que disparou a regra.
• Os demais módulos ligados ao contato (pedido, agenda, tarefa, contrato) usam o registro mais recente do contato.
• Regras e macros nunca oferecem as variáveis exclusivas do Flow Builder (vars, steps, trigger) nem as de outras telas (produto, campanha, grupo, artigo).

Quando uma variável não tem valor, o texto fica em branco naquele trecho — o cliente nunca recebe {{ ... }}. Em campos que são dado (telefone, e-mail do convidado, ids, valores e datas), a ação é ignorada e registrada em vez de gravar um valor errado. O telefone é normalizado para o formato internacional depois de a variável ser resolvida, então 55 11 98888-7777 vira +5511988887777.

O valor de uma variável é sempre tratado como texto: se o nome do contato, um atributo ou uma resposta do cliente contém {{ }} ou {% %}, ele aparece exatamente como está — nunca é executado — e no e-mail para o time ele também não vira HTML. Um modelo que gera texto grande demais ou repete sem fim é interrompido e fica em branco.

O formulário da regra

A regra abre em uma janela modal sobre a lista, ancorada no topo da tela e com rolagem própria: o formulário inteiro cabe ali, do nome até as ações. Os menus de condição e de ação abrem dentro dessa janela — é uma escolha deliberada da plataforma, para que nenhuma lista suspensa fique escondida atrás do modal.

A ordem dos campos é sempre a mesma: nome, descrição, o seletor Quando esta regra deve ser executada? (quando a execução com espera está habilitada) e, abaixo dele, o gatilho e as condições — ou o bloco Condição de espera, se você escolher a espera. As ações vêm por último, seguidas dos botões de cancelar e salvar.

Alguns detalhes que evitam surpresa:

• Trocar entre "imediata" e "com espera" não perde a duração digitada. O valor fica guardado no formulário, então você pode ir e voltar entre os dois cartões sem redigitar "4 horas".
• Ao reabrir uma regra com espera, o tempo aparece na maior unidade inteira: 240 minutos são exibidos como "4 horas"; 2.880 minutos, como "2 dias".
• Ao transformar uma regra imediata em regra com espera, as condições do editor imediato são substituídas pelas condições do gatilho de espera escolhido. É proposital: um filtro que sobrasse do editor anterior armaria a contagem no evento errado.
• No bloco de espera, o status já vem preenchido com Pendentes; as opções são Abertas, Resolvidas, Pendentes e Adiadas — "Todas" não entra aqui, porque uma espera precisa de um status concreto para contar.
• Em uma regra nova, trocar o evento avisa em texto: "Alterar o evento irá redefinir as condições e eventos que você adicionou abaixo".
• Gatilhos cujo assunto não tem nenhum campo filtrável (grupo do WhatsApp, catálogo e outros) simplesmente não mostram a seção de condições — em vez de exibirem uma linha de condição vazia.

Regras com espera: executar depois de um tempo

A execução com espera é controlada pela funcionalidade Delayed Automations (delayed_automations), que nasce desligada e é habilitada por conta. Com ela ativa, o formulário da regra ganha o seletor Quando esta regra deve ser executada?, com duas opções em cartão: Executar imediatamente e Executar após um período de espera.

Ao escolher a espera, o gatilho e a lista de condições dão lugar ao bloco Condição de espera, com quatro campos:

Ao lado dos campos há um painel lateral com o ícone de informação. Ele explica em texto corrido o que a combinação escolhida significa, usando a mesma unidade que você digitou ("4 horas", "2 dias"):

• A conversa permanece em um status — "A contagem começa quando a conversa entra nesse status. Se ela ainda estiver nele após {duração}, as ações abaixo serão executadas. Se o status mudar antes disso, nada acontecerá."
• O cliente não respondeu — "A contagem começa quando um atendente responde. Se o cliente não responder em até {duração}, as ações abaixo serão executadas. Se ele responder antes, nada acontecerá, e a próxima resposta do atendente iniciará a contagem novamente."
• Nenhum atendente respondeu — "A contagem começa quando um cliente envia uma mensagem. Se nenhum atendente responder em até {duração}, as ações abaixo serão executadas. Se alguém responder antes disso, nada acontecerá."

O mesmo painel traz o rodapé: "Apenas novas atividades iniciam uma contagem. Conversas que já estiverem nesse estado só serão consideradas na próxima vez que houver alguma atividade nelas."

Duas precisões que o painel não tem espaço para explicar, e que mudam o resultado:

• Em O cliente não respondeu, cada nova resposta do atendente adianta o vencimento: o prazo passa a contar da resposta mais recente. Uma sequência de mensagens da equipe empurra o prazo para frente; ela não acumula vários prazos.
• Em Nenhum atendente respondeu, vale o relógio da primeira mensagem sem resposta do cliente. Se ele mandar mais três mensagens seguidas, o prazo continua contando desde a primeira — não reinicia a cada mensagem.

Limites da espera

• Mínimo de 10 minutos e máximo de 30 dias (43.200 minutos). O campo ajusta sozinho um valor fora dessa faixa para o limite mais próximo — ao sair do campo, ao pressionar Enter ou ao trocar a unidade. Digitar 5 minutos deixa 10. A mensagem "O período de espera deve ser entre 10 minutos e 30 dias" aparece ao tentar salvar com o campo de duração vazio.
• A duração sugerida ao criar uma regra nova é de 4 horas.
• Ao trocar a unidade, o mínimo acompanha: em dias, o menor valor possível é 1 dia.
• Uma nota privada é uma mensagem de saída. Por isso a opção O cliente não respondeu já adiciona sozinha um filtro que ignora notas internas — uma anotação da equipe não reinicia a contagem.

O que a espera não aceita

• Condições com o operador de mudança de atributo (attribute_changed): a reconferência feita na hora de executar não consegue reconstruir o que mudou, então a regra é recusada ao salvar.
• Nos gatilhos de conversa, apenas status e caixa de entrada podem ser usados como condição. Os demais campos mudam durante a espera e misturariam períodos diferentes em uma contagem só.

Editar uma regra com espera zera as contagens em andamento

Alterar gatilho, condições, ações, duração — ou simplesmente ligar/desligar a regra — descarta as esperas já armadas. Elas voltam a ser armadas no próximo evento que combinar. É proposital: uma regra desligada e religada antes do prazo não deve executar justamente as ações que você desligou para evitar.

Uma única exceção: uma espera que já começou a executar as ações não é interrompida — o que está em voo não tem como ser chamado de volta. Tudo o que ainda apenas aguardava é descartado.

Como a lista separa regras imediatas e com espera

Quando a conta pode criar regras com espera (ou ainda tem alguma), a lista ganha duas abas com contador: Executadas imediatamente e Executadas após um período de espera. Criar uma regra a partir da segunda aba já abre o formulário com a espera selecionada.

• Cada regra com espera exibe, ao lado do nome, o selo Executadas após {tempo}, escrito na maior unidade inteira: 30m, 4h, 2d.
• A aba de espera sem regras mostra "Ainda não há regras executadas após um período de espera".
• Cada linha traz três ícones de ação, com dica ao passar o mouse: Alterar, Duplicar e Excluir. No formulário, cada ação da regra também tem o seu ícone (envelope para transcrição por e-mail, etiqueta para rotular, sino cortado para silenciar, relógio para adiar, e assim por diante) — os mesmos ícones aparecem nas Macros.

A lista completa de ícones de ação: pessoa (atribuir agente), pessoas arredondadas (atribuir equipe), pessoa com X (remover agente), pessoas (remover equipe), etiqueta (rotular), etiqueta com menos (remover etiqueta), envelope (transcrição por e-mail), avião de papel (e-mail para a equipe), balão (enviar mensagem), bloco de notas (nota privada), clipe (anexo), webhook, sino cortado (silenciar), relógio (adiar), círculo com ponto (reabrir), círculo tracejado (marcar como pendente), círculo com check (resolver), barras de sinal (prioridade) e medidor (SLA). Toda ação sem ícone próprio usa o raio.

O cabeçalho traz ainda a busca ("Pesquisar regras de automação..."), que filtra por nome e descrição ao mesmo tempo e vale para as duas abas — os contadores acompanham o filtro. Sem resultado, a tabela mostra "Nenhuma regra de automação encontrada correspondente à sua busca". Ao lado das abas aparece a contagem das regras visíveis na aba atual.

A tabela tem quatro colunas: Nome, Ativo, Criado em e Ações. A coluna de data mostra o dia; o horário completo aparece ao passar o mouse. A chave de Ativo pede confirmação antes de ligar ou desligar, e a pergunta nomeia a regra ("Esta ação irá desativar a regra de automação '...'").

Quando a espera está desligada

Se a funcionalidade for desativada e a conta ainda tiver regras com espera, um aviso em destaque aparece acima da lista: "A execução com atraso está desativada para esta conta, portanto as regras abaixo que executam após um período de espera estão pausadas até que ela seja ativada novamente."

Nesse estado:

• As esperas já armadas não são apagadas — ficam paradas. Ao reativar a funcionalidade, as que passaram do limite de 3 dias durante a pausa recebem um prazo novo para agora, em vez de serem descartadas por vencimento; as demais simplesmente entram na varredura seguinte. Todas passam pela reconferência normal antes de executar.
• Nenhuma espera nova é armada, e a regra não passa a rodar na hora: virar instantânea em silêncio seria pior do que não rodar.
• Duplicar uma regra com espera é recusado, em vez de criar uma cópia que dispararia imediatamente. Na tela aparece o aviso genérico "Não foi possível duplicar regra de automação, por favor, tente novamente mais tarde"; o motivo específico vem na resposta da API ("Delayed automations are not enabled for this account.").

Como a espera é executada nos bastidores

Saber isto ajuda a interpretar o que você vê na tela:

1. Quando o evento acontece e as condições passam, a plataforma agenda a execução em vez de rodar as ações. A contagem parte do momento do evento — não do momento em que o processamento aconteceu — então uma fila atrasada ainda dispara na hora certa.
2. A cada 5 minutos uma varredura recolhe as execuções vencidas e as entrega aos processadores.
3. Antes de executar, a plataforma reconfere tudo: a regra ainda está ativa? A conversa ainda existe? O período continua o mesmo (o status não mudou, ninguém respondeu)? As condições continuam verdadeiras? Qualquer "não" registra o motivo e descarta a execução sem rodar as ações.
4. Uma execução que passou 3 dias do prazo nunca roda — isso evita que uma indisponibilidade longa despeje mensagens antigas de uma vez. Os registros já encerrados são limpos após 30 dias.
5. As ações não são repetidas: se algo falhar depois que elas começaram, a plataforma não reexecuta. Reenviar mensagem, e-mail ou webhook é pior do que não reenviar.

Duas salvaguardas completam o quadro:

• Cada varredura entrega no máximo 1.000 execuções. O excesso fica para a varredura seguinte, 5 minutos depois, e o responsável pela instalação pode alterar esse teto. Contas com a execução com espera desligada não consomem essa cota — o acúmulo de uma conta pausada nunca atrasa as outras.
• Um processador que morra antes de agir tem a execução recuperada após 15 minutos e devolvida à fila. Um processador que morra no meio das ações não é repetido, pela mesma razão do item 5.

Toda execução descartada guarda o motivo, o que torna o diagnóstico direto: expired (passou dos 3 dias), rule_inactive (a regra foi desativada), conversation_gone (a conversa não existe mais), episode_moved (o período acabou — alguém respondeu ou o status mudou) e conditions_changed (uma condição deixou de ser verdadeira).

Um detalhe que explica o rodapé do painel: uma espera por status só arma quando a conversa tem registro de quando entrou no status atual. Conversas anteriores à funcionalidade não têm esse registro — elas passam a contar na próxima mudança de status, em vez de vencerem todas de uma vez na primeira varredura.

Enviar a transcrição para o e-mail do contato

A ação Enviar transcrição por e-mail aceita uma lista de endereços separados por vírgula, e cada endereço passa por variáveis antes do envio. Para mandar o histórico ao próprio cliente, escreva:

{{contact.email}}

Você pode combinar variável e endereço fixo: {{contact.email}}, supervisao@suaempresa.com. Outras variáveis do contato também funcionam nesse campo (por exemplo {{contact.custom_attribute.email_nf}} para um atributo personalizado). Use a variável apenas em regras cujas condições garantam um contato com e-mail cadastrado — sem e-mail, não há o que resolver. O envio só acontece quando a transcrição por e-mail está habilitada para a conta e respeita o limite de e-mails da conta.

Dois detalhes do campo: todo espaço em branco é removido antes de a lista ser separada pelas vírgulas — {{contact.email}} , supervisao@suaempresa.com funciona igual à versão sem espaços. E o campo resolve o mesmo conjunto de variáveis do compositor de resposta (contato, conversa, caixa de entrada, conta e os módulos ativos), não apenas as do contato. Se a conta bater o limite de e-mails no meio da lista, os endereços restantes daquele envio ficam de fora.

Casos de uso

• Roteamento por canal: conversas criadas no WhatsApp comercial vão para a equipe de Vendas.
• Triagem por palavra-chave: se a mensagem contém "boleto", adicionar a etiqueta "financeiro".
• Fora do horário: ao criar uma conversa fora do expediente, enviar uma mensagem automática.
• Higiene da fila: resolver conversas sem resposta há muito tempo e notificar a equipe.
• CRM: ao criar uma conversa de um lead, criar um negócio e atribuí-lo ao vendedor responsável.
• Cliente sumiu (com espera): se o cliente não responder 4 horas depois da última resposta da equipe, etiquetar como "sem retorno" e criar uma tarefa de retomada.
• Primeira resposta atrasada (com espera): se nenhum atendente responder em 30 minutos, avisar a equipe por e-mail e subir a prioridade.
• Fila parada (com espera): conversa em "Pendente" há 2 dias, resolver e enviar a transcrição para o e-mail do contato.

Dicas, limites e boas práticas

• Use nomes descritivos e mantenha cada regra focada em um objetivo.
• Evite regras conflitantes que tentam fazer coisas opostas na mesma conversa.
• Para ações que enviam mensagens automáticas, cuide dos limites do canal (boas práticas anti-ban do WhatsApp).
• Teste em uma caixa de entrada de testes antes de aplicar a regra em produção.
• Documente para a equipe o que cada regra faz — facilita a manutenção futura.
• Comece com esperas generosas (horas, não minutos) e encurte depois de ver o resultado: uma espera curta demais dispara em cima de conversas que ainda estavam sendo atendidas.
• A espera é uma contagem contínua, não um relógio de horário comercial: 12 horas iniciadas às 20h vencem às 8h do dia seguinte.
• Ao habilitar a execução com espera, as conversas que já estão paradas naquele estado não começam a contar sozinhas — a contagem começa na próxima atividade delas.
• Restrinja a regra por caixa de entrada quando o tempo aceitável de resposta variar por canal.

Solução de problemas

• A regra não disparou: confirme o gatilho e que todas as condições estão verdadeiras; veja se a regra está ativa.
• A ação não executou: verifique se o agente, equipe ou etiqueta referidos ainda existem; e se o módulo da ação (CRM, Catálogo, etc.) está habilitado.
• A regra agiu na conversa errada: as condições estão amplas demais. Refine os filtros.
• Uma ação foi ignorada: algumas ações só rodam quando há uma conversa no contexto do gatilho; fora disso, elas são registradas e ignoradas sem interromper a regra. Prefira uma ação compatível com o gatilho escolhido.
• Uma ação aparece com o valor bloqueado, mostrando só um número: a ação aponta para um registro de um módulo que está desativado na conta ou ao qual o seu perfil não tem acesso (por exemplo, uma sequência de follow-up ou uma política de SLA). Um valor bloqueado também pode significar que a lista ainda não carregou, que a busca falhou ou que a lista do seu perfil de acesso não inclui o registro (ele pode estar fora do seu alcance ou ter sido removido). A dica explica a causa. A referência fica inalterada ao salvar outras mudanças. Recarregue a página para repetir uma busca que falhou; se o acesso for restrito, peça a quem tem acesso ou reative o módulo.
• Uma ação mostra um número em vez do nome: o registro pode estar fora da página carregada de uma lista longa ou ter sido removido. Um lote preparado também pode aparecer só pelo identificador. Quando uma busca confirma a remoção, o campo o identifica como removido. O valor continua selecionado e é salvo sem alteração; escolha outro item só se quiser trocá-lo.
• Webhook não chegou: confira a URL do endpoint e se ele responde com sucesso.
• A regra com espera nunca executou: o motivo mais comum é o período ter terminado antes do prazo — alguém respondeu, o status mudou ou uma condição deixou de ser verdadeira. Confira também se a regra continua ativa e se a conversa ainda existe.
• Todas as regras com espera pararam de uma vez: procure o aviso acima da lista. Ele indica que a execução com atraso foi desativada para a conta; ao reativá-la, as esperas vencidas são reagendadas.
• Quero saber por que uma espera foi descartada: o motivo fica registrado na própria execução — expired, rule_inactive, conversation_gone, episode_moved ou conditions_changed. Peça ao responsável pela instalação para consultá-lo quando o comportamento não estiver claro.
• As esperas estão vencendo com atraso: cada varredura entrega até 1.000 execuções e roda a cada 5 minutos. Um acúmulo maior do que isso é escoado nas varreduras seguintes.
• Não consigo salvar a espera: remova condições com operador de mudança de atributo e, nos gatilhos de conversa, mantenha apenas status e caixa de entrada.
• Não consigo duplicar uma regra com espera: o aviso genérico de falha ao duplicar aparece porque a funcionalidade está desativada na conta. Reative-a antes de duplicar, para não gerar uma cópia sem a espera.
• O bloco de espera não aparece no formulário: a funcionalidade Delayed Automations não está habilitada para a conta.

Mudança de etapa no CRM

Use o evento Etapa do negócio do CRM alterada e selecione a etapa nas condições. A regra só dispara quando o negócio muda efetivamente de etapa; reorganizar um card dentro da mesma coluna não dispara outra execução.

Anexos (incluindo PDF) e conversões Meta usam a conversa vinculada ao negócio. Se o vínculo não existir, a ação fica registrada como ignorada; o webhook pode executar independentemente. Confirme as configurações de conversão da caixa e use arquivos anexados à própria regra. Enfileirar uma conversão não comprova que a Meta a aceitou: confira também o registro de entrega de conversões.

Ao escolher execução atrasada, o prazo começa na mudança de etapa. Na hora de executar, o sistema confere novamente a etapa, as condições e se a regra está ativa. Pausar a funcionalidade preserva as ações pendentes. Ao reativá-la, retomam apenas as elegíveis; execuções vencidas há mais de três dias são marcadas como expiradas. Alterar ou desativar a regra cancela os trabalhos pendentes da definição anterior.

Cada ação mantém seu próprio resultado. Repetir o evento ou retomar o worker não repete ações concluídas. Se uma integração externa puder ter executado antes de uma falha, o resultado fica incerto e exige conferência antes de reenviar. Não reaplique em massa mudanças históricas de etapa para recuperar uma regra: isso pode disparar efeitos comerciais legítimos novamente.

Veja também

• Visão geral de Automação e Fluxos
• Gatilhos de automação sobre a IA (Maestro)
• Macros: ações reutilizáveis
• Flow Builder: fluxos conversacionais visuais
• Roteamento inteligente (Smart Routing)