Antes de construir, mapeie: o guia da Salesforce para discovery assistido por IA em orgs maduras
Um framework de três domínios para entender objetos customizados, automação e integrações antes de tocar em qualquer coisa
A Salesforce publicou um guia prático de discovery para orgs maduras, cobrindo objetos customizados, dependências de automação e integrações. É basicamente o checklist que todo arquiteto deveria rodar antes de qualquer projeto de modernização, só que agora com IA no meio do processo.
Toda vez que entro num projeto de org madura, a primeira pergunta que faço não é "o que vocês querem construir", é "o que já existe aqui e por quê". E a resposta, na maioria das vezes, é um silêncio constrangedor seguido de "boa pergunta, deixa eu chamar o time técnico".
Esse artigo da Salesforce coloca em papel algo que todo arquiteto experiente já faz de forma meio artesanal: um processo estruturado de discovery antes de qualquer decisão de arquitetura. A diferença é que aqui eles formalizam isso em três domínios de análise (objetos customizados, automação e integrações) e sugerem usar agentes de IA para acelerar o levantamento. Não é genial, mas é necessário, e a formalização importa mais do que parece.
Objetos customizados: nem tudo que existe merece continuar existindo
O framework propõe três níveis de resolução: avaliação no nível do org (quantos objetos existem, quais têm um único record type, onde há redundância tipo Contact__c, Contact2__c, Legacy_Contact__c), saúde do objeto (densidade de registros, complexidade de metadata, quantidade de triggers e flows ativos) e raio de dependência (quantas classes Apex, relacionamentos, relatórios e integrações dependem daquele objeto).
Isso é exatamente o tipo de análise que separa quem decommissiona um objeto legado com segurança de quem quebra produção em um sábado de manhã. Já vi objeto Legacy_Opportunity__c sendo usado por um único relatório executivo que ninguém lembrava que existia, mas que o CFO abria toda segunda-feira. Sem esse raio de dependência mapeado, você só descobre isso depois do desastre.
Automação: o campo minado que todo projeto de modernização encontra
A parte mais valiosa do artigo, na minha leitura, é o tratamento dado à automação. Eles descrevem cinco padrões clássicos de dívida técnica em automação: Workflow Rules e Process Builder ainda ativos (sim, ainda existem, e sim, ainda quebram coisa), lógica duplicada entre Flow e trigger disputando quem escreve por último, trigger stacking sem handler framework compartilhado, automações conflitantes escrevendo no mesmo campo em contextos diferentes, e dependências não mapeadas que chamam sistemas externos.
Se você já debugou um Record-Triggered Flow que dispara depois de um trigger Apex que já tinha disparado outro Flow que atualizava o mesmo campo que o Process Builder também tentava atualizar, sabe exatamente de que inferno estamos falando. O guia propõe mapear antes de tocar: quem escreve o campo, quem usa esse campo como condição, se existe callout externo e se há risco de governor limit pelo volume total de automação no objeto. É basicamente o checklist que eu gostaria que todo cliente tivesse antes de pedir "só mais um Flow rapidinho".
Integrações: volume e frequência importam mais que a lista de conexões
O terceiro domínio foca em algo que muita gente ignora: ter o inventário de Named Credentials, Connected Apps e API Catalog não diz nada sobre como essas integrações operam na prática. O ponto central é quantificar velocidade e volume, porque integrações de alta frequência (batch pesado ou rajadas de API) são amplificadoras de risco para qualquer feature nova, criando concorrência, record locking e governor limits que nunca aparecem em sandbox ou teste unitário isolado.
Esse tipo de discovery estruturado é o que evita que um projeto de modernização vire uma cirurgia às escuras. Arquitetos que pulam essa etapa (e são muitos) acabam desenhando o future state em cima de premissas erradas sobre o que o org atual realmente faz, e a fatura chega em produção.
Para quem trabalha com Revenue Cloud, CPQ ou qualquer domínio com muita automação acoplada, isso é ainda mais crítico: price rules, product rules e triggers de billing costumam se acumular em camadas ao longo de anos, e ninguém documenta a ordem de execução.
O artigo é o primeiro de uma série de duas partes e foca só no discovery, sem entrar no "como remediar". Vale acompanhar a segunda parte quando saír, porque a parte prática de execução (o toolkit de IA mencionado) ainda não foi detalhada.
Se você é arquiteto ou consultor entrando num org maduro, use os três níveis de objetos customizados como um checklist real antes de propor qualquer remoção ou refatoração: schema footprint, saúde do objeto e raio de dependência. Para automação, monte primeiro o inventário de quais objetos têm mais de um tipo de automação ativa disputando o mesmo evento ou campo, isso sozinho já revela 80% dos riscos escondidos.
Para integrações, não pare no inventário de Named Credentials e Connected Apps. Cruze isso com Apex classes e Flows que fazem os callouts, e levante volume e frequência real de chamadas antes de estimar o impacto de qualquer mudança no objeto que recebe esses dados.
O artigo é conceitual e não traz o toolkit de IA prometido no título, isso fica para a parte dois. Trate o conteúdo como framework de análise, não como tutorial passo a passo com prompts prontos.
Outro ponto: os critérios de "saúde do objeto" e "raio de dependência" fazem sentido teórico, mas a execução real depende de ferramentas de análise de metadata (nativas ou de terceiros) que nem todo org tem configuradas. Sem isso, o discovery vira trabalho manual arrastado.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.