Primeiro, contenha o impacto
Ao perceber uma falha, confira se a automação continua executando ações incorretas. Se estiver criando duplicidades, enviando mensagens repetidas ou alterando dados indevidamente, avalie pausar o gatilho com o responsável pela operação. Preserve a configuração e os registros antes de qualquer alteração.
Não apague as execuções com erro para “limpar a fila”. Elas podem conter o horário, o identificador do evento e a resposta da ferramenta que ajudam a localizar a origem do problema. Também não compartilhe logs completos em canais abertos: eles podem incluir dados pessoais ou credenciais.
Diferencie atraso de falha
Um fluxo pode não estar parado: pode estar aguardando uma fila, um agendamento, uma aprovação ou uma nova tentativa. Verifique a frequência de execução configurada e o estado de cada etapa.
Compare o que era esperado com o que realmente aconteceu. “O cadastro não apareceu no CRM até o horário habitual” é uma observação mais útil do que “a integração está ruim”. Escolha um evento concreto e acompanhe seu caminho.
Localize a última etapa concluída
Use o histórico para responder três perguntas: o evento de entrada chegou, quais etapas terminaram e qual foi a primeira resposta inesperada? Uma execução marcada como falha pode já ter realizado ações antes de parar.
Imagine um fluxo que cria um contato no CRM e depois notifica a equipe. Se a notificação falhar, o contato pode já existir. Reexecutar tudo sem verificar o identificador pode criar outro cadastro. O ponto seguro de retomada depende de como o fluxo trata duplicidades.
- Horário e identificador da execução.
- Dados de entrada necessários para reproduzir o caso, com informações sensíveis removidas.
- Última etapa confirmada no sistema de destino.
- Mensagem de erro e código de resposta, quando disponíveis.
- Mudanças recentes em contas, campos, regras ou plataformas.
Investigue as causas mais comuns
Autenticação e permissões: tokens podem expirar, autorizações podem ser revogadas e contas podem perder acesso a um recurso. Respostas 401 ou 403 frequentemente apontam para essa categoria, mas precisam ser interpretadas conforme a documentação do serviço.
Mudança no formato dos dados: um campo foi renomeado, deixou de ser obrigatório ou passou a receber outro tipo de valor. Compare uma entrada que funcionou com a que falhou. Um valor vazio ou uma data em formato diferente pode interromper uma transformação.
Limites de uso: uma API pode restringir a quantidade de requisições ou a cota de um plano. Respostas 429 costumam indicar limitação de requisições. A solução pode envolver uma fila, um intervalo adequado ou ajuste de volume, respeitando a orientação do fornecedor.
Indisponibilidade e tempo de resposta: uma ferramenta externa pode estar fora do ar ou responder além do tempo esperado. Confira o status do serviço e o padrão das falhas. Repetir chamadas sem limite pode piorar o problema.
Regras e gatilhos: filtros, condições e agendas podem ter sido alterados. Verifique se o evento ainda atende às condições de entrada e se o webhook continua apontando para o destino correto.
Reproduza com o menor caso possível
Depois de preservar as evidências, teste uma entrada controlada em um ambiente separado ou em uma execução que não dispare ações reais. Use apenas os dados necessários para reproduzir o comportamento.
Mude uma variável por vez. Se você alterar credenciais, mapeamento de campos e filtros ao mesmo tempo, pode fazer a automação voltar sem saber o que resolveu o problema. Isso dificulta prevenir a repetição.
Quando o fluxo pode enviar mensagens, gerar cobranças ou alterar pedidos, a reprodução exige um cuidado adicional. Verifique se existe modo de teste e quem precisa autorizar uma execução com efeitos reais.
Corrija também o caminho da exceção
Uma correção não termina quando um único teste funciona. Verifique se a solução lida com dados incompletos, respostas inesperadas e falhas temporárias. As tentativas precisam ter limites e o erro deve chegar a alguém que consiga agir.
Use identificadores de origem para reconhecer eventos já processados quando a ferramenta permitir. Essa estratégia ajuda a evitar que a mesma solicitação gere ações duplicadas. Nem todo sistema oferece essa garantia pronta; ela precisa ser desenhada e validada no contexto da integração.
Registre o que mudou, qual cenário provocava a falha e quais testes foram executados. Esse histórico facilita uma investigação futura e a transferência de responsabilidade entre pessoas.
Faça uma retomada gradual
Antes de liberar toda a fila, confira uma pequena amostra e acompanhe os sistemas de destino. Defina quais eventos precisam ser reprocessados e quais já foram concluídos parcialmente. Não presuma que todos os registros com erro devem começar do zero.
A retomada deve incluir um plano caso o problema reapareça: quem pausa o fluxo, como preservar novas evidências e como manter a operação manualmente enquanto a investigação continua.
Quando pedir um diagnóstico
Se não há histórico suficiente, se a falha envolve vários sistemas ou se a reexecução pode gerar efeitos relevantes, vale organizar uma investigação antes de insistir nas tentativas. A causa pode estar fora da automação, como uma mudança ou limitação de um fornecedor.
Para conversar com a DevIA, envie uma descrição do fluxo, o comportamento esperado, quando o problema começou e quais ferramentas participam. Não envie senhas, tokens ou dados de clientes no primeiro contato. A forma de acesso e os exemplos necessários são definidos durante o diagnóstico.
Conheça o serviço relacionado
Integrações e correções