Salesforce é uma das plataformas mais poderosas do mercado, e também uma das mais personalizáveis. Essa combinação é excelente para construir soluções sob medida — mas carrega um risco silencioso que eu vejo se repetir em auditoria atrás de auditoria: a personalização excessiva, sem controle e sem documentação, que suga a escalabilidade da plataforma por dentro.
O sistema vai indo, vai indo, e de repente uma mudança relativamente simples — adicionar um campo, ativar uma automação, integrar um novo sistema — quebra algo que ninguém esperava. E aí você descobre que aquela regra de validação que alguém criou há dois anos interfere naquele Flow que foi adicionado no ano passado, que por sua vez conflita com a integração que entrou há seis meses.
À medida que sua operação cresce, a complexidade aumenta. Sem uma auditoria técnica periódica, é quase certo que gargalos, redundâncias e riscos se acumulem silenciosamente até estourarem em forma de falhas operacionais, baixa adoção ou retrocessos caros.
O que significa "escalar" em Salesforce?
Essa é a primeira pergunta que faço em diagnósticos. Muitas equipes pensam que escalar é só adicionar usuários. Na prática, escalar em Salesforce significa:
·Volume de dados: processar mais registros, mais transações, mais eventos sem degradação de performance. SOQL queries não otimizadas que funcionam bem com 50.000 registros começam a atingir limites com 500.000.
·Amplitude de equipes: adicionar novos times, regiões e linhas de negócio sem ter que refazer o que já existe. Isso exige que o modelo de dados seja genérico o suficiente para acomodar variações, não hardcoded para um único cenário.
·Profundidade de integrações: conectar novos sistemas sem criar dependências frágeis ou situações de "esse sistema só pode entrar se aquele estiver funcionando".
·Governança sob pressão: manter rastreabilidade, compliance e controle de acesso quando o número de usuários e perfis multiplica.
Se algum desses quatro eixos está comprometido hoje, o crescimento vai amplificar o problema — não resolvê-lo.
Área 1: Arquitetura de dados
A arquitetura de dados é a fundação. Quando está mal estruturada, tudo que vem em cima — automações, relatórios, integrações, IA — fica comprometido.
O que verificar:
Objetos e relacionamentos:
·Os objetos customizados têm nomes e finalidades claros, documentados? Ou há objetos como "Objeto_Customizado_2" que ninguém sabe para quê servem?
·Existem objetos duplicados fazendo a mesma função? É mais comum do que parece: dois objetos diferentes registrando o que deveria ser o mesmo conceito de negócio.
·Os relacionamentos (Lookup vs. Master-Detail) estão corretos para a natureza de cada relação? Um Lookup onde deveria ser Master-Detail compromete integridade de dados.
·Campos de texto livre onde deveriam ser picklists? Isso inviabiliza relatórios e automações confiáveis.
Performance de queries:
·Campos usados frequentemente em filtros de relatório e SOQL têm índice habilitado?
·Há relatórios sem filtros de data que rodam sobre objetos com milhões de registros?
·Há consultas SOQL em Apex sem cláusula LIMIT que podem estourar limites de governador?
Sinal de alerta: se qualquer relatório do Salesforce está sendo exportado para Excel para "cruzar com outras informações", há uma inconsistência de dados ou de arquitetura que precisa ser endereçada.
Área 2: Automações
O Salesforce tem múltiplas camadas de automação — Flows, Process Builders (ainda ativos em orgs mais antigas), Triggers Apex, Workflow Rules, Approval Processes — e cada uma tem suas características e limitações. O problema é que, ao longo de anos de implementação, essas camadas se acumulam e interagem de formas que ninguém projetou.
O que verificar:
Inventário e redundância:
·Existe um mapa de todas as automações ativas por objeto? Ou é necessário investigar cada objeto individualmente para saber o que está rodando?
·Há múltiplas automações fazendo a mesma coisa — por exemplo, atualizando o mesmo campo em Opportunity a partir de condições parecidas?
·Ainda há Process Builders ativos? A Salesforce está descontinuando essa tecnologia. Tudo deveria estar em Flow.
·Há Workflow Rules ainda ativos? Mesma situação.
Tratamento de erros:
·Os Flows críticos têm fault paths configurados? Um Flow sem fault path falha silenciosamente em muitos cenários.
·Há monitoramento de falhas de automação? Ou você descobre que o Flow quebrou quando o usuário liga reclamando?
·Existe ambiente de sandbox atualizado onde automações são testadas antes de ir para produção?
Limites e performance:
·Há Flows que rodam em contexto de usuário com volume alto sendo executados sincronamente quando deveriam ser assíncronos?
·Há recursividade em Triggers que pode causar loop?
Sinal de alerta: se a resposta para "posso adicionar uma nova automação nesse objeto?" é "melhor testar no sandbox primeiro porque a gente não sabe o que pode quebrar", há um problema de arquitetura de automações.
Área 3: Governança e segurança
Segurança no Salesforce é como uma cebola — tem muitas camadas. O problema é quando as camadas estão mal calibradas: muito permissivo cria riscos de compliance, muito restritivo cria usuários que "inventam" jeitos de contornar as restrições.
O que verificar:
Profiles e Permission Sets:
·O modelo de segurança usa Profiles como linha de base e Permission Sets para exceções — ou há dezenas de Profiles com pequenas variações entre eles?
·Usuários têm acesso a objetos e campos que nunca utilizam? Excesso de acesso é risco.
·Há revisão periódica de permissões? Ou uma vez configurado, nunca mais revisado?
Sharing Rules e visibilidade de dados:
·O Organization-Wide Default (OWD) de cada objeto está correto para a política de visibilidade da empresa?
·As Sharing Rules estão documentadas? Ou é necessário investigar para entender por que Usuário X consegue ver o registro Y?
·Há relatórios mostrando dados que não deveriam ser visíveis a determinados perfis?
Auditoria e rastreabilidade:
·O Setup Audit Trail está sendo monitorado? Mudanças de configuração em produção ficam registradas — mas alguém está olhando?
·Há Field History Tracking nos campos críticos (preço, estágio de oportunidade, status de contrato)?
Área 4: Qualidade de dados
Dados ruins escalam junto com o negócio — e o problema fica maior na mesma proporção. Uma taxa de duplicidade de 15% com 10.000 registros se torna um pesadelo com 100.000.
O que verificar:
Completude e consistência:
·Campos críticos — como email, telefone, segmento, tipo de conta — têm taxa de preenchimento acima de 80%?
·Há Validation Rules nos campos obrigatórios para o processo de negócio?
·As picklists têm valores "Outros" que acumulam tudo que não se encaixa? Isso é sintoma de categorias mal definidas.
Duplicidade:
·Há regras de duplicate management ativas para Leads, Contatos e Contas?
·A taxa de duplicidade foi medida recentemente? Qual é?
·Há processo de merge de duplicatas executado regularmente?
Dados legados:
·Há registros inativos, arquivados ou de teste misturados com dados de produção?
·Oportunidades fechadas há mais de 2 anos ainda aparecem em relatórios ativos?
Área 5: Integrabilidade
Integração é onde a complexidade explode. Cada sistema conectado é uma dependência, e dependências mal gerenciadas criam sistemas que "funcionam quando tudo funciona" — mas quebram de formas imprevisíveis quando qualquer peça tem problema.
O que verificar:
Documentação e monitoramento:
·Existe um mapa de integrações documentando: o que integra com o quê, qual a direção dos dados, qual a frequência e qual o que acontece em caso de falha?
·Há monitoramento ativo de falhas de integração? Ou você descobre quando o usuário percebe que os dados estão errados?
·Os limites de API estão sendo monitorados? Uma integração mal otimizada pode consumir toda a cota diária.
Resiliência:
·Há fallback quando uma integração falha? O registro fica em estado indefinido, gera erro visível para o usuário ou entra em fila de retry?
·Há idempotência nas integrações de entrada? Se a mesma mensagem for processada duas vezes, cria registros duplicados?
Como usar este checklist
Classifique cada item em: OK, Atenção, ou Crítico. Itens Críticos são os que podem quebrar a operação se não forem endereçados antes do crescimento. Itens de Atenção são débito técnico que vai cobrar juros com o tempo.
Se você encontrou mais de 5 itens Críticos, o próximo passo recomendado é uma auditoria completa com especialistas — não para descobrir o que está errado (você já sabe), mas para priorizar o que endereçar primeiro e criar um plano de remediação realista.
Perguntas frequentes sobre escalabilidade no Salesforce
Como saber se minha instância Salesforce está pronta para crescer?
Os sinais mais claros são: automações que quebram com frequência, relatórios que demandam exportação para Excel para serem úteis, usuários que preferem planilhas ao CRM, e qualquer mudança de configuração que exige testes extensos por medo de quebrar algo. Esses padrões indicam que a instância tem débito técnico que precisa ser endereçado antes do crescimento.
Com que frequência devo fazer uma auditoria técnica do Salesforce?
Para orgs em crescimento ativo, anualmente. Para orgs estáveis, a cada 18-24 meses — ou sempre que houver uma mudança significativa de negócio (fusão, novo produto, nova linha de negócio) que impacte os processos do CRM.
Quantos objetos customizados são aceitáveis em uma instância Salesforce?
Não há um número mágico — depende da complexidade do negócio. O problema não é a quantidade de objetos, é a falta de documentação e propósito claro para cada um. Orgs com 20 objetos mal documentados têm mais problema do que orgs com 80 objetos bem gerenciados.
O que é débito técnico em Salesforce e como ele se acumula?
Débito técnico são as decisões de curto prazo que criam custo de longo prazo: Triggers escritos sem testes, Flows duplicados, campos criados para "resolver agora" sem pensar na arquitetura, integrações sem monitoramento. Cada um desses itens individualmente é manejável; acumulados ao longo de anos, criam sistemas que ninguém quer tocar por medo de quebrar.
Quando vale a pena refazer vs. remediar uma instância Salesforce?
Raramente vale a pena refazer do zero. A maioria dos problemas é remediável com um plano de priorização bem feito. A exceção é quando o modelo de dados está fundamentalmente errado para o negócio atual — e mesmo aí, é possível migrar em fases.
