Escolha o objeto certo

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 com IA. Ainda não revisto 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 sustenta-se sozinho. Anterior: Onde vivem estes dados? · Próximo: Os campos também são arquitetura

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

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

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

É aqui que o modelo lógico do capítulo 2 encontra a plataforma, e a minha posição de partida é simples: se o conceito de negócio 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 representa realmente. Uma empresa ou organização de qualquer tipo? Comece pela Conta. Uma pessoa que trabalha com essa organização? Contacto. Algo que um cliente possui ou comprou? Ativo. Algo que está a tentar vender? Agora a Oportunidade entra na conversa.

É por isso que olhámos primeiro para a nave-mãe, no módulo 2. Esses modelos não servem para todos os negócios, mas não os deveríamos ignorar só 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 à volta desse modelo, e de que abdicaria ao substituí-lo.

O teste do encaixe limpo

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

Um distribuidor é uma empresa com a qual temos uma relação, por isso a Conta é um encaixe limpo. Não me importa que os utilizadores chamem a uma empresa distribuidor, a outra fornecedor, a outra parceiro retalhista e a outra 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 registo ou uma relação podem carregar a diferença.

O teste também funciona na outra direção. No capítulo 1 deixei-lhe uma pergunta: 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. Fica com os campos de morada, e com tudo o que já espera uma morada de Conta: relatórios, mapas, integrações. Mas também fica com a sobrecarga: muitos campos, partilha, hierarquia, propriedade, tudo o que está pendurado numa Conta, e quase nada disso tem a ver com uma morada separada. Estaria a carregar um monte de coisas pesadas que não vai usar, só para ter uma morada alternativa.

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

Por isso é um equilíbrio: o peso que assume contra o valor que recebe. Se só preciso de uma morada com o 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 o seu próprio estado e nível de serviço, aninhe-os com o Caso principal do módulo 2. Mas se é só um item de uma lista de verificação 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 escolhe um objeto padrão, está a escolher mais do que os seus campos. Está a escolher algo que os produtos da Salesforce já entendem: relatórios, automação, relações incorporadas, funcionalidades de produto, pacotes do AppExchange, e o que mais a Salesforce construir a seguir. Isso pode valer muito.

Os objetos padrão também vêm com opiniões: comportamento existente, relações, considerações de segurança, às vezes requisitos de licença, e funcionalidades de que não precisa. Por isso «use sempre 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 à sua volta ajudar o design em vez de lutar contra ele. Se passar cinco anos a obrigar a Oportunidade a comportar-se como algo que não é uma oportunidade de venda, não ganhei nada por ficar no padrão. Só fiz a cedência errada na outra direção.

O Ativo é um bom exemplo

O Ativo (Asset) é um dos objetos padrão que as pessoas deixam escapar. A forma mais simples que tenho de o dizer: é uma coisa que o cliente tem. Talvez a tenha comprado a nós, talvez não. Continuo a importar-me com o produto de um concorrente instalado no meu cliente, porque estou a fazer-lhe a manutenção, ou a tentar substituí-lo, ou preciso de entender a sua base instalada. Se crio Customer_Product__c sem olhar primeiro para o Ativo, saltei uma pergunta de arquitetura. O Ativo não ganha automaticamente, mas merece ser avaliado.

Contas pessoais: quando a pessoa é a conta?

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

A minha posição: para B2C, é difícil viver sem elas. Vem tanta coisa pronta com as Contas e os Contactos que o custo e a sobrecarga valem a pena. E há um custo: cerca do dobro do armazenamento de uma conta empresarial, um interruptor que não consegue desligar, e algumas licenças externas não as conseguem usar. A Partner Community não pode ser usada com contas pessoais (Experience Cloud User Licenses (opens in a new tab), em inglês). Por isso a pergunta não é «temos pessoas na nossa base de dados?» Todas as orgs têm pessoas. É «a pessoa é de facto a conta neste negócio?» Um Contacto ser uma pessoa não faz dele uma conta pessoal. O que decide é a relação 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 de usar isto? Pode projetar um modelo lindo e depois descobrir que metade das pessoas que precisam dos dados não está licenciada para os objetos que escolheu. As licenças fazem parte do modelo de dados.

Três licenças internas

Comece pelas suas próprias pessoas. Dentro da empresa, há três tipos de licença que quero que todos os arquitetos saibam de cor, porque determinam o que cada utilizador consegue ver e fazer, e portanto com o que o seu modelo de dados pode contar.

Sales Cloud (agora Agentforce Sales). Estes utilizadores têm a licença de utilizador 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 contactos, e até casos: um vendedor consegue ver os casos abertos de um cliente antes de uma chamada. Criar e executar campanhas exige mais uma peça, a licença de funcionalidade Marketing User.

Service Cloud (agora Agentforce Service). A mesma licença de utilizador Salesforce, configurada para o apoio ao cliente. Os casos ficam no centro, trabalhados no Service Console: a licença de funcionalidade Service Cloud User é o que abre o Salesforce Console for Service. É aqui que vivem os acordos de nível de serviço (SLAs), através da gestão de direitos (Entitlement) e dos 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. Recebem contas, contactos, relatórios, dashboards, documentos e todas as aplicações personalizadas 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 correm nela, e exatamente por isso que pode apanhar o seu modelo de dados desprevenido.

	Sales Cloud	Service Cloud	Platform
Licença de utilizador	Salesforce	Salesforce	Salesforce Platform
Feita para	Vender	Apoiar os clientes	Aplicações personalizadas
Contas, contactos	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 a lê. Se um grande grupo de utilizadores está na Platform, qualquer design que ponha o trabalho deles numa Oportunidade está estragado antes de começar. Se os executivos precisam dos números de SLA, a licença deles decide se os conseguem ver. Estes três tipos determinam o comportamento.

Click to enlarge

Quando a licença decide o objeto

A Oportunidade é a vítima com que mais me cruzei. Viu-o na tabela: os utilizadores da Platform não a recebem (Standard User Licenses (opens in a new tab), em inglês), e os utilizadores 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 pormenor de compras. É uma restrição de arquitetura, e normalmente empurra o design para um objeto personalizado.

Funciona também para cima. Nas aulas pergunto: o CEO quer dashboards bonitos; licença de Vendas ou de Serviço? Um utilizador de Vendas consegue ver os objetos de vendas e até os casos, por isso 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 ultrapassar o seu nível de serviço), esses dados ficam em direitos (entitlements) e marcos (milestones), e a gestão de direitos exige o Agentforce Service, antigo Service Cloud (Supported Editions for Service Features (opens in a new tab), em inglês). Agora está a fazer upgrade das licenças dos executivos. Ouça o requisito de negócio, e saiba que licença está por baixo dos dados de que ele precisa.

O estádio

Penso nas licenças como lugares num estádio. Toda a gente está a ver o mesmo jogo. Se compro os lugares caros ao meio, vejo as duas equipas de perto. Se estou lá em cima ao canto, na bancada, os assentos não são almofadados e vejo de binóculos.

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

Customer Community: a bancada lá de cima. Feita para um grande número de utilizadores externos que precisam de casos e de base de conhecimento: um cliente a acompanhar o seu caso de suporte. Os lugares custam cerca de metade e podem ir para um número enorme de utilizadores. O que perde lá em cima? Relatórios, dashboards e a tabela de partilha: a partilha baseada em funções que os níveis mais altos recebem. Funciona com contas pessoais.

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

Partner Community: ainda mais perto, para business-to-business, com acesso aos dados de vendas. Os parceiros trabalham leads e oportunidades: registam negócios e fazem campanhas consigo. É o lugar externo que chega aos objetos de vendas. Um senão: 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 toda a gente tivesse o bilhete caro, e depois descobrir na implementação que a maioria dos seus utilizadores não consegue entrar no setor onde pôs os seus dados. Aí tem três escolhas: comprar outros lugares, mudar a experiência ou reprojetar o modelo. As três são arquitetura.

Como pagam muda o design

Há outra pergunta que as pessoas esquecem: como vão estes utilizadores iniciar sessão? As licenças externas vêm em dois formatos. Por membro (member-based): paga por utilizador, o que serve para 500 parceiros que entram todos os dias. Por login (login-based): 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 do que uma vez no mesmo dia continua a contar como um login (Experience Cloud User Licenses (opens in a new tab), em inglês).

Por isso, quando alguém diz «estamos a construir um portal do cliente», a minha pergunta seguinte não é que 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; dobra o modelo inteiro. Algumas licenças de plataforma limitam os utilizadores 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, competências, certificações, línguas e projetos de cada pessoa, para poderem encontrar o construtor de pontes certificado num determinado país. Sem limite, teria construído um objeto utilizador-cargo, utilizador-competência, utilizador-certificação, utilizador-língua e utilizador-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 os gastar todos, isso não era possível. Por isso tornou-se 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 registo para cada tipo de lista (cargo, competência, certificação, língua, projeto), e um objeto de atributo do utilizador, com os tipos de registo correspondentes, a apontar para ele.

Não era o modelo ideal. Era um sofrimento para fazer relatórios, e teria preferido algo mais limpo. Mas era o que a licença permitia. Chamo a estes objetos canivete suíço: guarde o padrão no bolso de trás e, quando os limites não deixarem espaço, parta o vidro e avance para a separação por tipo de registo. Só saiba de que está a abdicar. Permissões diferentes por tipo de registo podem obrigá-lo a dividir o objeto de qualquer forma.

As pessoas já não são os únicos utilizadores

Mais uma pergunta de licenciamento ganhou importância: e as coisas que não são pessoas? As integrações têm identidades. Os agentes têm identidades. A Salesforce tem agora 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). Por isso não pergunte só que utilizadores precisam de acesso. Pergunte que identidades precisam de acesso: uma pessoa, um cliente, um parceiro, uma integração, um agente. E depois o que cada uma precisa de ver e fazer.

Além do exame: o que a IA muda. À medida que os agentes se tornam mais um consumidor e criador de dados, a escolha de objetos e o licenciamento não dizem respeito só aos ecrãs humanos. Saiba com que identidade corre o agente, o que essa identidade consegue alcançar, e se o modelo põe os dados de que ele precisa atrás de um objeto ou permissão que não pode usar.

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

A Steve Trucking trabalha com Parceiros retalhistas. O que é um Parceiro retalhista? Uma empresa. Fácil: Conta. Não crio Retail_Partner__c só porque alguém usou a palavra «parceiro».

Agora o Destinatário, a pessoa que recebe o frigorífico. Contacto? Conta pessoal? Outra coisa? Um milhão de novos Destinatários por ano, que são clientes dos Parceiros retalhistas, não nossos. É exatamente o tipo de pergunta em que não quero saltar para um objeto antes de entender a relação, 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 encaixa de forma limpa no propósito pretendido de um objeto padrão, ou se o 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, utilizador externo, integração e agente que precisa dos dados consegue alcançar o objeto escolhido com as licenças planeadas.
• 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 é os objetos padrão serem bons e os objetos personalizados maus. É que a escolha tem consequências, e às vezes não é decidida pelo substantivo, mas pelas pessoas, e pelas máquinas, que o precisam de usar.

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: os utilizadores 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 partilha padrão; vários inícios de sessão no 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 (gestão 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 gerir campanhas.