ARTIGO // DATA: 13-07-2026

Quando uma automação falha

Uma automação pode trabalhar durante semanas sem chamar a atenção. Recebe dados e atualiza ferramentas. O problema aparece quando um destes passos falha e ninguém recebe um aviso.

Imagina um formulário que regista um pedido e cria um contacto no sistema comercial. Se o primeiro passo funcionar e o segundo falhar, a pessoa vê a mensagem de sucesso, mas o pedido pode não chegar à equipa. O processo parece concluído porque não existe nada a mostrar o contrário.

Cada execução deve deixar um registo

Uma automação que faz parte do trabalho diário deve guardar informação sobre o que aconteceu em cada execução. Não é preciso registar todos os dados recebidos. Aliás, guardar informação pessoal sem necessidade cria outro problema.

O registo deve permitir saber quando o processo começou, qual foi a referência tratada, que passos foram concluídos e onde surgiu o erro. Com estes dados, é possível perceber se houve uma falha isolada ou se todas as execuções estão a parar no mesmo ponto.

Este registo também reduz o tempo perdido a tentar reproduzir o problema. Em vez de começares por testar todas as ligações, vais ao passo que devolveu o erro e confirmas o que mudou.

O aviso tem de chegar a alguém

Guardar o erro não chega se ninguém o consultar. O processo deve enviar um aviso para o canal que a equipa acompanha, como o correio eletrónico ou a ferramenta usada para gerir tarefas.

Esse aviso deve identificar o processo, o passo que falhou, a hora e a referência afetada. Não deve incluir palavras-passe, chaves de acesso ou dados pessoais que não sejam necessários para resolver o problema.

Também convém definir quem recebe o aviso. Quando a responsabilidade fica distribuída por toda a equipa, é fácil cada pessoa assumir que outra vai tratar do assunto. Um processo importante precisa de uma pessoa responsável e de uma alternativa quando essa pessoa não está disponível.

Tentar novamente sem repetir trabalho

Algumas falhas duram poucos segundos. Uma ferramenta pode demorar a responder ou interromper uma ligação. Nestes casos, a automação pode voltar a tentar depois de um intervalo curto.

Mas repetir uma execução sem controlo pode criar dois contactos iguais ou enviar a mesma mensagem duas vezes. Antes de repetir, o processo deve confirmar o que já foi concluído.

Uma forma de o fazer é atribuir uma referência única a cada pedido. Quando a automação tenta retomar, verifica essa referência e continua a partir do passo em falta. Se uma ação já foi concluída, não a executa novamente.

O número de tentativas também deve ter um limite. Se o erro continuar, o processo para e envia o aviso. Caso contrário, uma automação pode ficar presa a repetir o mesmo pedido sem que ninguém perceba.

Testa o caminho do erro

É habitual testar uma automação com dados corretos e confirmar que o resultado chegou ao destino. Esse teste mostra apenas o caminho esperado.

Antes de dependeres do processo, desliga uma ligação de teste ou envia um dado inválido. Confirma se o erro fica registado e se o aviso chega à pessoa responsável. Depois, retoma a execução e verifica se o trabalho já feito não foi repetido.

Repete o teste quando uma ferramenta muda ou o processo ganha um novo passo. Uma alteração pequena pode mudar a ordem das ações ou retirar uma autorização usada pela ligação.

Uma automação precisa de mostrar o que aconteceu

O trabalho de uma automação não termina quando os passos são construídos. É preciso saber se continuam a funcionar e o que fazer quando deixam de funcionar.

Ao desenvolver uma automação ou uma integração, incluo o tratamento do erro no próprio processo. Defino o registo e o aviso. Depois, estabeleço como a execução pode ser retomada. É o mesmo princípio que expliquei no artigo sobre quando uma automação deve passar o pedido a uma pessoa: o processo tem de reconhecer os seus limites.

Se tens uma automação da qual depende o contacto com clientes ou o trabalho da equipa, podes consultar os meus serviços de automação e construção de sistemas. O primeiro passo é perceber onde um erro pode ficar escondido e como recuperar o pedido afetado.

Back_To_Blog() ID: #9