Trigger que suporta 200 registros sem estourar limite

Ajustei o código que cria pedidos de análise de crédito quando uma Oportunidade entra em revisão. Agora, o processo também consegue lidar com atualizações em lote, como a mudança de etapa de muitas Oportunidades de uma só vez, sem ultrapassar os limites de processamento da Salesforce.

Um trigger de Oportunidade criava um registro Credit_Review_Request__c quando a etapa mudava para Credit Review. Esse pedido reunia o nível de risco, o valor da Oportunidade e o contato principal. O processo funcionava quando poucas Oportunidades eram atualizadas, mas falhava quando uma operação em lote incluía muitas delas, por exemplo, mais de 150.

A causa estava na forma como o código consultava e salvava informações. Ele fazia consultas SOQL (busca de dados) e operações de DML (inserir, alterar ou excluir registros) dentro de um loop. Repetir essas operações para cada Oportunidade consome rapidamente os limites de recursos (Governor Limits) que a plataforma aplica a cada execução.

Esses limites existem para que uma única operação não use recursos em excesso, como tempo de processamento e memória, prejudicando outras tarefas na plataforma. Por isso, o código precisava tratar vários registros juntos, em vez de executar uma consulta e uma gravação para cada um.

Primeiro, reproduzi a falha com um teste que atualiza vários registros de uma vez. Como esperado, a operação em lote falhava e nenhum dos registros era salvo. Em seguida, movi a lógica para uma classe handler, uma classe que recebe o trabalho iniciado pelo trigger e organiza as etapas da regra de negócio, deixando o trigger responsável por iniciar o processo.

O handler reúne os IDs das Oportunidades e faz uma consulta para buscar as Contas relacionadas e outra para buscar os papéis de contato associados às Oportunidades. Guarda os resultados em estruturas Maps, que permitem localizar rapidamente cada registro pelo seu identificador. Depois percorre os dados já carregados, prepara todos os pedidos de revisão e faz um único save, fora do loop.

Também tratei os casos em que uma Oportunidade não tem contato principal e evitei criar mais de um pedido para o mesmo ciclo de revisão. Assim, consultas e gravações deixam de se repetir para cada registro individual.

O objetivo deste trabalho era corrigir o processamento em lote sem mudar a ferramenta que executa a automação. Migrar a lógica para Flow, a ferramenta declarativa Salesforce para automatizar processos, poderia ser uma opção para facilitar a leitura e a manutenção, mas também exigiria revisar o comportamento atual e verificar possíveis conflitos entre a automação nova e o código existente.

Preferi corrigir primeiro o problema observado e manter a migração fora deste escopo. Uma mudança para Flow poderia ser considerada depois, com testes e uma transição planejada para confirmar que as mesmas regras continuam sendo aplicadas.

Quando 150 Oportunidades mudam para Credit Review em uma única operação, o trigger reúne os dados necessários e cria um pedido de análise de crédito para cada uma. As consultas e o save no banco são feitas em conjunto, reduzindo o risco de atingir os limites de SOQL e DML do Salesforce.