Foto: Steve A Johnson / Unsplash
Automações
Montar automação que atualiza o mesmo registro que a dispara, sem filtro de controle, cria um loop que só para quando a cota acaba
Pedro Toledo · 4 de novembro de 2026 · 3 min de leitura
Montar automação que atualiza o mesmo registro que a dispara, sem filtro de controle, cria um loop que só para quando a cota acaba — porque a atualização feita pela própria automação conta como uma nova alteração e dispara o gatilho de novo, repetindo a ação até alguém interromper ou o limite da ferramenta ser atingido. Por que o fluxo funcionar no primeiro teste parecer prova de que está certo, o que caracteriza um fluxo protegido contra o loop, e como perceber se a automação reage às próprias alterações.
Ver a automação atualizar o registro certo no primeiro teste costuma parecer prova de que ela está correta. Olhar o histórico de execuções e procurar o mesmo registro aparecendo várias vezes seguidas revela se ela reage às próprias alterações.
Montar automação que atualiza o mesmo registro que a dispara, sem filtro de controle, cria um loop que só para quando a cota acaba — porque a atualização feita pela própria automação conta como uma nova alteração.
Por que o fluxo funcionar no primeiro teste parece prova de que está certo
O primeiro disparo faz o que se espera e o teste termina ali. O loop só aparece quando a atualização feita pela automação gera um novo evento e o gatilho "novo ou atualizado" reage a ele, de modo que o fluxo se repete até esgotar o limite de tarefas ou até alguém notar.
O que caracteriza um fluxo protegido contra o loop
Um fluxo protegido filtra os eventos gerados por ele mesmo e marca o que já foi processado. Isso tem relação direta com automação que reage a evento sem verificar se já foi processado gerar ação duplicada — os dois casos apontam pro mesmo princípio de fundo: a automação precisa saber se já tratou aquele registro, seja pra não repetir uma ação por causa de um evento duplicado, seja pra não se disparar de novo com a própria atualização.
O que a documentação e as comunidades descrevem
A ajuda da Zapier descreve que um Zap que atualiza o registro que o disparou entra num loop, e recomenda acrescentar dados únicos às ações que causam o ciclo e usar um filtro depois do gatilho. Respostas de comunidades sugerem um campo dedicado de "já processado", uma comparação entre dados novos e antigos e a escolha das colunas que disparam o gatilho. Não encontrei confirmação específica pro Make, onde o equivalente seria um filtro depois do gatilho.
Como perceber se a automação reage às próprias alterações
A forma prática é olhar o histórico de execuções. O mesmo registro aparecendo várias vezes em sequência, em intervalos curtos, ou um consumo de tarefas acima do volume real de dados são sinais de que o fluxo está se disparando sozinho, e vale pausá-lo, acrescentar o filtro e testar com um registro novo antes de reativá-lo.
Um exemplo prático
Uma empresa cria uma automação que, quando uma linha da planilha é alterada, calcula uma pontuação e a grava na mesma linha. A gravação conta como alteração, e o Zap roda sem parar até esgotar as tarefas do mês em poucas horas. Depois, a equipe define que o gatilho observe só as colunas de entrada, acrescenta um campo "processado" e um filtro que ignora linhas com o campo marcado.
O ponto central
Antes de ativar uma automação que escreve no mesmo lugar de onde lê, vale perguntar o que impede a escrita de disparar a leitura. Um fluxo que não sabe reconhecer as próprias alterações pode se repetir até a cota acabar.
