A consultoria que montou tudo foi embora, o dev que fazia os ajustes saiu, e agora algo quebrou. Ninguém na empresa sabe explicar por que aquele campo se preenche sozinho, de onde vem o e-mail que o cliente reclamou, ou o que acontece se você mexer no Flow errado. Assumir uma org nesse estado é menos programação e mais arqueologia: antes de consertar qualquer coisa, você precisa entender o que está vivo lá dentro.
Para assumir uma org Salesforce sem documentação, comece mapeando o que está ativo em produção antes de mudar qualquer coisa: objetos custom, Flows ativos, código Apex e permissões. Priorize o que roda automático e não tem teste, porque é ali que uma mudança inocente derruba produção. A primeira semana é para inventariar e ler log, não para consertar.
Por que a primeira semana é para olhar, não para consertar
A tentação de quem herda uma org quebrada é abrir o registro que deu problema e mexer até parar de reclamar. Numa org sem documentação, esse é o caminho mais rápido para transformar um bug em três. O Salesforce não executa suas automações de forma isolada: quando você salva um registro, dispara uma sequência inteira de regras de validação, triggers, Flows e fluxos de trabalho, numa ordem definida pela plataforma que se chama ordem de execução. Um Flow que preenche um campo pode disparar um trigger que recalcula outro, que por sua vez estoura uma regra de validação três camadas abaixo. Você mexe em um ponto e o efeito aparece em outro, sem nexo aparente.
O outro motivo para ir devagar é que numa org herdada você não sabe o que tem teste automatizado. No Salesforce, código Apex sem cobertura de teste não bloqueia só o deploy: ele esconde de você o que vai quebrar. Se a org tem uma trigger de 800 linhas escrita há três anos, sem um único teste, qualquer mudança que você faça é uma aposta. A primeira semana bem gasta é a que troca a pergunta "como conserto isso?" por "o que exatamente acontece quando um registro é salvo aqui?". Sem essa resposta, todo conserto é no escuro.
Passo 1: inventário do que está ativo em produção
Antes de julgar, catalogue. O objetivo do inventário é sair da sensação de "não sei o que tem aqui" para uma lista concreta do que existe e do que está ligado. Comece pelo Setup, na busca rápida, e levante quatro camadas:
- Objetos e campos custom. No Object Manager, veja quais objetos foram criados além dos padrão, e em cada objeto crítico (Conta, Oportunidade, Case) quantos campos custom existem e quais estão realmente em uso. Campo custom sem nenhum registro preenchido costuma ser resquício de um projeto abandonado.
- Flows ativos. Em Flows, filtre por status Ativo. Anote o objeto que cada um dispara e o gatilho (record-triggered, agendado, chamado por tela). Um Flow inativo não roda, mas ocupa espaço mental: separe o que está vivo do que é rascunho esquecido.
- Apex: classes e triggers. Liste as triggers por objeto e as classes que elas chamam. Aqui mora o comportamento mais difícil de enxergar pela interface, porque código não aparece na tela do usuário.
- Integrações. Em Connected Apps, Named Credentials e no monitoramento de API, veja o que entra e sai da org. Uma integração silenciosa que atualiza registros de fora é a causa mais comum de "esse campo mudou sozinho".
Faça esse inventário render um artefato, não só um olhar. Baixe os metadados com o Salesforce CLI e coloque tudo num repositório Git. O mesmo raciocínio que vale para versionar relatório e dashboard no Git vale para a org inteira: com os arquivos de metadata na sua máquina, você busca no código o que a interface esconde, compara versões e passa a ter um retrato datado do que existia antes de você tocar em nada.
Passo 2: mapear as automações que disputam o mesmo registro
Inventário pronto, o passo mais valioso é entender o que compete pelo mesmo objeto. Escolha o objeto que mais dói (quase sempre Oportunidade ou Case) e liste, num só lugar, tudo que dispara quando um registro dele é salvo: regras de validação, triggers Apex, Flows record-triggered e as regras antigas de workflow ou process builder que muita org ainda carrega em paralelo. É comum encontrar as três gerações de automação convivendo no mesmo objeto, cada uma escrita por uma pessoa diferente, nenhuma sabendo da outra.
Com essa lista, reconstrua a ordem de execução na mão. Isso responde perguntas que a interface nunca mostra: dois Flows escrevem no mesmo campo e brigam pelo último valor? Uma trigger dispara um Flow que dispara a mesma trigger de novo? Decidir a fronteira entre o que deveria ser Flow e o que deveria ser código é metade da briga, e vale reler quando usar Flow e quando usar Apex para julgar o que herdou. Para ver a sequência real acontecendo, ligue os Debug Logs num usuário de teste e salve um registro: o log mostra, linha a linha, a ordem em que cada automação rodou. É a diferença entre supor e ver.
Passo 3: achar o código sem teste e as automações órfãs
Agora você caça o que é risco puro. Dois tipos de coisa merecem uma coluna vermelha na sua planilha: o código sem cobertura de teste e a automação órfã, aquela que roda mas ninguém sabe para quê. Na tela de Apex Test Execution você vê a cobertura por classe. Uma trigger crítica com cobertura baixa é um alerta duplo: além do risco de quebrar, ela pode impedir você de fazer deploy de qualquer outra coisa, porque a plataforma exige um mínimo de cobertura para promover mudança para produção.
Automação órfã é mais sutil. É o Flow que envia um e-mail que ninguém entende, o campo de fórmula que referencia um objeto morto, a integração que grava numa tabela que não se lê mais. Para caçá-las, cruze o inventário com o uso real: um Flow ativo que não dispara há meses, uma classe Apex que nada chama, um workflow apontando para um perfil que não existe mais. Aqui ajuda instrumentar antes de apagar. Colocar um log estruturado no Flow para depurar em produção mostra se aquela automação suspeita ainda roda de verdade, e com que frequência, antes de você decidir o destino dela. Desligar automação às cegas numa org viva é como cortar um fio sem saber onde ele vai dar.
Passo 4: reconstruir o mapa de acessos
Quem pode ver e fazer o quê é a parte da org que menos aparece e mais assombra numa auditoria de segurança. Numa org sem documentação, o acesso costumou crescer por remendo: alguém precisava de um campo, ganhou um perfil inteiro; outro precisava de um botão, virou administrador. O resultado é gente vendo dado que não deveria e ninguém sabendo por quê. Reconstruir esse mapa é entender de onde vem cada permissão, e no Salesforce ela vem de muitos lugares somados (perfil, permission sets, permission set groups, papéis na hierarquia, regras de compartilhamento).
Rastrear isso perfil por perfil, no clique, leva dias. Foi exatamente essa dor que me levou a construir uma extensão que abre as permissões de um usuário de uma vez, porque a resposta para "por que esse usuário vê esse registro?" quase nunca está num lugar só. Ao herdar a org, o alvo não é reescrever a segurança no primeiro dia, é ter o retrato: quem é administrador, quais perfis são cópias inchadas um do outro, e onde um permission set group resolveria o que hoje são dez perfis quase iguais. Esse retrato é o que permite, depois, enxugar o perfil inchado com calma, sem tirar acesso de quem precisa no meio do expediente.
Refatorar ou conviver: como decidir sem reescrever a org
Com o mapa na mão, chega a decisão que separa a sustentação sã da reescrita traumática. O instinto de engenheiro é limpar tudo, reescrever a trigger feia, unificar os Flows. Numa org de produção com gente trabalhando, esse instinto é caro. A régua honesta tem três perguntas, e você refatora só o que responde sim a pelo menos uma:
- Isso quebra de forma recorrente? Automação que gera chamado toda semana é candidata legítima. Uma que roda torto mas ninguém percebe há dois anos pode esperar.
- Isso me bloqueia de entregar o que preciso agora? Se a cobertura baixa de uma classe impede o deploy da mudança que o cliente pediu, essa classe entrou na fila por consequência, não por gosto.
- Isso roda sem teste em cima de algo crítico? Código sem cobertura sobre faturamento, comissão ou fechamento de negócio é dívida que cobra juros. Cobrir com teste vem antes de mudar, sempre.
O que não responde sim a nenhuma dessas você documenta e deixa quieto. Automação que funciona, ninguém entende e raramente muda não é prioridade, é item de backlog. Reescrever a org inteira de uma vez é a forma mais confiável de trocar bugs velhos e conhecidos por bugs novos e surpresa. A ordem que dá menos susto é estabilizar, cobrir com teste o que é crítico, e mudar por partes pequenas e reversíveis. Essa disciplina de mexer pouco e medir é o que mantém o custo mensal de sustentação previsível, em vez de virar um projeto de reforma sem fim.
O que aprendi auditando a org da Vetra
A Vetra Distribuidora é a empresa fictícia que uso como org de demonstração deste portfólio, e mesmo sendo uma org que eu mesmo montei, ela me ensinou o tamanho do problema de quem herda uma de verdade. Ao voltar a um objeto custom depois de semanas, precisei parar e reconstruir na mão qual automação escrevia em qual campo, porque campo custom novo em objeto que já existia às vezes nem materializava na interface do jeito esperado, e a única forma de confiar no que estava lá era consultar os metadados direto pela API, não pela tela.
A lição que carrego para o cliente veio daí: a interface do Salesforce mente por omissão. Ela mostra o que está configurado, não o que está acontecendo. Numa org herdada, a verdade está no metadado versionado, no Debug Log da ordem de execução e na cobertura de teste, não na tela bonita que o usuário vê. Por isso o primeiro entregável de uma sustentação que assumo nunca é um conserto, é um mapa: o inventário do que existe, a lista do que é risco e a recomendação do que refatorar, conviver ou desligar. Consertar sem esse mapa é o que transformou a org do cliente na bagunça que ele me chamou para arrumar. A diferença entre sustentar e apagar incêndio é ter o retrato antes de tocar no primeiro fio.
Perguntas frequentes
Por onde começar ao assumir uma org Salesforce sem documentação?
Comece mapeando o que está ativo em produção antes de mudar qualquer coisa: objetos e campos custom, Flows ativos, classes Apex e triggers, integrações via API e o modelo de permissões. A prioridade é achar o que roda automático e não tem teste, porque é ali que uma mudança inocente derruba produção. A primeira semana é para inventariar e ler log, não para refatorar.
Como descobrir todas as automações ativas numa org Salesforce?
Combine três fontes: a tela de Flows em Setup filtrada por ativos, a lista de Apex Triggers por objeto, e as regras antigas de workflow e process builder que ainda podem coexistir. Para um objeto crítico como Oportunidade ou Case, liste tudo que dispara nele e monte a ordem de execução na mão. Um retrieve via Salesforce CLI baixa os metadados e deixa você buscar no código o que a interface esconde.
Vale a pena refatorar uma org Salesforce herdada ou conviver com o que existe?
Depende do risco e da frequência de mudança. Automação que funciona, ninguém entende, mas raramente muda, você documenta e deixa quieta. O que refatora primeiro é o que quebra recorrente, o que bloqueia mudanças novas, ou o que roda sem teste em produção. Reescrever a org inteira de uma vez costuma introduzir mais bug do que resolve. Estabilize, cubra com teste, e só então mude por partes.
Quais ferramentas ajudam a mapear uma org Salesforce sem documentação?
O próprio Setup com a busca rápida, o Salesforce CLI para baixar os metadados e versionar, os Debug Logs para ver a ordem de execução real, e o Optimizer e o Security Health Check para achar itens ociosos e riscos. Para o modelo de acessos, uma ferramenta que abra as permissões por usuário economiza dias de clique manual por perfil e permission set.