Tem um momento específico em projetos Salesforce que eu reconheço antes de ver qualquer configuração: é quando alguém diz "funciona, mas ficou complicado". Essa frase é o sintoma. O problema é que o crescimento revelou o débito técnico que estava escondido.
Sistemas que funcionam bem para 20 usuários, 5 produtos e 10.000 registros muitas vezes não funcionam bem para 100 usuários, 50 produtos e 500.000 registros. Não porque o Salesforce não aguentaria — aguenta. Mas porque as escolhas de arquitetura, automação e governança que pareciam razoáveis no início se tornam gargalos quando o volume e a complexidade aumentam.
Aqui na 3DES, analisamos implementações todos os dias e vemos um padrão consistente: sistemas que funcionam bem no início, mas que não aguentam o crescimento quando ele de fato chega. Este checklist é uma versão simplificada do que usamos em nossas auditorias de saúde do Salesforce.
Como usar este checklist
Para cada item, avalie como: Verde (ok, não precisa de atenção), Amarelo (atenção — débito técnico que vai cobrar juros) ou Vermelho (crítico — risco real de problema antes ou durante o crescimento).
Se você terminar o checklist com 3 ou mais itens Vermelhos, o crescimento planejado vai encontrar esses problemas — é questão de quando, não de se.
Área 1: Arquitetura de dados
A arquitetura de dados é a fundação. Problemas aqui amplificam tudo que vem acima.
Objetos e relacionamentos:
·Cada objeto customizado tem uma finalidade única e claramente documentada? Ou existem objetos como "Objeto_Temp", "Objeto_Antigo" que ninguém sabe para que servem?
·Os relacionamentos entre objetos são adequados para o volume esperado? Objetos com muitos filhos em relações Master-Detail precisam de atenção especial de performance.
·Há campos de texto livre onde deveriam ser picklists controladas? Texto livre impede filtragem confiável e dificulta automações.
·Campos de lookup circulares ou dependências entre objetos que tornam queries complexas?
Performance:
·Campos usados frequentemente em filtros de SOQL e relatórios têm índice customizado habilitado?
·Relatórios críticos rodam em menos de 10 segundos? Relatórios lentos são sintoma de queries mal otimizadas.
·Há rotinas de limpeza de dados obsoletos que evitam o crescimento indefinido de tabelas?
·Triggers Apex seguem as boas práticas (bulkified, sem SOQL dentro de loop)?
Sinal de escalabilidade: consiga criar um relatório com filtro em qualquer campo crítico do seu principal objeto e obtenha resultado em menos de 5 segundos. Se não conseguir, há problema de indexação ou volume.
Área 2: Automações sustentáveis
Automação é onde o Salesforce brilha — e também onde o débito técnico se acumula mais rápido. Cada Flow, Trigger e Process Builder adicionado sem documentação é um ponto de possível conflito futuro.
Inventário e organização:
·Existe um mapa de todas as automações ativas por objeto? Ou você precisa clicar em cada objeto para descobrir o que está rodando?
·Ainda há Process Builders ativos? A Salesforce está descontinuando essa tecnologia — tudo deveria estar migrado para Flow.
·Há Workflow Rules ativas? Mesma situação de descontinuação.
·Flows têm nomes descritivos que identificam o que fazem, para qual objeto e em qual contexto?
Qualidade técnica:
·Todos os Flows têm fault paths configurados? Um Flow sem tratamento de erro falha silenciosamente em produção.
·Há Flows com lógica duplicada — dois Flows fazendo a mesma coisa para condições ligeiramente diferentes?
·Triggers Apex têm testes unitários com cobertura mínima de 85% (acima do mínimo exigido de 75%)?
·Há Flows que rodam sincronamente em contextos de alto volume? (Ex.: Flow em Before Save em objeto com muitas atualizações simultâneas)
Ambiente de desenvolvimento:
·Existe sandbox atualizado onde automações são testadas antes de ir para produção?
·Há um processo de code review para Flows e Apex antes de ir para produção?
·Mudanças em produção são documentadas? Ou alguém "ajustou aqui" e ninguém sabe o que mudou?
Sinal de escalabilidade: você consegue descrever em menos de 2 minutos todas as automações que rodam quando um campo específico de Opportunity é atualizado? Se precisar "investigar" para responder, há automações não mapeadas.
Área 3: Governança e segurança
Com crescimento vem mais usuários, mais equipes, mais dados sensíveis e mais exigência de compliance. Governança mal estruturada escala como problema.
Profiles e Permission Sets:
·O modelo de segurança usa Profiles como linha de base e Permission Sets para exceções específicas — ou há dezenas de Profiles com pequenas variações entre eles?
·Há usuários com perfil de System Administrator que não precisam de todo esse acesso?
·Permission Sets são nomeados de forma descritiva e têm documentação do que habilitam?
·Há Permission Set Groups organizando Permission Sets relacionados?
Visibilidade de dados:
·O Organization-Wide Default (OWD) de cada objeto está configurado no nível mínimo necessário?
·Sharing Rules estão documentadas e revisadas nos últimos 12 meses?
·Há relatórios mostrando dados a perfis que não deveriam ter acesso?
·Field-Level Security está configurada nos campos sensíveis (financeiros, pessoais, contratuais)?
Onboarding e offboarding:
·Há um processo documentado para criar um novo usuário com as permissões corretas?
·Quando alguém sai da empresa, há um processo para garantir que o acesso é removido no mesmo dia?
·Usuários inativos com licenças ativas estão sendo monitorados?
Sinal de escalabilidade: um novo admin consegue onboarding de um novo usuário com o perfil correto sem precisar perguntar para alguém o que habilitar? Se não, o modelo de permissões não está documentado o suficiente.
Área 4: Qualidade e higiene de dados
Dados ruins escalam junto com o negócio. A duplicidade que é "manejável" com 10.000 registros se torna inviável com 200.000.
Prevenção na entrada:
·Há Validation Rules nos campos obrigatórios para o processo de negócio?
·Campos de picklist estão com valores controlados e sem opções "Outros" que acumulam tudo?
·Duplicate Rules estão ativas para os objetos críticos (Lead, Contact, Account)?
·Campos obrigatórios no sistema batem com campos obrigatórios no processo real?
Monitoramento ativo:
·A taxa de duplicidade dos principais objetos é monitorada regularmente?
·Há um processo periódico de limpeza de registros inativos, obsoletos ou de teste?
·Relatórios de qualidade de dados existem e são revisados com frequência?
·Campos críticos têm taxa de preenchimento monitorada?
Dados históricos:
·Registros de oportunidades fechadas há mais de 2 anos estão sendo arquivados ou excluídos para não inflar relatórios?
·Leads não trabalhados há mais de 6 meses têm processo de descarte ou arquivamento?
Sinal de escalabilidade: qual é a taxa de duplicidade dos seus Leads e Accounts? Se você não sabe responder, não está sendo monitorado. Se a resposta for "mais de 10%", é um problema que precisa de endereçamento antes de crescer.
Área 5: Documentação e conhecimento
O crescimento traz pessoas novas. Se o conhecimento sobre como a instância funciona está na cabeça de uma ou duas pessoas, você tem um risco operacional que se manifesta em rotatividade.
Documentação técnica:
·Há um documento de arquitetura da instância descrevendo os principais objetos, automações e integrações?
·Cada automação crítica tem documentação do que faz e por quê?
·Integrações com sistemas externos estão documentadas: o que integra, qual a direção, qual a frequência, o que acontece em falha?
Continuidade operacional:
·Um novo administrador Salesforce consegue entender o ambiente em 1-2 semanas sem depender das pessoas que implementaram?
·Há runbook para situações de emergência: o que fazer quando a integração com ERP para, quando um Flow crítico começa a falhar?
·Mudanças de configuração em produção são registradas com data, responsável e motivo?
Sinal de escalabilidade: peça para alguém da equipe que não implementou o sistema documentar como funciona o processo de criação de uma Opportunity do zero. Se a documentação produzida for incompleta ou incorreta, o conhecimento está nas pessoas, não nos processos.
O que fazer com os resultados
Maioria Verde: sua instância tem boa saúde técnica. Auditoria de manutenção anual é suficiente.
Mistura de Verde e Amarelo: há débito técnico presente, mas não crítico. Crie um backlog de remediação e endereça nos próximos 6-12 meses, em paralelo com o crescimento.
3 ou mais Vermelho: endereça antes de crescer. Esses itens vão se tornar crises operacionais quando o volume e a complexidade aumentarem.
Perguntas frequentes sobre escalabilidade no Salesforce
Qual a diferença entre este checklist e o anterior de "preparado para escalar"?
Este checklist foca na perspectiva da instância — o estado técnico atual da org. O checklist de escalabilidade de projeto foca no projeto e no processo de desenvolvimento. São complementares: um avalia o que existe, o outro avalia como está sendo construído e mantido.
Com que frequência devo fazer esse tipo de avaliação?
Anualmente para orgs estáveis, a cada 6 meses para orgs em crescimento ativo. Sempre que houver uma mudança significativa de negócio — expansão para novo mercado, novo produto, aquisição — é uma boa prática fazer uma avaliação antes de construir sobre a instância.
Posso fazer essa avaliação internamente ou preciso de uma consultoria?
Parte sim — especialmente os itens de qualidade de dados e governança, que não requerem conhecimento técnico avançado. Para os itens de arquitetura de dados e automações, ter um olhar externo especializado ajuda a identificar padrões de problema que uma equipe interna, por proximidade, pode não perceber.
Quanto tempo leva para remediar uma instância com problemas significativos?
Depende da gravidade e do volume. Orgs com 3-5 itens Vermelhos tipicamente levam de 3 a 6 meses para remediação completa, trabalhando em paralelo com as operações normais. Orgs com problemas estruturais profundos podem levar mais.
