Tipos de triggers e lógica de condições
Uma visão estilo referência dos triggers de automação no Dailybot—agendas por tempo, ganchos orientados a eventos, regras condicionais e lógica composta AND/OR—com padrões para configurações complexas.
Automações são tão confiáveis quanto suas condições de entrada. Se o trigger for amplo demais, ruído invade o canal; se for estreito demais, eventos importantes nunca disparam. Este artigo percorre os tipos de trigger e a lógica de condições que vocês combinam ao construir fluxos sérios no Dailybot—pensem num mapa, não num manual clique a clique da UI.
Triggers baseados em tempo
Agendas estilo cron expressam “rodar nesses instantes do relógio” com padrões que o produto documenta para o workspace de vocês (semântica tipo minuto/hora/dia/mês/dia da semana). São ideais para digest, lembretes antes do fechamento de standup e tarefas de manutenção como arquivar threads antigos.
Intervalos recorrentes (“a cada N horas”) servem para sondagens leves ou heartbeats quando alinhar com o relógio de parede importa menos do que espaçar de forma estável. Em ambos os casos, definam um fuso horário explícito para times globais não levarem surpresa quando muda o horário de verão.
Triggers de tempo não leem o humor do time; apenas abrem uma janela para a automação avaliar se outras condições passam—muitas vezes junto com eventos capturados desde a última execução.
Triggers baseados em eventos
Check-in concluído dispara quando um participante envia ou quando uma rodada fecha—conforme a automação esteja configurada. Usem para confirmar envios, rotear bloqueios a um canal de triagem ou atualizar painéis.
Relatório de agente recebido liga automações a agentes de código ou tarefa que publicam resumos estruturados no Dailybot. Esse evento pode iniciar aprovações, criação de tickets ou avisos a gestores quando o relatório menciona palavras de risco.
Bloqueio detectado (ou sinais equivalentes do fluxo) escuta semântica ou campos que indicam impedimentos. Esses triggers são fortes para ops: transformam frustração não estruturada em trabalho roteado sem esperar um @mention manual.
Triggers de evento brilham quando vocês querem causalidade: algo aconteceu no sistema, então reajam agora—em vez de esperar o próximo tick de cron.
Triggers baseados em condições
Às vezes a agenda ou o evento é só metade da história. A lógica condicional filtra a carga: texto contém uma frase, escore de humor cai abaixo de um limiar, uma tag é customer-escalation ou um campo customizado bate com um valor.
Condições tornam as automações conscientes do contexto. Exemplo: “Quando o check-in conclui e o texto livre contém ‘outage’ e o time é Platform”. Sem condições, cada conclusão avisaria o mesmo lugar.
Atenção a maiúsculas, tokenização e idioma: casar “blocked” pode perder “bloqueado” a menos que vocês modelem padrões multilíngues ou usem campos estruturados em vez de substring crua.
Condições compostas: AND, OR e agrupamento
Políticas reais raramente cabem numa única cláusula. Construtores de automação no estilo Dailybot costumam permitir:
- AND: todos os predicados precisam passar (severidade alta e owner vazio).
- OR: qualquer predicado passa (palavra-chave “P1” ou campo prioridade igual a urgente).
- Grupos aninhados:
(A AND B) OR (C AND D)para matrizes de escalação.
Quando aninharem grupos, nomeiem em comentários ou documentação—o vocês do futuro não vão lembrar por que os parênteses estavam assim. Um padrão legível espelha a linguagem do runbook que o time de ops já usa (“acionar se impacto ao cliente e sem incident commander”).
Exemplo: padrões de configuração complexa
Caminho quente de incidente: evento = relatório de agente recebido; grupo de condição = (contém incident OR tag sev-1) AND business_hours == false; ação = acionar plantão e postar na sala de guerra.
Digest para gestor: tempo = cron dia útil 08:30; condição = “pelo menos um bloqueio nas últimas 24h para o time X”; ação = DM ao líder com links do rollup.
Portão de qualidade: evento = check-in concluído; condição = humor abaixo do limiar AND humor anterior também abaixo para o mesmo usuário (dois strikes); ação = template para agendar 1:1.
Esses exemplos ilustram composição: tempo abre a porta, eventos dão frescor e condições impõem proporcionalidade.
Disciplina operacional
Para qualquer conjunto de triggers não trivial, mantenham notas versionadas: quem é dono, o que quebra se desligarem e como testar. Usem staging quando existir. Triggers são código em forma de produto—tratem-nos com o mesmo respeito que hooks de deploy, e as automações permanecem rápidas, silenciosas e confiáveis.
FAQ
- Quais tipos de trigger as automações do Dailybot suportam?
- Famílias comuns incluem baseados em tempo (cron ou intervalos recorrentes), baseados em eventos (check-in concluído, relatório de agente recebido, bloqueio detectado) e regras condicionais que avaliam respostas ou escores—muitas vezes combináveis com lógica AND/OR.
- Posso combinar várias condições numa automação?
- Sim. Condições compostas permitem exigir vários predicados de uma vez (AND), caminhos alternativos (OR) e grupos aninhados—espelhando como times de ops expressam políticas reais de escalação.
- Onde documentar triggers complexos?
- Mantenham um runbook interno com a agenda, fontes de evento, expressões de condição, responsável e passos de rollback—para quem está de plantão mudar o comportamento sem engenharia reversa da interface.