## 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):

| Ação | O que faz |
| --- | --- |
| Atribuir agente | Direciona a conversa a um agente específico. |
| Atribuir equipe | Direciona a conversa a uma equipe. |
| Adicionar etiqueta | Marca a conversa com uma ou mais etiquetas. |
| Enviar mensagem | Envia uma mensagem ao contato. |
| Enviar e-mail para a equipe | Notifica a equipe por e-mail. |
| Enviar transcrição por e-mail | Envia o histórico da conversa por e-mail. |
| Silenciar conversa | Coloca a conversa em mudo. |
| Resolver conversa | Encerra a conversa automaticamente. |
| Enviar anexo | Anexa um arquivo à conversa. |
| Disparar webhook | Envia o evento para um endpoint externo. |
| Adicionar etiqueta ao contato | Marca o **contato** (não a conversa) com etiquetas. |
| Remover etiqueta do contato | Remove etiquetas do cadastro do contato. |
| Adicionar nota ao contato | Registra uma nota interna no cadastro do contato. |
| Definir atributo do contato | Grava um valor em um atributo personalizado do contato. |
| Lançar disparo em massa | Inicia um disparo em massa de um fluxo publicado do Flow Builder. |

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.* }}`.

| Ação | Campos que aceitam variáveis |
| --- | --- |
| Enviar mensagem, Adicionar nota privada | Mensagem |
| Enviar e-mail para o time | Mensagem |
| Enviar transcrição por e-mail | E-mails |
| Criar contato | Nome, e-mail, telefone, identificador, CPF/CNPJ, país fiscal e valores dos atributos personalizados |
| Criar conversa | Primeira mensagem |
| Adicionar nota ao contato | Nota |
| Definir atributo ou campo do contato / da empresa | Valor (texto) |
| Definir afiliado do contato | Código de indicação |
| Criar negócio do CRM | Título, descrição, e-mail e telefone do contato, valor, datas e valores dos atributos personalizados |
| Atributo, status e mensagens do negócio | Valor do atributo, motivo do fechamento, nota, item de checklist, mensagem |
| Criar tarefa, Comentar tarefa | Título, descrição, vencimento, valores dos atributos personalizados, comentário |
| Criar, cancelar e convidar em agendamento | Título, descrição, local, início, fim, atributos personalizados, motivo, e-mail do convidado |
| Criar cobrança, Criar assinatura | Descrição |
| Registrar pedido | Título, valor, id externo |
| Vendas | Métrica dos pontos, motivo da transferência e da recompensa |
| WhatsApp (grupos e contatos) | Telefone, nome do contato, anúncio da comunidade |
| Enviar template ou Flow do WhatsApp | Variáveis do template, cabeçalho e conteúdo; botão, corpo, cabeçalho e rodapé do Flow |
| Perguntar ao Maestro | Pergunta |
| Ajustar orçamento de anúncio | Orçamento diário |

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:

| Campo | O que você preenche |
| --- | --- |
| **Quando** | A situação que inicia a contagem: **A conversa permanece em um status**, **O cliente não respondeu** ou **Nenhum atendente respondeu**. |
| **O status é** | Só aparece na primeira opção: o status que a conversa precisa manter. |
| **Aguardar por** | A duração, em minutos, horas ou dias. |
| **Caixa de Entrada** | Restringe a regra a caixas específicas. Sem seleção, ela vale para todas. |

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](/hc/ajuda/articles/automation-flows-overview-pt-br)
- [Gatilhos de automação sobre a IA (Maestro)](/hc/ajuda/articles/automation-flows-gatilhos-de-ia-pt-br)
- [Macros: ações reutilizáveis](/hc/ajuda/articles/automation-flows-macros-pt-br)
- [Flow Builder: fluxos conversacionais visuais](/hc/ajuda/articles/automation-flows-flow-builder-pt-br)
- [Roteamento inteligente (Smart Routing)](/hc/ajuda/articles/automation-flows-smart-routing-pt-br)