Referência de gatilhos e condições
Use esta página ao projetar uma automation: o que a inicia e o que precisa ser verdadeiro antes de um passo rodar. Os rótulos exatos na interface podem variar ligeiramente conforme a versão; o comportamento descrito aqui corresponde ao builder de Automations.
Duas peças trabalham juntas:
- Um gatilho inicia a automation quando algo acontece (ou em um agendamento). Alguns gatilhos também filtram quais eventos iniciam uma execução (por exemplo, somente respostas de check-in que incluem um bloqueio).
- Uma pré-condição em um passo é lógica em texto livre só para esse passo. Não há um campo de “condição” separado para a automation inteira.
Se uma execução nunca começa, comece pelo gatilho. Se começa e para no meio do fluxo, abra a pré-condição do passo. Para detalhes do histórico de execuções, veja Solução de problemas de automations.
Gatilhos
Um gatilho responde: “Quando esta automation deve começar?” Cada automation tem um gatilho. A configuração do gatilho também pode limitar quais eventos contam (canal, usuários, somente follow-ups com bloqueio, intervalos de datas em passos de fetch e seletores semelhantes no gatilho ou no passo). Esses controles não são pré-condições de passo.
Quais gatilhos existem? (resposta rápida)
- Tempo: em um agendamento (tipo cron) ou em uma cadência fixa.
- Eventos de check-in: quando uma rodada termina, quando um bloqueio é sinalizado ou quando uma resposta é enviada.
- Eventos de formulário / tabela: quando um formulário do Dailybot recebe um envio.
- Eventos de membros: quando um usuário entra (ou, em alguns planos, sai) da organização.
- Webhook de entrada: um sistema externo faz POST na URL da sua automation.
- Eventos de Kudos: quando um kudo é dado (sujeito ao plano).
Referência de gatilhos
| Gatilho | Tipo | Descrição | Exemplo |
|---|---|---|---|
| Schedule | Scheduled | Dispara nos intervalos que você definir (diário, semanal, expressão cron). | Toda segunda 09:00 no fuso da organização. Publica um lembrete de metas semanais. |
| Check-in completed | Event | Dispara quando uma rodada de check-in termina ou um limiar de respostas é atingido. | Quando o standup fecha, envia um webhook de resumo para a ferramenta de BI. |
| Form submitted | Event | Dispara quando um formulário do Dailybot recebe um envio. | Formulário de solicitação de TI enviado, notifica #it-triage. |
| New member joined | Event | Dispara quando um usuário entra na organização na plataforma de chat conectada. | Sequência de DM de boas-vindas para novas contratações. |
| Webhook received | Webhook | Dispara quando uma requisição HTTP chega à URL de entrada da sua automation com autenticação válida. | Pipeline de CI publica o status do build, publica pass/fail em um canal. |
O gatilho só inicia a execução. Se os passos seguintes rodam depende da pré-condição de cada passo.
Pré-condições nos passos de uma automation
Uma pré-condição decide se o passo atual deve rodar. No builder é um único campo de texto (pre_condition) no passo. Nesse mesmo campo você pode escrever linguagem natural ou tags de lógica.
Quando a automation chega a esse passo:
- Se a condição é verdadeira, o Dailybot executa o passo e continua para o próximo.
- Se a condição é falsa, o Dailybot não executa o passo e para a automation ali. Os passos seguintes não são executados.
Isso corresponde ao copy do builder: quando a pré-condição não é atendida, a automation para naquele passo. Não diz “pule este passo e continue”. Um dry-run pode rotular um passo como Skipped; trate os rótulos de History em produção como outra superfície se precisar do wording exato do status da execução.
Mantenha uma única ideia sim/não por pré-condição. Separe verificações não relacionadas em passos diferentes ou em automations separadas.
Linguagem natural (sim / não)
Escreva uma frase que o Dailybot possa tratar como verdadeira ou falsa. Você não precisa de código.
Check-in / standup
- O check-in menciona um bloqueio
- A pessoa disse que está bloqueada
- O humor está negativo ou frustrado
Formulários
- A resposta do formulário para “Precisa de follow-up?” é Sim
- A prioridade é High
Chat / mensagens
- A mensagem é sobre um incidente de produção
- O usuário pediu ajuda com código ou uma biblioteca
Pessoas / organização
- A pessoa é manager
- A pessoa está no time de Engineering
Tempo / dados de um passo anterior
- Há pelo menos uma resposta correspondente
- A lista de pessoas não está vazia
A linguagem natural funciona melhor quando uma pessoa consegue ler a regra em voz alta e concordar que é uma única afirmação verdadeira/falsa.
Lógica ({% if %})
Use {% if %} … {% endif %}. O passo roda somente se o if avaliar como verdadeiro.
Inserir variavel cola um placeholder como {{ response }} (com espaços dentro das chaves). Não cola um bloco {% if %}. Para a lógica, escreva as tags você mesmo e coloque a chave do seletor dentro do if (sem inventar nomes à mão).
No campo de pré-condição, a condição é a própria expressão. Mantenha o bloco mínimo, como no exemplo do builder:
{% if response %}
{% endif %}Outras chaves vêm de Inserir variavel para o gatilho atual e as saídas de passos anteriores. Exemplos do catálogo incluem chaves como trigger.user, trigger.message, response e result. Sempre pegue a chave no seletor da sua automation; as chaves disponíveis mudam com o gatilho e os passos anteriores.
{% if trigger.message %}
{% endif %}{% if result %}
{% endif %}Não envolva a condição em prosa extra nem em instruções dentro do if. Prefira Inserir variavel a digitar chaves de memória.
Para uma lista mais ampla de placeholders comuns em mensagens e ações, veja Referência de variáveis de automation. Confirme sempre a chave que o seu passo oferece no seletor antes de confiar nela em uma pré-condição.
O que escolher
| Você quer… | Use |
|---|---|
| Uma regra legível por humanos (“eles reportaram um bloqueio”) | Linguagem natural |
| Um valor específico do gatilho ou de um passo anterior | Lógica {% if %} com uma chave de Inserir variavel |
Se não tiver certeza, comece com linguagem natural. Passe para a lógica quando precisar que uma variável específica do seletor esteja presente ou seja verdadeira.
Erros comuns
- Escrever várias perguntas não relacionadas em uma única pré-condição. Separe-as.
- Assumir que uma condição falha só pula este passo e continua. A automation para naquele passo.
- Misturar um parágrafo inteiro de instruções com
{% if %}no mesmo campo. Deixe o campo apenas como a condição. - Digitar chaves de variáveis à mão em vez de usar Inserir variavel.
- Copiar chaves de exemplo de outra automation ou de um documento antigo que o seu seletor não lista.
Filtros em gatilhos e passos (não são pré-condições)
Janelas de tempo, canais, usuários, papéis, intervalos de datas e seletores semelhantes costumam ficar no gatilho ou nos campos próprios do passo (por exemplo um intervalo de datas em “Fetch records”, ou seletores de canal e usuários). Não são uma superfície de produto de “condições” separada, e não são a mesma coisa que a pré-condição em texto livre.
| Onde | O que faz | Exemplo |
|---|---|---|
| Gatilho | Decide se a automation inicia para um evento | Somente respostas de follow-up com bloqueio; agendamento em dias úteis |
| Campos do passo | Configuram as entradas daquele passo | Canal, usuários, intervalo de datas em um passo de fetch |
| Pré-condição do passo | Texto livre sim/não ou {% if %} para aquele passo |
{% if response %} ou “A prioridade é High” |
Use a seção Pré-condições quando a trava for uma regra em texto livre no passo. Use os seletores do gatilho e do passo quando o builder já oferecer um controle para aquele filtro.