Os modelos de dados padrão
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)

Módulo 2 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: A plataforma de dados Salesforce: mais do que uma base de dados · Próximo: Construa o seu: objetos personalizados
A pergunta a que este módulo responde: O que é que a Salesforce já modelou por si, e como é que isso se encaixa?
No módulo 1 disse-lhe para olhar para a nave-mãe: antes de inventar alguma coisa, veja como o próprio Salesforce o faz. Este módulo é onde olhamos a sério. A Salesforce já modelou muito do negócio por si, nos seus objetos padrão, e dois desses modelos fazem a maior parte do trabalho na maioria das orgs em que entro: o modelo de vendas (Sales) e o modelo de serviço (Service). Antes de decidir se algo merece um objeto personalizado, precisa de saber o que já existe. São esses os próximos dois módulos.
O que torna um objeto padrão
Seção intitulada “O que torna um objeto padrão ”Um objeto padrão vem pronto de fábrica. Foi a Salesforce que o construiu, tem um propósito definido, e vem com os seus próprios campos e relações. Pode acrescentar-lhe campos, construir automação à volta dele e mudar os seus layouts, mas não o pode redesenhar: os campos e as relações padrão são da Salesforce.
Olhe para os nomes. Account, Contact, Case. Sem prefixo, sem sufixo. É a Salesforce a guardar esse espaço para si. Tudo o que construímos termina em __c, por isso a Salesforce pode acrescentar novos objetos padrão a qualquer momento sem nunca colidir com nada na sua org. E acrescenta, a cada versão.
A dada altura alguém construiu um objeto de produto que não deu certo e teve de ser deixado para trás. É por isso que o nome de API é Product2. É o meu primeiro teste decisivo quando alguém me diz que conhece Salesforce.
O modelo de vendas (Sales)
Seção intitulada “O modelo de vendas (Sales) ”Comece pela esquerda, com o Lead: alguém que pode vir a ser cliente. Um lead ainda não faz verdadeiramente parte do modelo. É uma área de espera. Quando o converte, o Salesforce cria os registos reais: uma Conta, um Contacto e, se houver um negócio, uma Oportunidade. É por isso que desenho o Lead de lado.
A Conta é a empresa. Os seus Contactos são as pessoas que trabalham nela. Uma Oportunidade é um negócio com essa conta. Até aqui, nada que não esperasse.
Depois fica interessante. O que está no negócio? Cada linha é um produto da oportunidade (Opportunity Product), e um produto da oportunidade não aponta diretamente para um Produto. Aponta para uma entrada do catálogo de preços (Price Book Entry): este produto, a este preço, neste catálogo de preços. A entrada do catálogo de preços fica entre o Produto e o catálogo de preços (Price Book), por isso o mesmo produto pode ter um preço no catálogo de preços padrão e outro no seu catálogo de preços de parceiros.
São duas relações que se tornaram coisas, uma a seguir à outra. Lembra-se do Item de entrega do capítulo 2, entre a Entrega e o Produto, e do Truque do cão entre o Cão e o Truque? A Salesforce fez exatamente o mesmo aqui, duas vezes: o produto da oportunidade entre a Oportunidade e a entrada do catálogo de preços, e a entrada do catálogo de preços entre o Produto e o catálogo de preços. Quando consegue ler isto, consegue ler a maior parte do modelo de dados padrão.
Eis essa cadeia de perto, com os campos que a mantêm unida:
Uma regra em que as pessoas tropeçam: existe um catálogo de preços padrão, e uma entrada em qualquer outro catálogo de preços pode simplesmente usar o preço padrão do produto. Saiba que catálogo de preços uma oportunidade usa antes de carregar os produtos dela.
O modelo de serviço (Service)
Seção intitulada “O modelo de serviço (Service) ”Agora o outro lado da casa. A mesma Conta, os mesmos Contactos. Quando algo corre mal, o cliente abre um Caso.
O caso é normalmente sobre algo que o cliente tem, e o Salesforce tem um objeto para isso: o Ativo (Asset). No módulo 5 vou chamar-lhe o objeto padrão que as pessoas deixam passar. É algo que o cliente tem, quer o tenha comprado a si quer não.
E a que é que o cliente tem direito? Esse é o direito (Entitlement): o suporte que uma conta está qualificada a receber, muitas vezes ligado a um ativo, a um produto ou a um contrato de serviço. Coloque um direito num caso, e agora o caso sabe que nível de suporte deve receber.
Repare na linha que sai do Caso e volta a ele próprio. Cada caso tem um campo Caso principal (Parent Case), e esse campo aponta para outro caso. Isso é uma autopesquisa (self-lookup): uma relação de um objeto com ele próprio. Confunde muita gente da primeira vez que a vê, por isso aqui ficam os dois motivos pelos quais a uso.
Um: um problema grande que se divide em problemas menores. O cliente relata que a instalação inteira foi abaixo. Abrimos subcasos para a rede, o hardware e a configuração, cada um trabalhado separadamente, e todos se resolvem para cima: o caso principal não termina enquanto eles não terminarem.
Dois: histórico. Um caso foi fechado no mês passado, e agora o mesmo problema voltou. O novo caso aponta para o original, por isso quem o abrir vê que isto já aconteceu antes, e o que foi feito a respeito.
Vamos voltar às autopesquisas quando chegarmos às relações, no módulo 7.
Repare que a Conta e o Contacto ficam no mesmo lugar nos dois diagramas. São os mesmos registos. Um vendedor e um agente de atendimento estão a olhar para o mesmo cliente, de lados diferentes da casa. Esse é um dos argumentos mais fortes para continuar no padrão: os modelos foram construídos para se encontrarem.
Ficheiros e anexos
Seção intitulada “Ficheiros e anexos ”Nem tudo num registo é um campo. Contratos, fotografias, PDFs e folhas de cálculo são ficheiros, e o lugar deles é o Salesforce Files, não o antigo modelo de anexos (Attachments), que é legado. Se o documento já vive no SharePoint Online, no OneDrive, no Google Drive ou no Box, o Files Connect permite aos utilizadores chegar até ele a partir do Salesforce sem o copiar para dentro.
Os ficheiros são contados de forma diferente dos registos. O Salesforce divide o armazenamento em dois: o armazenamento de ficheiros guarda anexos, Files, Salesforce CRM Content, ficheiros do Chatter e afins, e o armazenamento de dados guarda os seus registos. O armazenamento de ficheiros sobe depressa quando cada registo ganha fotografias ou digitalizações, por isso grandes volumes de imagens, como as fotografias de uma aplicação de campo, muitas vezes ficam melhor totalmente fora do Salesforce, com o Salesforce a guardar só uma ligação. O módulo 4 volta a este assunto.
Duas colunas ou duzentas
Seção intitulada “Duas colunas ou duzentas ”O armazenamento de dados também é contado de forma diferente de uma base de dados. Numa base de dados normal, uma tabela com duas colunas e um milhão de linhas é pequena, e uma tabela com cem colunas e um milhão de linhas é um elefante. O Salesforce pesa as duas da mesma forma: a maioria dos registos conta como cerca de 2 KB, independentemente de quantos campos tenham. Há exceções. Uma campanha conta mais, uma mensagem de e-mail conta pelo tamanho real, e uma conta pessoal conta como cerca de 4 KB, porque é uma conta e um contacto.
Uma dica. Sempre que entro numa org nova, um dos primeiros sítios aonde vou é Setup → Storage Usage (Utilização do armazenamento). Chego a pedir uma captura de ecrã ao cliente logo na primeira chamada. Esse ecrã não mente. Mostra que objetos estão a crescer, e quais já são os elefantes.
Contas pessoais: quando o cliente é uma pessoa
Seção intitulada “Contas pessoais: quando o cliente é uma pessoa ”O modelo de Conta e Contacto funciona na perfeição para uma empresa e as pessoas que trabalham nela. Mas e se o seu cliente não for uma empresa? E se for uma pessoa?
Essa é a conta pessoal: uma conta e um contacto combinados num único registo, para pessoas singulares. Os campos de contacto vêm com ela, e os personalizados aparecem com um sufixo próprio, __pc. Cada uma conta tanto no armazenamento de contas como no de contactos, porque por baixo é as duas coisas.
Um aviso antes de as ativar: depois de as contas pessoais serem ativadas, não é possível desativá-las. É o Teste de Reversibilidade do capítulo 1 na sua forma mais pura. O módulo 5 traz a minha posição sobre quando valem a pena.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”- Que partes do negócio a Salesforce já modelou, antes de desenhar qualquer coisa nova.
- Se um conceito cai no modelo de vendas, no modelo de serviço ou nos dois, sabendo que partilham a Conta e o Contacto.
- Onde vivem os documentos e as imagens: no Salesforce Files, num sistema de ficheiros ligado, ou fora da plataforma, com uma ligação.
- Quanto vão custar os dados em armazenamento, contados da forma como o Salesforce conta: registos, não colunas.
- Se o cliente é uma empresa ou uma pessoa, antes de ativar algo que não pode ser desativado.
E quando o Salesforce não tem aquilo de que precisa? Constrói-o. É o passo seguinte.
Para saber mais
Seção intitulada “Para saber mais ”- OpportunityLineItem (opens in a new tab), Object Reference for the Salesforce Platform (em inglês, consultado em 2026-10-12): «um membro da lista de produtos Product2 associados a uma Oportunidade»; a entrada do catálogo de preços é obrigatória.
- PricebookEntry (opens in a new tab), Object Reference (em inglês, consultado em 2026-10-12): «uma associação entre um Pricebook2 e um Product2»; uma entrada pode usar o preço padrão.
- Case (opens in a new tab), Object Reference (em inglês, consultado em 2026-10-12): ParentId, «o ID do caso principal na hierarquia. O rótulo é Parent Case»; uma relação de pesquisa para Case.
- Entitlement (opens in a new tab), Object Reference (em inglês, consultado em 2026-10-12): «o suporte ao cliente que uma conta ou um contacto está qualificado a receber», possivelmente com base num ativo, num produto ou num contrato de serviço.
- Data and Storage Resources (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-12): o que incluem o armazenamento de ficheiros e o armazenamento de dados.
- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-12): «A maioria dos registos do Salesforce consome aproximadamente 2 KB de armazenamento de dados»; contas pessoais, cerca de 4 KB.
- Enable Person Accounts (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-12): «Depois de as contas pessoais serem ativadas, não é possível desativá-las.»
- Files Connect FAQ (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-09-25).
