A Resposta Concisa
Um bom modelo de dados no Salesforce não é o mais teoricamente elegante, mas sim aquele que harmoniza três elementos simultaneamente: o processo de negócio, o modelo de permissões e os relatórios necessários. A maioria dos modelos falhos concentra-se apenas no primeiro.
A diferença entre uma decisão de modelo e outras decisões de projeto reside no custo da mudança. Adaptar um Flow leva um dia; alterar o tipo de relacionamento entre objetos após dois anos de dados, automações e integrações é um projeto por si só. Portanto, o investimento na fase de planejamento é crucial aqui, mais do que em qualquer outro lugar.
A Primeira Regra: Comece Pelos Objetos Padrão
Account, Contact, Lead, Opportunity, Case e Product vêm com funcionalidades que não são gratuitas para objetos personalizados: processos de vendas, Forecasting, Entitlements, Omni-Channel, aplicativo móvel e integração nativa com outros produtos na plataforma.
Uma organização que cria um Customer__c em vez de um Account pode, inicialmente, ter um modelo que parece mais organizado, mas depois descobre que cada funcionalidade padrão exige construção independente. A regra é: desvie do padrão apenas se houver uma razão clara que possa ser articulada em uma única frase.
Quando um Objeto Personalizado é Necessário
| Cenário | Objeto Personalizado? | Justificativa |
|---|---|---|
| Contrato/Assinatura com ciclo de vida próprio | Sim | Status, renovação, propriedade e relatórios separados |
| Ativo instalado no cliente | Sim (ou Asset padrão) | Entidade independente com histórico de serviço |
| "Prospect" adicional | Não | Use Lead ou Account com Record Type |
| Departamento na organização | Não | Dado de usuário, não uma entidade |
| Linhas de preço complexas | Depende | Avalie Quote Line ou CPQ antes de construir |
Normalização Versus Desnormalização: A Escolha que Afeta os Relatórios
Em bancos de dados clássicos, a normalização é uma virtude. No Salesforce, ela é trocada pela facilidade de geração de relatórios: cada nível adicional de relacionamento dificulta a construção de relatórios sem ferramentas externas, pois os relatórios padrão são limitados pela profundidade dos relacionamentos.
O compromisso comum é a normalização onde os dados mudam e são duplicados, e uma desnormalização controlada de campos de consulta comuns no objeto a partir do qual os relatórios são gerados – desde que a duplicação seja gerenciada automaticamente e não manualmente. Um campo duplicado que é atualizado por entrada manual se torna obsoleto em questão de meses.
Permissões São Parte do Modelo, Não Uma Etapa Posterior
A pergunta "quem vê o quê" deve ser feita ao desenhar os objetos. Um modelo em que dados sensíveis residem no mesmo objeto que dados operacionais força soluções alternativas – objetos sombra, campos criptografados ou uma visibilidade excessivamente ampla.
O teste prático: para cada novo objeto, anote uma linha – quem é o proprietário, quem lê, quem modifica e o que acontece na hierarquia. Se a resposta exigir mais de quatro linhas, a estrutura provavelmente está misturando duas entidades.
Para mais informações sobre fontes de informação e autoridade de atualização, veja Source of Truth na organização, e sobre gestão de entidades principais em Master Data Management.
Cenário: Uma Empresa de Software Que Construiu um Modelo em Torno de Departamentos
Uma empresa SaaS de médio porte construiu um modelo com quatro objetos personalizados – um para cada equipe de vendas – porque cada equipe tinha um processo diferente. Um ano e meio depois, as equipes foram unificadas, exigindo a unificação de relatórios, automações paralelas em quatro locais e uma migração interna de 60 mil registros entre objetos.
A reconstrução baseou-se em um único Opportunity com Record Types para os diferentes processos. A mesma distinção de negócio foi mantida – diferentes pipelines de vendas, diferentes campos, diferentes Page Layouts – mas no nível da configuração e não no nível da estrutura. A próxima mudança organizacional exigirá uma mudança de Record Type, não uma migração.
A regra que surgiu disso: a estrutura representa entidades; a configuração representa a organização. O que é esperado mudar a cada dois anos não deve residir na estrutura.
Desempenho e Volume - O Que Realmente Importa
Problemas de desempenho em modelos de dados surgem principalmente de três fontes: Data Skew (um único pai com dezenas de milhares de filhos, por exemplo, o Account "Clientes Particulares"), fórmulas aninhadas que calculam em tempo real em múltiplos relacionamentos, e compartilhamento baseado em Apex Sharing criado em grande escala. Todos os três podem ser identificados na fase de planejamento se for perguntado quantos registros são esperados sob cada pai.
Riscos Comuns e Ações Preventivas
| Risco | Como se Manifesta na Prática | Ação Preventiva |
|---|---|---|
| Objeto Personalizado Desnecessário | Funcionalidades padrão são recriadas manualmente | Verifique os objetos padrão antes de criar um novo objeto |
| Master-Detail Precoce Demais | Exclusões em cascata e estrutura imutável | Comece com Lookup se não houver necessidade de Roll-Up |
| Modelo que Reflete a Organização | Cada mudança organizacional se torna uma migração | Use Record Types em vez de objetos |
| Data Skew | Bloqueios e lentidão em atualizações em massa | Distribuição equitativa de pais, verificação de volume no planejamento |
| Permissões como Pensamento Posterior | Soluções alternativas e visibilidade excessivamente ampla | Matriz de acesso para cada objeto no planejamento |
Como Medir o Sucesso
| Área | O que Medir | Frequência de Verificação |
|---|---|---|
| Uso de Campos | Taxa de preenchimento por campo | Trimestral |
| Relatórios | Porcentagem de relatórios que exigem consolidação manual | Trimestral |
| Estabilidade da Estrutura | Número de mudanças estruturais por semestre | Semestral |
| Desempenho | Tempos de atualização em massa e bloqueios | Mensal |
O planejamento do modelo de dados como parte de uma arquitetura abrangente é realizado no âmbito do serviço de integrações e dados.
Checklist Antes de Congelar o Modelo
- ☐ Para cada objeto personalizado, há uma justificativa em uma frase
- ☐ Foi verificado um objeto padrão alternativo para cada entidade
- ☐ O tipo de relacionamento foi selecionado explicitamente com uma justificativa para Master-Detail
- ☐ O volume esperado para cada pai foi estimado (teste de Skew)
- ☐ Matriz de acesso: proprietário, leitor, modificador, hierarquia
- ☐ Foi verificado que cada relatório central pode ser construído no modelo
- ☐ Campos duplicados são atualizados apenas automaticamente
- ☐ Mudanças organizacionais esperadas são tratadas na configuração
- ☐ Existe um ERD atualizado e documentado
- ☐ Foi determinado quem aprova futuras mudanças de estrutura
Recursos Profissionais
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data