Escolha o objeto certo

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 5 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Onde esses dados vivem? · Próximo: Campos também são arquitetura

A pergunta que este módulo responde: Que tipo de objeto Salesforce este conceito de negócio deve virar, e o que as licenças permitem?

Uma das coisas mais fáceis de fazer no Salesforce é criar um objeto personalizado. É exatamente por isso que acho que criamos objetos demais.

Você está numa sessão de requisitos e alguém diz: “Precisamos acompanhar nossos distribuidores.” Novo objeto personalizado: Distribuidor. Pronto. Só que quero que o arquiteto faça outra pergunta primeiro: o que é um distribuidor? É uma empresa. O Salesforce já tem uma forma muito boa de representar uma empresa. Ela se chama Conta. Isso não significa que a resposta seja sempre Conta. Mas se eu tiver de explicar por que uma empresa não é uma Conta, quero um motivo melhor do que “o negócio os chama de distribuidores”.

É aqui que o modelo lógico do capítulo 2 encontra a plataforma, e minha posição de partida é simples: se o conceito de negócio se encaixa de forma limpa no propósito pretendido de um objeto padrão, comece por ele.

Comece pelo significado

Mesmo quando algo merece ser um objeto, não merece automaticamente ser um objeto personalizado. Pergunte o que a coisa realmente representa. Uma empresa ou organização de qualquer forma? Comece pela Conta. Uma pessoa que trabalha com essa organização? Contato. Algo que um cliente possui ou comprou? Ativo. Algo que você está tentando vender? Agora a Oportunidade entra na conversa.

É por isso que olhamos primeiro para a nave-mãe, no módulo 2. Esses modelos não servem para todo negócio, mas não deveríamos ignorá-los porque construir os nossos parece mais limpo. Antes de New Custom Object (Novo objeto personalizado), pergunte como a Salesforce modela este conceito, o que foi construído em torno desse modelo, e do que você abriria mão ao substituí-lo.

O teste do encaixe limpo

Meu teste é uma pergunta: este conceito de negócio se encaixa de forma limpa no propósito pretendido do objeto padrão? Se sim, minha inclinação é pelo objeto padrão.

Um distribuidor é uma empresa com a qual temos um relacionamento, então a Conta é um encaixe limpo. Não me importa que os usuários chamem uma empresa de distribuidor, outra de fornecedor, outra de parceiro varejista e outra de cliente. São papéis de negócio, e não precisam de quatro objetos físicos. Nomes de negócio diferentes não significam automaticamente estruturas de dados diferentes. Um tipo, um tipo de registro ou um relacionamento podem carregar a diferença.

O teste também funciona na outra direção. No capítulo 1 deixei uma pergunta para você: a empresa de um cliente tem muitos locais de entrega. Cada local deveria ser uma Conta, ou um objeto personalizado?

Uma Conta dá muita coisa. Você ganha os campos de endereço, e tudo o que já espera um endereço de Conta: relatórios, mapas, integrações. Mas também ganha a sobrecarga: muitos campos, compartilhamento, hierarquia, propriedade, tudo o que pende de uma Conta, e quase nada disso tem a ver com um endereço separado. Você estaria carregando um monte de coisas pesadas que não vai usar, só para ter um endereço alternativo.

Um objeto personalizado, filho da Conta, pode ser leve: só os campos de endereço, um lugar para onde entregamos, com seu próprio ciclo de vida, que consigo controlar de forma independente.

Então é um equilíbrio: o peso que você assume contra o valor que você recebe. Se só preciso de um endereço com seu próprio ciclo de vida, é aí que vou para o personalizado.

O mesmo com subproblemas num caso. Se cada subproblema é mesmo um caso, trabalhado por um agente, com seu próprio status e nível de serviço, aninhe-os com o Caso pai do módulo 2. Mas se é só um item de checklist que ninguém trabalha como caso, um caso completo carrega muita coisa que nunca vai usar, e um filho personalizado simples pode pesar menos. Não porque o personalizado seja mais limpo. Porque o significado é diferente, ou o peso está errado.

Objetos padrão vêm com bagagem

Quando você escolhe um objeto padrão, está escolhendo mais do que os campos dele. Está escolhendo algo que os produtos da Salesforce já entendem: relatórios, automação, relacionamentos embutidos, recursos de produto, pacotes do AppExchange, e o que mais a Salesforce construir a seguir. Isso pode valer muito.

Objetos padrão também vêm com opiniões: comportamento existente, relacionamentos, considerações de segurança, às vezes requisitos de licença, e recursos de que você não precisa. Então “sempre use objetos padrão” não é a minha regra. Não tenho uma regra de “sempre”. Tenho uma inclinação: use o objeto padrão quando o significado for um encaixe limpo e o comportamento da plataforma em torno dele ajudar o design em vez de brigar com ele. Se eu passar cinco anos fazendo a Oportunidade se comportar como algo que não é uma oportunidade de venda, não ganhei nada por continuar no padrão. Só fiz a concessão errada na outra direção.

O Ativo é um bom exemplo

O Ativo (Asset) é um dos objetos padrão que as pessoas deixam passar. A forma mais simples que tenho de dizer: é uma coisa que o cliente tem. Talvez ele tenha comprado de nós, talvez não. Ainda me importo com o produto de um concorrente instalado no meu cliente, porque estou dando manutenção nele, ou tentando substituí-lo, ou preciso entender a base instalada dele. Se crio Customer_Product__c sem olhar primeiro para o Ativo, pulei uma pergunta de arquitetura. O Ativo não vence automaticamente, mas merece ser avaliado.

Contas pessoais: quando a pessoa é a conta?

No módulo 2 conhecemos as contas pessoais: uma conta e um contato num único registro, para clientes que são indivíduos. Agora, a decisão.

Minha posição: para B2C, é difícil viver sem elas. Vem tanta coisa pronta com Contas e Contatos que o custo e a sobrecarga valem a pena. E há um custo: cerca do dobro do armazenamento de uma conta empresarial, uma chave que você não consegue desligar, e algumas licenças externas não conseguem usá-las. A Partner Community não pode ser usada com contas pessoais (Experience Cloud User Licenses (opens in a new tab), em inglês). Então a pergunta não é “temos pessoas no nosso banco de dados?” Toda org tem pessoas. É “a pessoa é de fato a conta neste negócio?” Um Contato ser uma pessoa não o torna uma conta pessoal. O que decide é o relacionamento de negócio.

Click to enlarge

Agora deixe-me complicar tudo: licenciamento

Até aqui: encontre o conceito, procure o encaixe padrão mais limpo, vá para o personalizado quando o significado não encaixar. Agora a pergunta seguinte do arquiteto: quem precisa usar isto? Você pode projetar um modelo lindo e depois descobrir que metade das pessoas que precisam dos dados não está licenciada para os objetos que você escolheu. As licenças fazem parte do modelo de dados.

Três licenças internas

Comece pelo seu próprio pessoal. Dentro da empresa, há três tipos de licença que quero que todo arquiteto saiba de cor, porque eles determinam o que cada usuário consegue ver e fazer, e portanto com o que o seu modelo de dados pode contar.

Sales Cloud (agora Agentforce Sales). Esses usuários têm a licença de usuário Salesforce completa: objetos padrão de CRM, e qualquer aplicação padrão ou personalizada. São leads, oportunidades e previsões, além de contas e contatos, e até casos: um vendedor consegue ver os casos abertos de um cliente antes de uma ligação. Criar e executar campanhas exige mais uma peça, a licença de recurso Marketing User.

Service Cloud (agora Agentforce Service). A mesma licença de usuário Salesforce, configurada para atendimento. Os casos ficam no centro, trabalhados no Service Console: a licença de recurso Service Cloud User é o que abre o Salesforce Console for Service. É aqui que vivem os acordos de nível de serviço (SLAs), pelo gerenciamento de direitos (Entitlement) e pelos marcos (milestones), e é aqui que entra o Knowledge, que a maioria das edições compra como complemento.

Platform (Salesforce Platform). Para pessoas que precisam das suas aplicações personalizadas, não do CRM. Elas recebem contas, contatos, relatórios, dashboards, documentos e toda aplicação personalizada da org. O que não recebem: previsões, leads, campanhas e oportunidades. Custa menos, e é exatamente por isso que tantas aplicações personalizadas grandes rodam nela, e exatamente por isso que ela pode pegar o seu modelo de dados desprevenido.

	Sales Cloud	Service Cloud	Platform
Licença de usuário	Salesforce	Salesforce	Salesforce Platform
Feita para	Vender	Atender clientes	Aplicações personalizadas
Contas, contatos	Sim	Sim	Sim
Leads, oportunidades, previsões	Sim	Sim	Não
Casos	Sim, para ver os casos de um cliente	No centro, no Service Console	Não
Acordos de nível de serviço	Não	Sim, direitos e marcos	Não
Objetos e aplicações personalizados	Sim	Sim	Sim

Leia a tabela como um arquiteto lê. Se um grande grupo de usuários está na Platform, qualquer design que coloque o trabalho deles numa Oportunidade está quebrado antes de começar. Se os executivos precisam dos números de SLA, a licença deles decide se conseguem vê-los. Esses três tipos determinam o comportamento.

Click to enlarge

Quando a licença decide o objeto

A Oportunidade é a vítima que mais encontrei. Você viu na tabela: usuários da Platform não a recebem (Standard User Licenses (opens in a new tab), em inglês), e usuários da Customer Community também não conseguem trabalhar com ela. Então o requisito parece uma Oportunidade, alguém diz “vamos usar a Oportunidade”, e aí eu pergunto quem precisa de acesso. Se uma população grande está em licenças Platform ou Customer Community, a licença deixa de ser um detalhe de compras. É uma restrição de arquitetura, e normalmente empurra o design para um objeto personalizado.

Funciona para cima também. Em aula pergunto: o CEO quer dashboards bonitos; licença de Vendas ou de Serviço? Um usuário de Vendas consegue ver os objetos de vendas e até os casos, então para dashboards de vendas e contagem de casos abertos, Vendas serve. Mas no momento em que o executivo quer KPIs de SLA (quanto falta para um caso estourar seu nível de serviço), esses dados ficam em direitos (entitlements) e marcos (milestones), e o gerenciamento de direitos exige o Agentforce Service, antigo Service Cloud (Supported Editions for Service Features (opens in a new tab), em inglês). Agora você está fazendo upgrade das licenças dos executivos. Ouça o requisito de negócio, e saiba qual licença está por baixo dos dados de que ele precisa.

O estádio

Penso nas licenças como lugares num estádio. Todo mundo está assistindo ao mesmo jogo. Se compro os lugares caros no meio, vejo os dois times de perto. Se estou lá em cima no canto, na arquibancada, os assentos não são acolchoados e assisto de binóculo.

Essas são as licenças externas, para pessoas de fora da empresa: clientes e parceiros que fazem login num site do Experience Cloud. Há três que quero que você conheça.

Customer Community: a arquibancada. Feita para um grande número de usuários externos que precisam de casos e de base de conhecimento: um cliente acompanhando o seu caso de suporte. Os lugares custam cerca da metade e podem ir para um número enorme de usuários. O que você perde lá em cima? Relatórios, dashboards e a tabela de compartilhamento: o compartilhamento baseado em papéis que os níveis mais altos recebem. Ela funciona com contas pessoais.

Customer Community Plus: mais ou menos no meio do caminho. A Salesforce a descreve como a licença para usuários externos que precisam de relatórios, dashboards e compartilhamento padrão: um cliente que gerencia o acesso de outras pessoas, ou que precisa ver os seus números.

Partner Community: mais perto ainda, para business-to-business, com acesso aos dados de vendas. Os parceiros trabalham leads e oportunidades: registram negócios e fazem campanhas com você. É o lugar externo que alcança os objetos de vendas. Um porém: ela não pode ser usada com contas pessoais (Experience Cloud User Licenses (opens in a new tab), em inglês).

Click to enlarge

O erro é projetar como se todo mundo tivesse o ingresso caro, e então descobrir na implementação que a maioria dos seus usuários não consegue entrar no setor onde você colocou os dados deles. Aí você tem três escolhas: comprar outros lugares, mudar a experiência ou reprojetar o modelo. As três são arquitetura.

Como eles pagam muda o design

Há outra pergunta que as pessoas esquecem: como esses usuários vão fazer login? As licenças externas vêm em dois formatos. Por membro (member-based): você paga por usuário, o que serve para 500 parceiros que entram todo dia. Por login (login-based): você compra um número de logins por mês, o que serve para cinco milhões de clientes que entram poucas vezes por ano. Entrar mais de uma vez no mesmo dia ainda conta como um login (Experience Cloud User Licenses (opens in a new tab), em inglês).

Então, quando alguém diz “estamos construindo um portal do cliente”, minha próxima pergunta não é qual template. É: quem são os clientes, quantos são, com que frequência vêm, de que dados precisam, e o que podem fazer com eles?

Quando a licença molda o modelo

Às vezes a licença não escolhe só o objeto; ela dobra o modelo inteiro. Algumas licenças de plataforma limitam os usuários a uma aplicação personalizada com até dez objetos personalizados (Lightning Platform – One App, por exemplo; Standard User Licenses (opens in a new tab), em inglês).

Num projeto antigo, para uma grande empresa de serviços profissionais e construção, tivemos de construir algo como um LinkedIn para toda a força de trabalho: os cargos, habilidades, certificações, idiomas e projetos de cada pessoa, para que pudessem encontrar o construtor de pontes certificado num determinado país. Sem limite, eu teria construído um objeto usuário-cargo, usuário-habilidade, usuário-certificação, usuário-idioma e usuário-projeto, mais listas de referência de certificações e projetos. Com uma licença de dez objetos, e a orientação de não gastar todos, isso não era possível. Então virou um “adivinhe a música”: com quão poucos objetos consigo construir isto? A resposta foi dois. Um objeto de referência, com um tipo de registro para cada tipo de lista (cargo, habilidade, certificação, idioma, projeto), e um objeto de atributo do usuário, com os tipos de registro correspondentes, apontando para ele.

Não era o modelo ideal. Era um sofrimento para fazer relatórios, e eu teria preferido algo mais limpo. Mas era o que a licença permitia. Chamo esses de objetos canivete suíço: guarde o padrão no bolso de trás e, quando os limites não deixarem espaço, quebre o vidro e parta para a separação por tipo de registro. Só saiba do que está abrindo mão. Permissões diferentes por tipo de registro podem obrigar você a dividir o objeto de qualquer jeito.

As pessoas não são mais os únicos usuários

Mais uma pergunta de licenciamento ficou importante: e as coisas que não são pessoas? Integrações têm identidades. Agentes têm identidades. A Salesforce agora tem uma licença Salesforce Integration para integrações entre sistemas: só API, não para humanos, com cinco incluídas em cada org das edições Enterprise, Unlimited e Performance (Standard User Licenses (opens in a new tab), em inglês). Então não pergunte só quais usuários precisam de acesso. Pergunte quais identidades precisam de acesso: uma pessoa, um cliente, um parceiro, uma integração, um agente. E depois o que cada uma precisa ver e fazer.

Além do exame: o que a IA muda. À medida que os agentes viram mais um consumidor e criador de dados, a escolha de objetos e o licenciamento não dizem respeito só às telas humanas. Saiba com qual identidade o agente roda, o que essa identidade consegue alcançar, e se o modelo coloca os dados de que ele precisa atrás de um objeto ou permissão que ele não pode usar.

Steve Trucking: um fácil e um difícil

A Steve Trucking trabalha com Parceiros varejistas. O que é um Parceiro varejista? Uma empresa. Fácil: Conta. Não crio Retail_Partner__c porque alguém usou a palavra “parceiro”.

Agora o Destinatário, a pessoa que recebe a geladeira. Contato? Conta pessoal? Outra coisa? Um milhão de novos Destinatários por ano, que são clientes dos Parceiros varejistas, não nossos. É exatamente o tipo de pergunta em que não quero pular para um objeto antes de entender o relacionamento, o acesso e a escala. Vamos decidir isso no checkpoint da Parte 1.

O que um arquiteto decide aqui

• Se um conceito de negócio se encaixa de forma limpa no propósito pretendido de um objeto padrão, ou se seu significado ou peso é diferente.
• Se rótulos de negócio diferentes são entidades diferentes ou só papéis diferentes da mesma.
• Se cada pessoa, usuário externo, integração e agente que precisa dos dados consegue alcançar o objeto escolhido com as licenças planejadas.
• Como a população e o padrão de login (por membro ou por login) moldam a licença e o modelo.
• Quando um limite de licença justifica um modelo abaixo do ideal, e quanto essa troca custa em relatórios e permissões.

A questão não é que objetos padrão são bons e objetos personalizados são ruins. É que a escolha tem consequências, e às vezes ela não é decidida pelo substantivo, mas pelas pessoas, e pelas máquinas, que precisam usá-lo.

Para saber mais

• Salesforce Help, Standard User Licenses (opens in a new tab) (em inglês), consultado em 2026-10-02, reconsultado em 2026-10-12: usuários da Platform não têm direito a previsões, leads, campanhas e oportunidades; uma aplicação personalizada de até 10 objetos personalizados; cinco licenças Salesforce Integration em cada org da edição Enterprise.
• Salesforce Help, Experience Cloud User Licenses (opens in a new tab) (em inglês), consultado em 2026-10-02, reconsultado em 2026-10-12: a Partner Community não pode ser usada com contas pessoais; Customer Community Plus para relatórios, dashboards e compartilhamento padrão; vários logins num mesmo dia contam como um.
• Salesforce Help, Supported Editions for Service Features (opens in a new tab) (em inglês), consultado em 2026-10-02, reconsultado em 2026-10-12: acordos de nível de serviço (gerenciamento de direitos) com o Agentforce Service; o Knowledge é um custo adicional na maioria das edições.
• Salesforce Help, Available Feature Licenses (opens in a new tab) (em inglês), consultado em 2026-10-12: Service Cloud User, “Access the Salesforce Console for Service”; Marketing User para criar e gerenciar campanhas.