Gatilhos de aplicativo (evento externo)

Camada funcional

Além de horário, um gatilho pode disparar a partir de algo que aconteceu num serviço conectado: e-mail novo, arquivo criado, mensagem recebida. A organização escolhe o serviço, o tipo de evento e a mensagem que o agente recebe quando ele acontece.

O catálogo de eventos é vivo

Os serviços que oferecem gatilho e os tipos de evento de cada um vêm do motor de integrações, não de uma lista fixa da plataforma — o mesmo desenho usado no catálogo de serviços conectáveis. Consequência prática: evento novo de um serviço já conectado passa a estar disponível sem esperar uma atualização da plataforma.

Entrega repetida não roda o agente duas vezes

Provedores de webhook reenviam a mesma entrega quando não recebem confirmação a tempo — isso é comportamento normal do lado deles, não falha. A plataforma reconhece a entrega repetida e não roda o agente de novo para ela.

Isso é diferente de eventos genuinamente distintos sobre o mesmo item, que podem chegar em sequência rápida — por exemplo, uma criação seguida de uma remoção do mesmo arquivo. Esses são dois acontecimentos reais, e os dois chegam ao agente; a plataforma não os trata como repetição um do outro.

Quando o próprio evento não carrega nenhuma forma de identificar de qual item ele fala, a plataforma não tenta adivinhar: prefere processar um evento a mais do que arriscar descartar um aviso legítimo que se repete de propósito.

Um episódio real

Já houve um caso de entrega duplicada num canal de mensagens: a mesma notificação de um gatilho chegou multiplicada no chat, mesmo com a interface mostrando só uma mensagem final. O caso foi identificado e corrigido.

O endereço de webhook que alguns eventos exigem

Um punhado de eventos do catálogo de serviços conectáveis exige, além da conta conectada, um endereço de webhook já cadastrado para aquele serviço — sem ele, a criação do gatilho era recusada só no último passo do assistente, depois de a pessoa montar o gatilho inteiro. Desde 17/09/2026 esse endereço é providenciado quando faz falta: a recusa não aparece mais, e não há nada a configurar no provedor. Vale tanto para quem cria pelo painel do agente quanto para quem usa a ferramenta de gestão de gatilhos de dentro de um agente.

Ter um endereço não bastava para o evento chegar (21/09/2026)

Providenciar o endereço fecha só a metade do caminho: um gatilho podia ser criado sem nenhum erro, aparecer ativo e mesmo assim nunca disparar, porque faltavam dois passos que só o serviço externo sabe fazer — registrar de fato um aviso apontando para aquele endereço, e reconhecer quem está mandando o aviso. Sem os dois, o serviço simplesmente nunca chegava a avisar a plataforma, e nada na tela distinguia isso de "ainda não aconteceu nada para disparar".

Desde 21/09/2026, os dois passos são fechados automaticamente ao criar o gatilho, e revisados a cada hora para o caso de algo ter sido desfeito do lado de fora (por exemplo, alguém apagando o aviso no painel do próprio serviço). Gatilhos que compartilham o mesmo serviço, a mesma conta e o mesmo tipo de evento reaproveitam um único registro — não é um passo a mais por gatilho.

Quando algum dos dois passos não pode ser fechado sozinho (o serviço ainda não sabe fazer isso, ou pede uma informação que só quem administra a conta naquele serviço tem), o gatilho continua sendo criado, mas a tela avisa explicitamente: "Gatilho criado, mas ainda não recebe eventos", com o motivo. Não é mais um silêncio indistinguível de "nada aconteceu ainda".

O registro automático só passou a fechar de fato em 22/09/2026. Ele chegou em 21/09 junto com o aviso na tela, mas uma falha no caminho até o serviço fazia a tentativa morrer sempre na última etapa — o gatilho ficava marcado como "ainda não recebe eventos" rodada após rodada, sem que a revisão de hora em hora conseguisse resolver. Desde 22/09 ele fecha.

A lista pronta, antes do primeiro disparo

Alguns campos de configuração pedidos já na hora de criar o gatilho — não depois que ele já disparou — passaram a oferecer uma lista pronta em vez de texto livre. O primeiro caso (19/09/2026) é escolher um time dentro do Linear: antes, o campo pedia um identificador que a pessoa não tinha como saber de cabeça e o serviço recusava o gatilho com um erro técnico; agora a tela busca as opções reais daquela conta antes de pedir a escolha; se a busca falhar, o campo volta a aceitar o valor digitado, sem travar a criação. Erros de criação também passaram a nomear o que exatamente foi recusado — a conta, ou o valor de configuração escolhido.

O que dá para fazer