Resumo

  • Ao apagar um campo personalizado, o Salesforce remove seus atributos de unicidade e preenchimento obrigatório. Depois de restaurar, é preciso reaplicá-los quando necessários.
  • Fórmulas recuperadas ficam desativadas até serem editadas e salvas. Dependências removidas e algumas alterações de layout também exigem trabalho manual.
  • A recuperação termina com a exclusão permanente ou após 15 dias, o que acontecer primeiro. A pressão por liberar espaço para novos campos pode antecipar o fim dessa opção.

Se o contrato de recuperação termina quando os valores reaparecem na tela, ele pode terminar cedo demais. Uma empresa também usa os campos para impor condições: este dado precisa existir, aquele identificador não pode se repetir, esta conta deve produzir um resultado.

No Salesforce, essas funções não voltam todas na mesma viagem. A orientação oficial sobre restauração de atributos diz que a exclusão de um campo personalizado retira automaticamente os atributos de unicidade e obrigatoriedade. Após recuperar o campo, cabe configurá-los de novo, caso sejam necessários.

A diferença é comercialmente simples. O cliente pode receber de volta o lugar onde guarda a informação e ainda ter trabalho para recompor a regra que tornava essa informação confiável. Se ninguém atribuir esse trabalho a alguém, ele aparecerá mais tarde como surpresa no orçamento de operações.

O registro voltou. A recusa ao erro precisa voltar também

Pense num exemplo hipotético: um campo de referência de pedido cuja unicidade impedia que a mesma referência fosse usada duas vezes. Recuperar seus valores antigos mostra que os registros estão acessíveis. Não demonstra que esse atributo foi restabelecido. Outras validações podem existir, mas o controle que aquele atributo executava precisa ser identificado e conferido.

A exigência de preenchimento segue a mesma lógica. Uma série de registros antigos completos não diz como o sistema tratará o próximo registro vazio. O teste mais informativo pode ser justamente uma tentativa que deve falhar, feita com dados controlados num ambiente adequado.

Isso muda quem participa do aceite. O administrador domina a configuração. A pessoa que concilia os pedidos conhece o custo de uma referência ambígua. O responsável pelo processo sabe por que determinado conteúdo não podia ficar em branco. A recuperação precisa reunir esses conhecimentos, em vez de presumir que a existência da coluna encerra a conversa.

Se uma regra necessária continua ausente, a conta pode aparecer como correção de cadastro, análise de divergência ou repetição de uma tarefa. O chamado de recuperação estará encerrado; a recuperação econômica, ainda aberta. Para quem mede só o tempo de atendimento, o problema terá evaporado. Para quem limpa os dados, terá apenas mudado de sala.

Por isso, o aceite deve provar três coisas: o valor anterior pode ser lido, um novo valor correto é aceito e o que a regra proíbe é recusado. Um formulário que aceita qualquer coisa não ficou mais eficiente só porque deixou de reclamar.

A fórmula pode estar presente e fora de serviço

O guia de campos excluídos descreve outra tarefa pendente. Campos de fórmula voltam desativados, exibindo #Error! no lugar do resultado até que sejam editados e salvos. O salvamento aciona a verificação da sintaxe e exige resolver os erros encontrados.

Para uma área que usa o resultado calculado, recuperar a definição e voltar a receber o cálculo são entregas distintas. A planilha de controle do incidente deve acompanhar o resultado necessário ao trabalho, não só a presença do campo.

O nome de desenvolvedor também carrega a exclusão consigo. O Salesforce acrescenta _del, exceto quando já existe um campo excluído com esse nome, e o sufixo permanece após a restauração. O rótulo conhecido da tela não substitui a conferência do nome técnico e das configurações que o usam.

Já a busca pode levar um pequeno intervalo para mostrar novamente o campo e os dados. Esse atraso documentado tem de ser tratado como atraso de busca. Uma pesquisa bem-sucedida não atesta, por si, que as fórmulas e as exigências de entrada foram recompostas.

Há ainda mudanças ocorridas durante a ausência. O campo precisa ser recolocado nos layouts alterados enquanto estava excluído. Se relatórios e layouts não foram editados, o campo restaurado permanece neles. Dependências removidas devem ser redefinidas. O retorno de uma relação para mestre-detalhe exige dados adequados nos registros envolvidos.

Restaurar, portanto, envolve reencontrar uma configuração num ambiente que talvez já não esteja parado no mesmo ponto. Preservar a definição anterior e o registro das mudanças poupa uma investigação feita às pressas.

A pergunta “onde é usado?” não enxerga tudo

O recurso « Where is this used? » ajuda a localizar referências em fórmulas, layouts, Apex, regras de validação ativas e relatórios. É um bom ponto de partida antes de apagar ou modificar um campo. A documentação, porém, também delimita sua visão.

Alguns relatórios que usam o campo por meio de relações de chave estrangeira ficam de fora. Relatórios inacessíveis ao usuário que consulta não são retornados, e relatórios combinados não são suportados. Referências existentes dentro de um pacote gerenciado não aparecem na organização assinante; novas referências locais, criadas após a instalação, podem aparecer. A lista se limita às primeiras 2.000 entradas, ordenadas pelo tipo de referência.

Uma lista vazia não resolve uma investigação que também depende dos direitos de acesso e dos tipos de uso cobertos. É uma evidência com alcance definido. Transformá-la na assinatura de que o campo não tem dono nem utilidade deixa as partes menos visíveis para serem descobertas quando alguém reclamar.

O Salesforce mantém restrições à exclusão. Um campo referenciado por outro campo, por uma atualização de campo ou por Apex não pode ser excluído. Uma atualização em segundo plano também pode impedir o apagamento enquanto o trabalho estiver em andamento. Esses bloqueios tratam conflitos identificados; conhecer a função econômica do campo continua sendo tarefa da empresa.

A pressa por um campo novo pode enterrar o antigo

O campo e seus dados ficam disponíveis para recuperação até a organização excluí-los permanentemente ou até transcorrerem 15 dias, o que ocorrer primeiro. Essa janela é uma opção de retorno. Ela não inclui a reconstrução automática das regras.

Enquanto a exclusão definitiva não termina, o campo apagado continua consumindo a cota de campos personalizados e a cota aplicável ao seu tipo. Um projeto que precisa de novos campos pode querer encerrar a espera. Para a equipe responsável pelo processo antigo, a mesma espera pode ser a última chance de descobrir que apagou algo necessário.

A operação Purge encaminha os campos prontos para o processo de exclusão definitiva. Início e conclusão são etapas separadas. O prazo depende da demanda do sistema e pode ser acompanhado nas tarefas em segundo plano. A empresa pode abrir mão da recuperação antes de obter efetivamente a capacidade desejada.

Se persistirem erros de acesso ou falta de colunas limpas depois da exclusão permanente, o procedimento de suporte pede o identificador da organização, a indicação de produção ou ambiente de testes e autorização para a exclusão física. O texto informa que essa limpeza física de campos personalizados não pode ser limitada a um objeto: abrange a organização inteira. O erro que apareceu num objeto pode levar a uma autorização com alcance maior.

Para saber quais controles faltam num caso concreto, são necessárias as definições guardadas, as dependências e os resultados dos testes de aceite do negócio. O objetivo pode ser definido desde já: recuperar a capacidade de trabalhar com a informação e de barrar as entradas que aquela regra devia barrar. É uma entrega mais exigente do que fazer a coluna reaparecer. Também é mais útil.