O ciclo completo
O evento acontece
Alguém move um projeto, responde um formulário, vincula uma etiqueta — ou um agendamento chega na hora marcada.
O sistema procura automações compatíveis
Só entram na disputa as automações ativas da sua conta cujo gatilho é do mesmo tipo do evento.
Cada automação confere as próprias opções
Ter o gatilho certo não basta: as opções também precisam bater. Um gatilho de etapa configurado para “Proposta enviada” ignora um projeto que entrou em “Contrato assinado”.
As que combinam executam, uma depois da outra
Se três automações combinarem com o mesmo evento, as três rodam. Não há ordem garantida entre elas, então evite montar automações que dependam uma da outra pela ordem.
O gatilho não é executado como os outros componentes. Ele apenas decide se a automação roda. Quem executa são as ações e condições.
A ordem dos componentes
Os componentes rodam de cima para baixo, na ordem em que aparecem no editor. Use Mover para cima e Mover para baixo no menu de cada componente para reordenar. A ordem importa sempre que um componente depende do efeito do anterior. Alguns exemplos reais:- Colocar o projeto em uma etapa antes de aplicar uma etiqueta daquele funil — a etiqueta só é aplicada se o funil estiver vinculado.
- Adicionar um formulário avulso antes de atualizar um contador daquele formulário.
- Criar o cliente antes de enviar um e-mail que usa o nome dele.
Condições e ramos
Uma condição avalia algo sobre o projeto e devolve verdadeiro ou falso. Isso define qual dos dois ramos executa:Se verdadeiro
Executa os componentes colocados neste ramo quando a checagem passa.
Se falso
Executa os componentes deste ramo quando a checagem não passa.
Bloquear o fluxo
As condições têm a opção de bloquear o fluxo. Com ela ligada, quando a condição for falsa, o ramo “Se falso” ainda executa normalmente — e, terminado o ramo, a automação para ali. Os componentes seguintes do nível principal não rodam. Use o bloqueio para escrever regras do tipo “só continue se…”:1
Quando
Um projeto entra na etapa “Faturamento”.
2
Se (bloqueando o fluxo)
O projeto contém o status de funil “Aprovado”. Se não contiver, a automação termina aqui.
3
Então
Gera a cobrança, avisa o financeiro, move para “Aguardando pagamento”.
Mantenha as condições no nível principal
Em quais projetos cada componente age
Por padrão, cada ação e cada condição age no projeto que disparou a automação. No menu do componente, Definir projetos alvo (nas ações) ou Definir em quais projetos (nas condições) permite escolher outros projetos, sempre a partir do projeto do gatilho.Nas ações
A ação roda uma vez em cada projeto da lista, e o registro de execução mostra uma linha por projeto. Dentro da ação, as variáveis do projeto se referem ao projeto que está sendo processado naquele momento, não ao do gatilho. Com qualquer opção além do projeto do gatilho, Limitar com filtro cruza a lista com um filtro para reduzir quais projetos entram — por exemplo, só os filhos com impacto alto.Nas condições
A condição é verificada em cada projeto da lista, e os resultados viram um só conforme a opção Quando a condição passa: Em todos, Em pelo menos um ou Em nenhum. O ramo escolhido executa uma vez. Veja Verificar em outros projetos. Condições não aceitam Limitar com filtro nem a opção Por filtro. Quando a regra depende de um filtro, use a condição Decisor com filtro.Sintaxe avançada
A expressão precisa devolver identificadores de projeto em um destes formatos:Limites e casos de borda
No máximo 50 projetos
No máximo 50 projetos
A lista é cortada em 50 projetos. Uma ação roda nesses 50 e a execução fica marcada com erro, para que o corte não passe despercebido. Numa condição, Em todos e Em nenhum dão falso — sem ver a lista inteira não dá para garantir o resultado —, e Em pelo menos um verifica os 50.
Lista vazia
Lista vazia
Acontece, por exemplo, com os irmãos de um projeto que não tem pai, ou com Por filtro sem nenhuma regra — um filtro vazio não abre a lista para a conta inteira. A ação não faz nada e registra sucesso com a mensagem
no_projects_in_scope. A condição só dá verdadeiro com Em nenhum.Falha em um dos projetos
Falha em um dos projetos
Um erro em um projeto da lista fica registrado naquele projeto, e os demais continuam sendo processados. Se a própria lista não puder ser montada — uma expressão que falhou, um filtro que ficou inválido —, o componente registra
project_scope_resolution_failed e o fluxo segue.A automação não se aciona de novo
A automação não se aciona de novo
Enquanto uma automação está rodando, o que ela provoca não a dispara outra vez — nem no projeto do gatilho, nem nos outros projetos em que ela age. Automações diferentes continuam podendo se acionar, dentro do limite de encadeamento.
O que acontece quando algo falha
Nem todo problema derruba a automação. O comportamento depende do tipo de falha:A ação não tinha o que fazer
A ação não tinha o que fazer
A maioria das ações tem pré-requisitos silenciosos: uma etiqueta só é aplicada se o funil dela estiver vinculado ao projeto, um contador só é atualizado se o formulário estiver disponível.Nesses casos a ação registra o motivo no log e o fluxo continua nos componentes seguintes.
Faltou permissão
Faltou permissão
O componente é marcado com erro no registro de execução, mas o fluxo continua. O log identifica qual permissão faltou.
Erro inesperado
Erro inesperado
Uma falha não prevista fica registrada no componente em que aconteceu, com a mensagem original, e o fluxo continua nos componentes seguintes. O registro de execução fica marcado com erro, para que a falha não passe despercebida.
A condição não conseguiu avaliar
A condição não conseguiu avaliar
Se a condição falha ao avaliar — por exemplo, um filtro salvo que ficou inválido — o erro é registrado, nenhum dos dois ramos executa e o fluxo segue para os componentes seguintes.
Automações que acionam automações
Uma ação pode provocar um evento que aciona outra automação. Mover um projeto de etapa, por exemplo, dispara o gatilho Projeto movido de etapa de qualquer outra automação configurada para aquela etapa. Isso é esperado e útil, mas existe um teto: uma cadeia pode encadear até cinco automações. Ao chegar na sexta, a execução é interrompida e o registro aponta o motivo (automation_run_limit_reached).
Uma automação, porém, não aciona a si mesma: enquanto ela está rodando, o que ela provoca não a dispara outra vez, em nenhum projeto. O encadeamento acontece entre automações diferentes.
Cuidado especial com cadeias que voltam ao ponto de partida — uma automação que move o projeto para a etapa A, e outra na etapa A que move de volta. O limite impede o laço infinito, mas as duas gastam execuções do plano até estourar.
O que a automação ignora e o que ela respeita
Automação não é ação de usuário: em parte do fluxo ela passa por cima das travas do funil, em parte não. A diferença é por ação.
No caso das etiquetas e dos status, o bloqueio é configurado no próprio funil, etapa por etapa. A opção Bloquear vínculo por automações, marcada por padrão, faz o bloqueio valer também para automações. Desmarque-a se quiser que a automação passe por cima daquele bloqueio específico.
Restrições e bloqueios de etapa
Como as duas travas funcionam e onde configurá-las no funil.
Quem disparou
Todo registro de execução guarda a origem do disparo. É a primeira coisa a olhar quando você precisa entender por que algo rodou:
Quando a origem é um usuário, os dados dele ficam disponíveis para uso em variáveis — é assim que você escreve “Movido por Fulano” na mensagem.
Uma execução, um registro
O contador de Execuções da lista de automações sobe uma vez por disparo, não uma vez por componente. Uma automação com dez ações que roda três vezes marca três execuções. Cada disparo também grava um registro completo do que aconteceu. Veja Logs e depuração para ler esse registro.Por onde continuar
Gatilhos
Os oito eventos que podem iniciar uma automação.
Condições
As quatro checagens disponíveis e como cada uma decide.
Logs e depuração
Como ler o registro de execução e o que cada erro significa.
Receitas prontas
Montagens completas para cenários comuns.