Em algum momento, alguém abre o Object Manager do Salesforce e perde a conta. Dezenas de custom objects, muitos com nomes parecidos, alguns sem dono claro, vários criados para resolver uma exceção específica que ninguém lembra mais. A pergunta que aparece é "como organizo isso". A pergunta melhor é "por que isso cresceu tanto".

Custom objects existem por bons motivos: estender o modelo de dados do Salesforce para o que o negócio precisa guardar. O problema raramente é o primeiro custom object. É o vigésimo, criado não para guardar um dado, mas para guardar uma regra.

Vale reconhecer o padrão. Quando uma decisão de negócio tem muitas variações (uma matriz de desconto por categoria, uma tabela de elegibilidade por perfil, um conjunto de faixas por região), a saída fácil dentro do Salesforce é criar um objeto para guardar essas linhas, e um pedaço de automação para lê-las. Funciona no começo. Só que aquilo deixou de ser dado e virou regra de negócio morando no modelo de dados do CRM.

Antes de organizar, um inventário ajuda a enxergar o que está acontecendo. Para cada custom object, três perguntas:

1. Isto guarda um dado do negócio (um cliente, uma apólice, um pedido) ou guarda um critério de decisão (uma faixa, uma matriz, uma condição)?

2. Com que frequência o conteúdo dele muda por mudança de política, e não por entrada de dado novo?

3. Quem precisa mudar esse conteúdo, e essa pessoa consegue fazer isso sem abrir um chamado?

Os objetos que guardam dado são o uso legítimo do Salesforce. Os que guardam critério de decisão, e mudam por política, e dependem de TI para mudar, são os que estão inflando o seu org sem precisar.

Nada disso é defeito do Salesforce. A flexibilidade do modelo de dados dele é uma força real, e é justamente por ser fácil criar objeto que a regra encontra ali um esconderijo confortável. O problema não é o recurso, é o uso: transformar matriz de decisão em tabela de dados, e espalhar a mesma decisão por vários objetos até ninguém ter mais a visão do todo.

Há um custo concreto nisso, além da bagunça visual. Cada edição do Salesforce tem limite de custom objects, e a proliferação consome esse teto. A mesma regra replicada em objetos diferentes não tem fonte única de verdade, então a manutenção precisa caçar todas as cópias. E não existe histórico da decisão como decisão: existe histórico de registros, que mistura mudança de política com entrada de dado.

A separação que organiza isso de verdade é tirar do modelo de dados o que é critério de decisão. A matriz de desconto, a tabela de elegibilidade, o conjunto de faixas deixam de ser custom objects e passam a viver em uma camada de decisão própria, que o Salesforce consome via API quando precisa do resultado. O CRM volta a guardar dado de cliente, apólice e pedido, que é o que ele faz bem. A regra passa a ter fonte única, versão, autor, critério e timestamp, e é editada pela área de negócio sem chamado.

Na prática, o Object Manager encolhe e para de crescer a cada exceção. A decisão deixa de estar espalhada e passa a ter um lugar. E a auditoria mostra a regra com o critério que a gerou, em vez de uma coleção de registros que alguém precisa interpretar.

Vimos esse movimento fora de um único setor. Uma financeira que guardava faixas de crédito em três objetos diferentes e descobriu que eles divergiam entre si. Um varejo que criava um objeto novo a cada campanha para as regras de desconto daquela campanha. Uma seguradora que mantinha critérios de aceitação por ramo espalhados em objetos paralelos. Em todas, o dado podia continuar no Salesforce; a matriz de decisão precisava sair do modelo de dados.

Sendo direto sobre o contrário: nem todo custom object é problema, e a maioria provavelmente não é. Objeto que guarda dado de negócio é exatamente para isso. O alvo é específico: o objeto que existe só para guardar critério de decisão que muda por política. Esse, sim, costuma estar no lugar errado.

A pergunta útil não é "como organizo meus custom objects". É "quais deles são dado e quais são regra de decisão disfarçada de dado". A segunda lista é a que merece sair do CRM.

Aprofundamos onde cada regra de negócio deveria morar no e-book [Onde mora a regra de negócio], e mostramos como essa camada opera ao lado dos seus sistemas em [IA em decisões críticas].