Pular para o conteúdo

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)

An aisle of a builders' supply warehouse, its racks stacked with ready-made standard doors, windows and stair parts, a cart waiting in the aisle.
Imagem gerada com IA

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.

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.

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.

O modelo de vendas O modelo de vendas. Um Lead, à esquerda, é convertido numa Conta. Uma Conta tem Contactos e Oportunidades. Uma Oportunidade usa um catálogo de preços e contém produtos da oportunidade. Cada produto da oportunidade obtém o preço de uma entrada do catálogo de preços. Um catálogo de preços lista entradas do catálogo de preços, e um Produto aparece em entradas do catálogo de preços, por isso cada entrada do catálogo de preços une um Produto e um catálogo de preços. é convertido em tem tem usa contém obtém preço de lista aparece em Lead Conta Contacto Oportunidade Catálogo de preços Produto da oportunidade Entrada do catálogo de preços Produto exatamente um zero ou um um ou muitos zero ou muitos © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Eis essa cadeia de perto, com os campos que a mantêm unida:

A cadeia de preços de perto A cadeia de preços como um modelo de dados detalhado. Um produto da oportunidade leva o ID da sua Oportunidade, o ID da sua entrada do catálogo de preços, uma quantidade e um preço de venda, e obtém o preço de uma entrada do catálogo de preços. A entrada do catálogo de preços leva o ID do seu catálogo de preços, o ID do seu Produto, um preço de tabela e um indicador Usar preço padrão. Um catálogo de preços tem um nome e um indicador É padrão; um Produto tem um nome e um código de produto. obtém preço de lista aparece em Catálogo de preços ID do catálogo de preços ID DE REGISTO Nome É padrão Produto da oportunidade ID do produto da oportunidade ID DE REGISTO ID da oportunidade ID da entrada do catálogo de preços Quantidade Preço de venda Entrada do catálogo de preços ID da entrada do catálogo de preços ID DE REGISTO ID do catálogo de preços ID do produto Preço de tabela Usar preço padrão Produto ID do produto ID DE REGISTO Nome Código do produto exatamente um zero ou um um ou muitos zero ou muitos © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

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.

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.

O modelo de serviço O modelo de serviço. Uma Conta tem Contactos, Casos e Ativos. Um Contacto relata Casos. Um Caso pode ser sobre um Ativo, e um direito (Entitlement), que pertence a uma Conta, cobre Casos. Uma linha do Caso de volta para si mesmo, a contornar o seu canto, é o Caso principal (Parent Case): um caso é pai de zero ou muitos casos, e cada caso tem zero ou um pai. tem tem relata possui é sobre cobre pai de Conta Contacto Ativo Caso Direito exatamente um zero ou um um ou muitos zero ou muitos © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

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.

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.

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.

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.

  • 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.