Disparo da esteira e filtro de entrada

Como uma execução começa

Quatro caminhos: alguém aperta Executar, chega a hora marcada, um serviço conectado avisa que algo aconteceu, ou um sistema de fora chama pela API.

Filtro de entrada: nem todo evento merece uma execução

Um serviço conectado avisa muito mais do que interessa. O filtro de entrada é um conjunto de regras avaliado antes de a execução existir — evento que não passa simplesmente não vira trabalho, e não custa nada.

Quatro coisas que valem saber:

1. Vale só para o que dispara sozinho. Apertar Executar sempre roda, e chamada de fora também: o filtro é sobre o que o gatilho entrega, não sobre a decisão de uma pessoa nem sobre um sistema que pediu explicitamente.
2. O que o serviço conectado já fazia continua valendo — evento repetido, avisos em rajada e disputa entre entregas continuam sendo tratados antes, como sempre foram.
3. Na dúvida, a execução acontece. Se o próprio filtro falhar, o evento passa. Engolir um disparo legítimo por um problema nosso é pior que rodar uma vez a mais.
4. Todo descarte fica registrado, com o motivo já preenchido com os valores daquele evento — e a tela mostra quantos disparos o filtro cortou nas últimas 24 horas. Sem isso o filtro seria caixa-preta: ninguém descobriria que uma regra mal escrita está cortando evento legítimo. O registro fica por 30 dias.

O ponto 4 vale como regra geral: todo mecanismo que descarta em silêncio precisa de um lugar que mostre o descarte.

De quem é a conta que escuta o evento

Um gatilho de aplicativo numa esteira é criado sob a conta de quem clica em criar — não sob a conta de quem criou a esteira um dia. Faz sentido porque cada etapa da esteira roda sob o dono do seu agente, e quem criou a esteira não assina nada nela; até 17/09/2026 a regra usava a conta de quem criou a esteira, por engano de paridade com o gatilho de agente (esse sim usa a conta do dono, porque lá o dono assina as ferramentas do disparo). O sintoma do bug antigo: o assistente só oferecia os serviços que a própria pessoa tinha conectado, mas ao salvar o pedido saía em nome de outra conta — e o provedor de integrações recusava, tarde, dizendo que a conta não estava conectada. Gatilhos criados antes da correção continuam válidos.

Um punhado de eventos do catálogo de serviços conectáveis exige, além da conta, um endereço de webhook já existente para aquele serviço — sem ele a criação 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.

Os campos que a esteira aprende do gatilho

Um evento traz dezenas de campos internos do serviço para você usar dois. Depois do primeiro disparo, o editor passa a oferecer campo por campo, com o valor do último disparo como dica — você escolhe da lista em vez de adivinhar o nome.

Campo cujo nome a esteira não conseguiria usar não é oferecido. É coerência entre o que a tela promete e o que a execução entrega.

A lista pronta, antes do primeiro disparo

Diferente do aprendizado acima (que só existe depois que o gatilho já disparou ao menos uma vez), alguns campos de configuração do gatilho em si — pedidos já na hora de criá-lo, antes de qualquer evento acontecer — passaram a oferecer uma lista pronta em vez de um campo 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 ("entidade não encontrada"). Agora a tela busca as opções reais daquela conta antes de pedir a escolha; se a busca falhar ou o campo não tiver lista conhecida, volta a pedir o valor por texto, sem travar a criação do gatilho. A mesma lista vale tanto para gatilho de agente quanto para gatilho de esteira — é a mesma tela de configuração nos dois casos.

Erros do serviço conectado ao criar o gatilho também passaram a nomear o que exatamente foi recusado — a conta que não tem acesso, ou o valor de configuração escolhido — em vez de uma mensagem genérica.

Um interruptor para parar tudo

Existe um bloqueio geral que impede qualquer execução de começar — manual, agendada, por evento ou por ferramenta. Ele é um só, e isso é o ponto: um interruptor por caminho de disparo deixaria alguma porta aberta justamente no dia do incidente.

Disparo por sistema de fora

O quarto caminho: um sistema seu chama a esteira pela API pública, autenticado por chave da organização.

O disparo é sempre assíncrono, e não por limitação: uma esteira encadeia vários trabalhos de agente e pode levar horas. Quem chama recebe o identificador na hora e acompanha de duas formas — consultando o progresso quando quiser, ou registrando um endereço para ser avisado no fim.

Quatro coisas que não são óbvias por analogia com o botão da tela:

• O filtro de entrada não vale aqui. Ele existe para gatilho agendado e evento de serviço conectado. Chamada de fora entra sempre.
• Informação que a esteira esperava do gatilho chega vazia, sem erro. Se uma etapa cita algo que só um gatilho preencheria, aquilo vira vazio em silêncio — e a resposta do disparo lista o que faltou, para você descobrir na hora e não pelo resultado estranho três etapas depois. A mesma lista aparece na tela da esteira, ao lado do que a chamada de fato preenche.
• Repetir a mesma chamada não duplica a execução. Mandando a mesma chave de identificação, você recebe de volta a execução que já existe, com o estado atual dela — inclusive se ela tiver falhado. Não é uma resposta fixa: é o estado real, para você não ficar esperando por algo que já terminou mal.
• Chave restrita a certos agentes não dispara esteira que use outro agente. A restrição vale para a esteira inteira, e não só para a primeira etapa.

O que dá para fazer, e onde

Limites relacionados: cinco execuções ativas por esteira e dez gatilhos habilitados por esteira.