Página visualforce idempotente

Ajustei a página usada para resolver um Caso, que é o registro de atendimento do Salesforce, para que uma segunda tentativa não crie outra resolução. Mesmo quando a tela demora e a pessoa clica novamente, o sistema mantém uma única resolução para aquele Caso.

A página Visualforce chamada “Resolver Caso” criava um registro Case_Resolution__c e fechava o Caso na mesma ação. Quando a tela demorava para responder, era natural a pessoa clicar de novo ou tentar novamente. Cada clique podia criar uma resolução, deixando mais de um registro para o mesmo Caso e um histórico difícil de conferir.

Desabilitar o botão depois do primeiro clique ajudava na tela, mas não resolvia a causa. Se a solicitação chegasse duas vezes ao servidor, o sistema ainda poderia gravar duas resoluções. A proteção precisava funcionar também no lado do Salesforce que processa e salva os dados.

Reproduzi a duplicidade e acompanhei o caminho desde a página até a controller extension, uma classe Apex que fornece à página a lógica necessária para executar ações no Salesforce. Mantive o botão desabilitado após o primeiro clique como uma resposta visual, mas garanti a proteção principal no servidor.

Para isso, cada resolução usa uma chave única baseada no identificador do Caso. O banco de dados não permite que essa chave seja gravada mais de uma vez, então duas solicitações para o mesmo Caso não criam duas resoluções. Antes de inserir um registro, o código também verifica se já existe uma resolução final. Se existir, retorna esse registro em vez de criar outro. Esse comportamento é chamado de idempotência: repetir a mesma solicitação produz o mesmo resultado, sem repetir a alteração.

A criação da resolução e o fechamento do Caso acontecem na mesma transação. Isso significa que o Salesforce confirma as duas mudanças juntas; se uma delas falhar, nenhuma fica salva pela metade. As permissões necessárias são declaradas explicitamente e, quando a pessoa não tem acesso, a página mostra uma mensagem compreensível em vez de um erro técnico bruto.

O objetivo era corrigir um defeito observado sem mudar o fluxo que as pessoas já conheciam. Migrar a página para LWC, a tecnologia mais recente do Salesforce para criar componentes de interface, ou substituir o processo por um Flow, exigiria rever o comportamento e testar uma mudança maior.

Como a falha podia ser corrigida na própria página, mantive a estrutura existente e concentrei a alteração na prevenção de registros duplicados. Assim, a correção resolve o problema sem transformar a modernização da tela em parte deste trabalho.

A pessoa solicita a resolução e, se a tela demorar, pode tentar novamente. O Salesforce verifica se aquela resolução já foi criada e devolve o mesmo registro em vez de gravar outro. Mesmo que as duas solicitações cheguem quase ao mesmo tempo, a chave única no banco impede que ambas criem uma resolução para o mesmo Caso.

Uma nova tentativa deixa de criar outra resolução para o mesmo Caso. A forma de resolver o atendimento continua a mesma, mas a gravação agora tem uma proteção no servidor e no banco de dados contra solicitações repetidas.