Arquitetura de dados Salesforce

🌐 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

Guia de estudo do capítulo 3 do curso Data Architect. Leia primeiro os dez módulos; esta página ajuda você a verificar o que ficou.

Sobre este guia de estudo. Ele foi construído apenas a partir do conteúdo deste curso e da lista de objetivos publicada no guia do exame da Salesforce. Ele nunca se baseia em questões reais do exame e não afirma saber o que cai na prova. Se você já fez o exame, por favor não me envie as questões: o contrato de certificação proíbe compartilhá-las, e decorar respostas é, de qualquer forma, o jeito errado de se tornar arquiteto.

Este é o capítulo em que o modelo encontra a plataforma, e ele carrega boa parte do exame. Alimenta as duas maiores seções, Modelagem de Dados e Design de Banco de Dados, e Gerenciamento de Dados Salesforce, cada uma com um quarto do exame. Os números da plataforma mudam: a lista traz os que os módulos citam, com a data em que foram consultados. Aprenda para que serve cada limite, e confira o número atual antes de contar com ele.

Para o exame

Marque conforme avança. Cada item tem um link para onde é ensinado.

DM-1: projetar o modelo de dados na plataforma

• Sei que o Salesforce é uma plataforma orientada por metadados e multitenant: um objeto é metadado, não uma tabela nova, e todo objeto ganha suas APIs no momento em que existe. (Os metadados são a planta, Sua API veio com o objeto)
• Sei que os limites do governador existem para que um inquilino não tome conta dos recursos compartilhados. (Você não pode tomar conta do elevador)
• Consigo ler os modelos de dados padrão: a conversão de Lead em Conta, Contato e Oportunidade; um produto da oportunidade (Opportunity Product) aponta para uma entrada do catálogo de preços (Price Book Entry), que aponta para o Product2; e Caso, Ativo e direito (Entitlement) do lado do serviço. (O modelo de vendas (Sales), O modelo de serviço (Service))
• Sei o que a tela New Custom Object (novo objeto personalizado) decide: um nome de registro do tipo Texto ou numeração automática; a Object Classification (classificação do objeto: com compartilhamento, Bulk API e Streaming API ligados, é um objeto Enterprise Application; com eles desligados, um objeto Light Application); e Allow Search (permitir pesquisa), desligado por padrão. (A tela New Custom Object)
• Consigo ler um nome de API: objetos e campos padrão não têm prefixo nem sufixo; objetos e campos personalizados terminam em __c; um pacote gerenciado acrescenta seu prefixo de namespace (abc__); e um campo que você acrescenta ao objeto de um pacote ganha __c, mas nunca o prefixo do fornecedor. (Prefixos e sufixos)
• Consigo aplicar o teste do encaixe limpo para um objeto padrão, e sei quando o significado ou o peso apontam para um objeto personalizado. (O teste do encaixe limpo)
• Sei para que servem o Ativo e as contas pessoais, que uma conta pessoal ocupa cerca do dobro do armazenamento de uma conta comercial, e que, depois de habilitadas, as contas pessoais não podem ser desabilitadas. (O Ativo é um bom exemplo, Contas pessoais, Quando a pessoa é a conta?)
• Escolho um tipo de campo pelo comportamento de que preciso (um número de frota não é um Número), e sei que data/hora é armazenada em GMT e mostrada no fuso horário de cada leitor, então é comparada com intervalos, não com igualdade. (Um número nem sempre é um número, Data, Data/Hora e Hora)
• Sei que o texto vem em dois tipos: até 255 caracteres no registro (indexável, utilizável como único ou como ID externo), e texto Longo ou Rich acima disso, sem índice, sem filtro no WHERE e sem fórmulas. (A família do texto)
• Sei quando usar um Nome com numeração automática, e que ele não é o ID de registro. (Um humano precisa identificá-lo?)
• Sei como um ID externo permite que uma integração faça upsert, e carregue filhos pelo ID externo do pai. (IDs externos)
• Sei quando um valor deve ser derivado por uma fórmula, e quando é um fato histórico que precisa ser armazenado. (Armazenado ou derivado?)
• Sei a diferença entre um objeto de junção lógico (a ideia de modelagem: um objeto que liga dois outros num muitos-para-muitos, com atributos próprios) e um objeto de junção do Salesforce (Salesforce Junction Object: um objeto personalizado com dois relacionamentos mestre-detalhes), e que a Salesforce quer dizer o segundo. (Dois pais de largura)
• Conheço o relacionamento hierárquico: um relacionamento de pesquisa especial, só no objeto Usuário, como o campo padrão Gerente (Manager), que não pode voltar ao mesmo usuário, direta ou indiretamente, e que não é a hierarquia de papéis. (Hierárquico)
• Sei a diferença entre um relacionamento de pesquisa e um mestre-detalhes: propriedade, compartilhamento, pai obrigatório, exclusão em cascata, resumos de totalização. (Relacionamento de pesquisa, Mestre-detalhes)
• Sei que o mestre-detalhes não pode ser criado num objeto que já tem dados (crie um relacionamento de pesquisa, preencha, converta), só volta a ser relacionamento de pesquisa sem resumos de totalização no mestre, e precisa de Permitir reatribuição de pai para mover um filho. (O filho pode trocar de pai?)
• Conheço a forma da plataforma para o mestre-detalhes: até três níveis de detalhe personalizados de profundidade (um relacionamento de pesquisa pode quebrar a cadeia em qualquer ponto), e dois pais mestre-detalhes de largura. Num objeto de junção do Salesforce, o mestre-detalhes criado primeiro é o principal (proprietário, aparência, divisão), o segundo é o secundário, e o acesso precisa dos dois pais: o mais restritivo vence. (Três níveis de profundidade, Dois pais de largura)
• Conheço as três escolhas de um relacionamento de pesquisa quando o pai é excluído: limpar o campo (o padrão), bloquear a exclusão, ou excluir em cascata, que fica desligada até a Salesforce habilitá-la e ignora o compartilhamento. (Relacionamento de pesquisa)
• Sei que um autorrelacionamento precisa ser um relacionamento de pesquisa, e conheço os dois que já vêm prontos: a Conta pai da Conta e o Caso pai (Parent Case) do Caso. (Autorrelacionamentos)
• Sei que o recálculo de totalizações pode levar tempo, que um resumo de totalização não pode usar uma fórmula com NOW(), TODAY() ou uma referência entre objetos, e que não se escolhe mestre-detalhes só para ganhar um resumo de totalização: um campo armazenado, mantido atualizado por um flow ou trigger, é a alternativa. (Resumos de totalização são úteis, mas não são de graça)
• Conheço os limites de relacionamento que o módulo cita: dois mestre-detalhes por objeto; 40 campos de relacionamento por padrão (no máximo 50); 25 resumos de totalização por padrão (no máximo 40). (Relacionamentos também têm limites)

DM-2: um modelo que respeita o compartilhamento e escala

• Sei que um filho mestre-detalhes não tem proprietário nem tabela de compartilhamento próprios: o acesso segue o mestre. (A propriedade vem de carona)
• Conheço o desequilíbrio pai-filho: a orientação da Salesforce é de no máximo cerca de 10 mil filhos num único pai. (A pergunta dos 10 mil filhos)
• Conheço o desequilíbrio de propriedade (um usuário dono de mais de 10 mil registros de um objeto) e a orientação: espalhar a propriedade, ou manter esse usuário fora da hierarquia de papéis ou sozinho no topo, e fora dos grupos públicos usados por regras de compartilhamento. (A propriedade pode virar um problema de escala)
• Conheço a tabela de compartilhamento: o objeto de compartilhamento de um objeto personalizado é Object__Share; um objeto de detalhe não tem nenhum, o acesso dele vem do mestre; e uma troca de proprietário remove os compartilhamentos manuais, mas mantém o compartilhamento Apex com seu próprio motivo. (A tabela de compartilhamento)
• Consigo decidir quem é dono dos registros que integrações e agentes criam, conforme a propriedade determine ou não o compartilhamento. (Quem é dono dos registros que os sistemas criam?)

DM-4: big objects versus objetos padrão e personalizados

• Conheço as três casas dos dados: no núcleo (on core: sObjects, trabalhados todo dia), referenciados (outro sistema é a fonte da verdade: os objetos externos do Salesforce Connect, __x, ou chamadas personalizadas) e arquivados (no núcleo em big objects, __b, ou fora do núcleo num data warehouse). (No núcleo e fora do núcleo)
• Sei que objetos externos fazem uma chamada externa toda vez que são tocados, então a latência e a disponibilidade do sistema de origem importam. (Referenciados)
• Conheço os big objects: volumes enormes, consultados pelo índice por correspondência exata ou intervalo, sem interface nem relatórios padrão, só permissões de objeto e de campo, sem automação. (Arquivados)
• Sei que a maioria dos registros conta como cerca de 2 KB de armazenamento de dados, independentemente dos campos, e que os arquivos são medidos à parte, no armazenamento de arquivos. (Duas colunas ou duzentas, Arquivos e anexos)

SDM-1: as licenças e os objetos que as pessoas podem usar

• Conheço as três licenças internas, Sales Cloud, Service Cloud e Platform, e o que cada uma pode usar. (Três licenças internas)
• Sei que as licenças fazem parte do modelo de dados: usuários Salesforce Platform não têm Leads, Campanhas, Oportunidades nem Previsões, e usuários Customer Community não podem usar a Oportunidade. (Agora deixe-me complicar tudo: licenciamento)
• Conheço os níveis de licença externa: Customer Community, Customer Community Plus (relatórios, dashboards, compartilhamento padrão), Partner Community (objetos de vendas); e que a Partner Community não pode ser usada com contas pessoais. (O estádio)
• Conheço o licenciamento por membro versus por login, e a que população cada um serve. (Como eles pagam muda o design)
• Sei que algumas licenças de plataforma limitam os usuários a uma aplicação com até dez objetos personalizados, e conheço o padrão de tipos de registro para trabalhar dentro disso. (Quando a licença molda o modelo)
• Sei que a licença Salesforce Integration é para usuários entre sistemas, só de API. (As pessoas não são mais os únicos usuários)
• Sei que relatórios de SLA precisam de direitos e marcos (entitlements e milestones), que exigem licenças de Serviço. (Agora deixe-me complicar tudo: licenciamento)

SDM-2: manter os dados consistentes

• Consigo colocar uma regra no degrau certo da escada da consistência: tipo de campo e vocabulário, obrigatório e único, regras de validação, regras de duplicidade, automação. (Mantendo os dados consistentes)
• Sei que uma lista de opções restrita rejeita valores que não estão na lista, até pela API, e que um conjunto de valores global compartilha uma lista entre campos (até 1.000 valores). (Degrau um)
• Sei que um requisito no layout de página protege só aquela tela, não os dados, e que as regras de validação rodam em toda gravação. (Validação na interface não é validação de dados, Degrau três)
• Consigo limitar uma regra de validação com ISNEW() e ISCHANGED(), uma permissão personalizada ou uma data de entrada no ar, sabendo quais gravações (inclusive as que não controlo, como uma mudança de proprietário em lote ou um resumo de totalização) cada escolha ainda verifica. (O problema dos registros antigos)
• Conheço as regras de correspondência e as regras de duplicidade, os limites que o módulo cita (cinco regras de duplicidade ativas por objeto, três regras de correspondência em cada), e que elas não resolvem a identificação entre sistemas. (Degrau quatro: regras de duplicidade)
• Sei que as regras de duplicidade não comparam entre si registros salvos no mesmo momento, que gravações por API e importação são bloqueadas sem alerta, e que uma gravação e tudo o que ela dispara são revertidos como uma transação só. (Degrau quatro, Tudo ou nada)
• Sei que Workflow Rules e Process Builder estão fora de suporte; automação significa Flow ou Apex. (Degrau cinco: automação)

Além do exame

O exame é o piso, não o teto. Estes são os hábitos deste capítulo de que um arquiteto precisa, quer alguma pergunta trate deles ou não.

• A plataforma tem uma forma. Projete para a plataforma em que você está, não para um banco de dados genérico.
• Olhe para a nave-mãe. Veja como a Salesforce modela um conceito antes de inventar um.
• Cada objeto é um compromisso: armazenamento, limites, um modelo de compartilhamento, licenças e dependências.
• Pergunte onde os dados vivem antes de escolher um objeto: no núcleo (on core), referenciados ou arquivados.
• Leia qualquer nome de API e você sabe quem o fez, e o que pode mudar.
• Se você não arquiva hoje, algum dia vai arquivar?
• Faça um protótipo de big objects antes de sugeri-los.
• Nomes de negócio diferentes não significam automaticamente objetos diferentes.
• Pergunte quais identidades precisam dos dados: pessoas, clientes, parceiros, integrações e agentes.
• Todo campo ganha uma descrição, e classificação onde importa.
• Descreva primeiro o comportamento do relacionamento; a configuração o implementa. Não distorça o modelo para ganhar um recurso.
• A pergunta da exclusão: o que deveria acontecer com os filhos se alguém excluir o pai?
• Escolha qual elo quebra a cadeia: crie o relacionamento de pesquisa onde o filho tem de fato vida própria.
• Propriedade vem do principal, acesso vem dos dois: o mais restritivo vence.
• Separe inativo de sumido, e faça da retenção uma regra de negócio.
• Empurre a regra até onde ela corretamente pertence, e dê ao histórico legítimo um desvio em vez de reescrevê-lo.
• O diagrama não é a arquitetura. Saiba rastrear cada estrutura até um motivo de negócio.

Palavras para conhecer

Termo	Em uma linha
Orientado por metadados	Objetos e campos são definições que a plataforma lê em tempo de execução, não novas tabelas físicas
Multitenancy (multilocação)	Muitas orgs compartilham a infraestrutura, cada uma isolada, como apartamentos num prédio
Limites do governador	Limites que impedem um inquilino de monopolizar os recursos compartilhados
Objeto externo	Dados exibidos no Salesforce pelo Salesforce Connect, buscados na origem a cada acesso
Big object	Armazenamento para dados muito grandes e pouco usados, consultados pelo índice
Conta pessoal	Um indivíduo representado como uma conta, para modelos business-to-consumer
Encaixe limpo	Um conceito de negócio que corresponde ao propósito pretendido de um objeto padrão
ID externo	Um campo com o identificador de outro sistema, usado para upserts e correspondência
Upsert	Atualizar o registro se ele existe, criá-lo se não existe
Relacionamento de pesquisa	Um relacionamento em que o filho mantém seu próprio proprietário e sua própria vida
Mestre-detalhes	Um relacionamento em que o filho pertence ao pai: proprietário e compartilhamento herdados, exclusão em cascata, resumos de totalização
Objeto de junção lógico	A ideia de modelagem: um objeto que liga dois outros num muitos-para-muitos e carrega atributos próprios, seja qual for a forma como é construído
Objeto de junção do Salesforce (Salesforce Junction Object)	O que a Salesforce quer dizer com “objeto de junção”: um objeto personalizado com dois relacionamentos mestre-detalhes
Mestre principal e secundário	O mestre-detalhes criado primeiro num objeto de junção do Salesforce (proprietário, aparência, divisão) e o segundo (escopo de relatório; vira principal se o primeiro for removido)
Relacionamento hierárquico	Um relacionamento de pesquisa especial, só no objeto Usuário, como Gerente (Manager), que não pode voltar ao mesmo usuário
Prefixo de namespace	O prefixo do fornecedor nos objetos e campos de um pacote gerenciado, como abc__Inspection__c
Tabela de compartilhamento	O objeto de compartilhamento (AccountShare, Truck__Share) que guarda a maior parte do compartilhamento de um registro, uma linha por usuário ou grupo, com seu motivo
Resumo de totalização	Um campo no mestre que conta, soma ou encontra o mínimo ou o máximo dos seus detalhes
Desequilíbrio de dados (data skew)	Registros demais sob um pai ou um proprietário, causando bloqueios e recálculos de compartilhamento demorados
Por membro / por login	Pagar por usuário externo, ou por login a cada mês
Escada da consistência	As camadas que aplicam as regras de dados, do tipo de campo até a automação
Lista de opções restrita	Uma lista de opções que rejeita qualquer valor fora da lista, venha de onde vier
Classificação de dados	Metadados do campo para proprietário, uso, sensibilidade e categoria de conformidade

Teste-se

Cenários curtos no estilo do curso. Decida sua resposta antes de abrir.

1. Os usuários precisam ver detalhes de pedidos que o ERP possui e atualiza o dia todo. Eles não os editam no Salesforce. Copiar para dentro, ou não?

Referencie-os: objetos externos pelo Salesforce Connect mantêm o ERP como fonte da verdade, sem cópia para sincronizar. Aceite que cada visualização faz uma chamada externa, então a latência e a disponibilidade do ERP importam, e que isso serve melhor para leitura do que para muita edição ou muitos relatórios. Releia Referenciados.

2. O negócio quer acompanhar distribuidores, fornecedores e parceiros varejistas. Três objetos personalizados?

Não. Todos são empresas, então a Conta é um encaixe limpo; os nomes diferentes são papéis, carregados por um tipo, um tipo de registro ou um relacionamento. Releia O teste do encaixe limpo.

3. Um design usa a Oportunidade, mas a maioria das pessoas que precisam dos dados tem licenças Salesforce Platform ou Customer Community. E agora?

Essas licenças não podem usar a Oportunidade, então a licença é uma restrição de arquitetura: comprar outras licenças, mudar a experiência ou reprojetar, normalmente na direção de um objeto personalizado. Releia Agora deixe-me complicar tudo: licenciamento.

4. O ERP envia atualizações noturnas de contas. Como a integração deve encontrar o registro certo sem consultar IDs do Salesforce?

Guarde o número de cliente do ERP num campo de ID externo e faça upsert por ele: atualiza se encontrar, cria se não. Registros filhos também podem apontar para o pai pelo ID externo dele. Releia IDs externos.

5. Um Item de entrega não pode existir sem sua entrega, nunca se move e não precisa de proprietário próprio. Uma Entrega existe antes de ser roteirizada e pode mudar para outra rota. Qual relacionamento para cada um?

Item de entrega para Entrega: mestre-detalhes (pertence ao pai a vida inteira, herda o acesso, exclui em cascata). Entrega para Rota: relacionamento de pesquisa (vida própria, opcional no início, móvel, e excluir uma rota nunca pode excluir entregas). Releia Comece pelo relacionamento de negócio.

6. Uma integração cria 3.300 entregas por dia, todas de propriedade do usuário de integração, que tem um papel no meio da hierarquia. Qual é o risco, e a correção?

Desequilíbrio de propriedade: passados 10 mil registros, mover esse usuário ou mudar seus grupos dispara recálculos de compartilhamento demorados. Espalhe a propriedade se ela importar para o acesso; senão, mantenha o usuário de integração fora da hierarquia de papéis, ou sozinho num papel no topo, e fora dos grupos usados por regras de compartilhamento. Releia A propriedade pode virar um problema de escala.

7. Você acrescenta uma regra de validação, e 20 mil registros antigos a violam. Um usuário edita um telefone em um deles e a gravação falha. O que a regra deveria ter feito?

Dizer quando aplicar, não só o que precisa ser verdade: limitá-la com ISNEW() ou ISCHANGED() nos campos relevantes, e dar aos registros anteriores à regra um desvio deliberado em vez de reescrever o histórico deles. Releia O problema dos registros antigos.

8. O negócio quer todas as fotos de entrega “no Salesforce”: quatro a cinco milhões por ano, crescendo 30%. O que você propõe?

Separe acesso de armazenamento. Guarde os arquivos num armazenamento feito para esse volume, fora da org do núcleo, e mantenha no Salesforce uma referência, uma contagem ou um registro de índice para que os usuários possam encontrá-las e vê-las. Releia Fotos.

9. Uma Atribuição de equipe (Crew Assignment) tem relacionamentos mestre-detalhes com Equipe (criado primeiro) e Caminhão. Um despachante consegue ver a equipe, mas não o caminhão. Ele consegue ver a Atribuição de equipe?

Não. A Equipe é o principal, então dá à atribuição o proprietário e a aparência, mas o acesso precisa dos dois pais: o despachante precisa de acesso à equipe e ao caminhão, no nível que a Sharing Setting (configuração de compartilhamento) de cada campo mestre-detalhes pede. O mais restritivo vence. Releia Dois pais de largura.

10. Um parceiro reenvia um arquivo de manifesto, e o mesmo cliente aparece duas vezes nele. Você tem uma regra de duplicidade na Conta configurada para bloquear. Você está seguro?

Não só com a regra de duplicidade. Registros salvos no mesmo momento não são comparados entre si, só com registros que já estão no Salesforce, então as duas linhas podem passar. Empurre a unicidade para baixo, até o campo: um ID externo único, que a plataforma verifica em toda gravação, então só um vence. Releia Degrau quatro: regras de duplicidade e Tudo ou nada.

Para saber mais

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (em inglês, consultado em 2026-09-25): a lista oficial de objetivos e seus pesos. Sempre confira a versão atual antes de agendar o exame.
• A seção Para saber mais de cada módulo lista a documentação da Salesforce por trás dos seus fatos de plataforma, com a data em que foi consultada.