Projete o modelo físico 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

Módulo 10 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Mantendo os dados consistentes · Próximo: o guia de estudo do capítulo, depois o próximo capítulo, Entendendo os dados corporativos

A pergunta que este módulo responde: Como transformamos nosso modelo lógico numa arquitetura Salesforce?

Este capítulo foi um longo argumento de que a plataforma tem uma forma: objetos padrão e personalizados, lugares onde os dados podem viver, tipos de campo, relacionamentos, propriedade, licenças, regras de consistência, armazenamento e escala. Cada um pode mudar a forma como o modelo lógico do capítulo 2 é construído. Agora vamos juntar tudo num recorte da Steve Trucking.

Um recorte, não a empresa inteira. Um erro que vejo arquitetos cometerem é tentar resolver a empresa inteira num diagrama só. Quero algo sobre o qual possamos raciocinar: um Parceiro varejista envia um manifesto, a Steve Trucking entrega o que está nele, e guardamos o que precisamos sobre cada entrega. Depois tomamos as decisões físicas uma de cada vez. O design completo é o checkpoint da Parte 1.

Comece pelo que já sabemos

O capítulo 2 fez o trabalho conceitual: Parceiro varejista, Destinatário, Manifesto, Entrega, Item de entrega, o tipo de parada, Equipe, Caminhão, Centro de distribuição, fotos. Demos nome aos relacionamentos e perguntamos o que significam. Não vou repetir isso. A pergunta agora é como esses conceitos vivem no Salesforce. Um fato do briefing importa logo de cara: a Steve Trucking já usa o Field Service para agendamentos, equipes e o app móvel.

Parceiro varejista: não invente uma conta

Um Parceiro varejista é uma empresa para a qual a Steve Trucking trabalha. O Salesforce já tem um objeto projetado para empresas: a Conta. Encaixe limpo. Então nada de Retail_Partner__c só porque o negócio diz “parceiro”. É uma Conta, com um tipo de registro Retail Partner para diferenciá-la de outras organizações, e com ela vêm contratos, casos, Contatos para os gerentes de CD, e acesso ao portal para esses Contatos. Decisão fácil. Nem todas são.

O número de pedido do parceiro não é a nossa identificação

Cada Parceiro varejista envia suas próprias referências. O pedido de um parceiro tem a cara 8843119, o de outro a cara A-984732. Esses números importam, mas de quem são? Do parceiro. O Salesforce tem seu próprio ID de registro, e o parceiro tem a referência que usa quando fala conosco. Os dois podem existir; é o “uma coisa, vários identificadores” do capítulo 2.

Então a referência do parceiro vira um ID externo que a integração usa para casar as atualizações. E, como dois parceiros poderiam usar o mesmo número, a identificação é o parceiro mais a referência, não a referência sozinha. Não faça do número de um parceiro a identificação universal da entrega só porque ele chegou primeiro, e não faça uma integração buscar num campo de texto toda vez que precisa encontrar um registro.

Entrega: olhe para a nave-mãe

É aqui que dá vontade de criar Delivery__c. O negócio disse “entrega”, então precisamos de um objeto Entrega. É exatamente o que não quero que você faça primeiro. Olhe para a nave-mãe, como fizemos no módulo 2. O que o Salesforce já tem para trabalho feito num local, com ciclo de vida, itens, agendamento e uma equipe em campo? A Ordem de serviço (Work Order) do Field Service: a Salesforce a descreve como trabalho de serviço de campo a ser feito para um cliente (WorkOrder (opens in a new tab), em inglês). A visita agendada e sua janela de horário são o Compromisso de serviço (Service Appointment), e é isso que o despacho agenda e o app da equipe mostra.

Então Entrega → Ordem de serviço. Não porque as palavras batem; não batem. Porque o comportamento bate com a capacidade da plataforma pela qual já estamos pagando e que pretendemos usar. Um objeto padrão não precisa compartilhar o vocabulário do negócio. Precisa representar o conceito corretamente.

Click to enlarge

Passo 1 de 4: a nave-mãe. Cada cartão é o conceito de negócio, com o seu objeto Salesforce embaixo.

Mas objetos padrão vêm com bagagem

A outra metade: a Ordem de serviço não é de graça. Ela traz o licenciamento do Field Service, seus próprios relacionamentos, comportamento de segurança, campos obrigatórios, automação e ciclo de vida, e outras partes da plataforma esperam que ela se comporte de certo jeito. Estamos escolhendo-a porque o encaixe é limpo e porque estamos usando o que foi construído em torno dela. Se a Steve Trucking não quisesse nada do Field Service e o modelo brigasse com o processo a cada passo, eu reconsideraria. A arquitetura é o encaixe, não o rótulo.

Itens de entrega: siga o modelo

Depois que a Entrega é uma Ordem de serviço, olhe o resto desse modelo antes de inventar qualquer coisa. Um Item de linha da ordem de serviço (Work Order Line Item) é uma subtarefa numa ordem de serviço (WorkOrderLineItem (opens in a new tab), em inglês): a geladeira, a instalação, o recolhimento. Então Item de entrega → Item de linha da ordem de serviço. Repare que a primeira decisão moldou a segunda. Não estamos escolhendo um objeto para cada entidade isoladamente. Adote um modelo, e entenda o resto dele antes de construir estruturas personalizadas em volta.

Que tipo de parada é esta?

Na Steve Trucking uma parada é só entrega, entrega com instalação ou entrega com recolhimento, e cada tipo tem sua própria duração, habilidades da equipe e checklist de instalação. No capítulo 2 decidimos que isso é uma entidade, não um rótulo. O Field Service já tem uma: o Tipo de trabalho (Work Type), um modelo para um tipo de trabalho que pode ser aplicado a ordens de serviço e itens de linha (WorkType (opens in a new tab), em inglês). Então Tipo de parada → Tipo de trabalho. De novo, não porque existe algo chamado Tipo de trabalho, mas porque o conceito e o comportamento se alinham.

Click to enlarge

Passo 2 de 4: siga o modelo. Os itens de linha e o Tipo de trabalho vêm com a Ordem de serviço.

Manifesto: agora eu quero um objeto personalizado

Existe um objeto padrão para “a lista do parceiro para terça-feira no CD de Phoenix”? Não exatamente, e não vou forçá-lo num objeto sem relação só para dizer que ficamos no padrão. Manifesto → Manifest__c. É a unidade de recebimento: de onde veio (um arquivo, um lote de API), quando, seu status e totais e, quando um parceiro o reenvia no próprio dia, o que é comparado. Cada linha do manifesto vira uma Ordem de serviço ligada de volta a ele.

Personalizado não é fracasso. É o que a plataforma nos dá quando um conceito não tem um lar padrão limpo. O erro não é criar um objeto personalizado; é criar um sem verificar se a plataforma já tem o conceito.

Click to enlarge

Passo 3 de 4: o único objeto personalizado, onde nenhum objeto padrão serve.

Fotos: só porque o Salesforce consegue guardar não significa que deva

“Precisamos das fotos das entregas no Salesforce.” O que “no Salesforce” quer dizer? Os usuários precisam vê-las a partir do Salesforce, sim. Isso significa que os arquivos de imagem precisam viver no armazenamento do núcleo? Não necessariamente. Conte os zeros: umas quatro fotos por entrega, mais com instalações, num milhão de entregas por ano, são quatro a cinco milhões de fotos por ano, e as entregas crescem 30% ao ano.

Então minha posição de partida: não transforme a org do núcleo num repositório gigante de fotos porque os usuários precisam acessar fotos. Os arquivos pertencem a um armazenamento feito para esse volume, fora do núcleo, com o Salesforce guardando o que precisa para encontrá-los e mostrá-los: uma referência, uma contagem, ou um pequeno registro de índice por foto, e um sinalizador de que as fotos obrigatórias da instalação estão completas. O acesso aos dados e o lugar onde os dados vivem fisicamente são duas perguntas diferentes. É o módulo 4 voltando.

Campos: torne o significado visível

A Ordem de serviço precisa de campos: a referência do parceiro, a janela de entrega, o horário real da entrega, o status, observações como “código do portão” ou “cachorro no quintal”. Não vou transformar isto num catálogo de campos; o módulo 6 fez isso. Faça as perguntas para cada um: o que significa, quem é o dono, se muda, se é um identificador, um vocabulário controlado, armazenado ou derivado, sensível. A referência do parceiro é o ID externo, então sua unicidade faz parte do contrato da integração, não é só uma caixa de seleção. O horário real da entrega é um momento, então Data/Hora. O status determina comportamento, então uma lista controlada, nunca texto livre. E observações de entrega sobre a casa de uma pessoa são dados pessoais, então são classificadas. Cada campo se rastreia de volta ao significado.

Relacionamentos: não ligue só as caixas

Conta para Ordem de serviço, Ordem de serviço para seus itens de linha, Manifesto para Ordem de serviço, Tipo de trabalho descrevendo a parada. Depois as perguntas do módulo 7 para cada linha: o filho pode existir sozinho, quem é o dono, o acesso é herdado, ele pode se mover, o que acontece na exclusão, quantos filhos podem se acumular? Todas as Ordens de serviço sob um punhado de contas de Parceiro varejista significam centenas de milhares de filhos por pai: uma questão de desequilíbrio que vamos responder na Parte 2. E, para os relacionamentos padrão do Field Service, verifique como a Salesforce já os construiu em vez de presumir que batem com o que teríamos projetado. Quando você adota um modelo padrão, adota as decisões que a Salesforce tomou dentro dele. Entenda-as antes de construir por cima.

Propriedade e o Destinatário: não deixe o padrão decidir

Duas decisões que um padrão tomaria por nós com todo o prazer.

Quem é dono de uma entrega? Respondemos isso no módulo 8, e a resposta passa direto para a Ordem de serviço: a propriedade não determina o acesso de ninguém aqui, então o usuário de integração é dono das Ordens de serviço que cria. Os despachantes veem as do seu centro de distribuição, as equipes veem as das suas rotas, e cada Parceiro varejista vê as suas pelo portal, tudo por compartilhamento, não por propriedade. O usuário de integração não tem papel e fica fora dos grupos públicos que nossas regras de compartilhamento usam, porque a 3.300 por dia ele passa de 10 mil registros em três dias. E registramos o que acontece se esse usuário um dia for substituído.

O que é o Destinatário? Um Contato? Uma conta pessoal? Algo guardado só na entrega? Depende de a Steve Trucking ter ou não alguma relação com essas pessoas (elas são clientes dos Parceiros varejistas), de um parceiro poder um dia ver os de outro, de por quanto tempo os dados pessoais delas podem ser guardados, e da escala: cerca de um milhão de Destinatários novos por ano. Ainda não temos tudo isso, e tudo bem. Às vezes a resposta certa é ainda não sabemos o suficiente. Anote a pergunta e vá buscar a informação; não enterre a incerteza num objeto personalizado. Respondemos no checkpoint da Parte 1, depois que os capítulos 4 a 6 nos derem o quadro corporativo e de dados mestres.

Consistência: proteja o modelo na camada certa

A escada do módulo 9 vale aqui: a referência do parceiro é um ID externo, único, então um manifesto reenviado faz upsert em vez de duplicar; o status é uma lista restrita; o horário real da entrega só é obrigatório quando o status diz Entregue; uma parada de instalação não pode fechar sem seu checklist e suas fotos. Não um flow gigante. Cada regra no seu próprio degrau.

Onde cada peça vive

Mais uma passada pelo recorte, com a pergunta do módulo 4: onde vive cada dado? No meu deck de aula é um slide só, lógico contra físico: as entidades lógicas do capítulo 2, e onde cada uma cai fisicamente: no núcleo (on core), como um sObject (__c se for personalizado) ou um big object (__b), ou fora do núcleo (off core), como um objeto externo (__x) ou dados que nunca entram no Salesforce.

• No núcleo, trabalhados todo dia: a Conta, as Ordens de serviço e seus itens de linha, os Compromissos de serviço, os Tipos de trabalho, Manifest__c.
• No núcleo, arquivados: entregas com mais de três anos vão para o Histórico de entregas (Delivery History), um big object, ainda ali para reclamações, no depósito dos fundos.
• Referenciados: os detalhes do pedido do próprio Parceiro varejista ficam no sistema do parceiro; guardamos a referência do parceiro como ID externo, e alcançamos o resto por um objeto externo ou pela integração quando alguém precisa.
• Fora do núcleo: as fotos, num armazenamento feito para milhões de imagens, com um link a partir da Ordem de serviço.

Isso é o modelo físico: não só qual objeto, mas qual casa.

Agora olhe o recorte inteiro

• Parceiro varejista → Conta, com um tipo de registro Retail Partner; gerentes de CD como Contatos.
• Entrega → Ordem de serviço do Field Service, agendada por meio de um Compromisso de serviço.
• Item de entrega → Item de linha da ordem de serviço.
• Tipo de parada → Tipo de trabalho.
• Manifesto → Manifest__c personalizado.
• Referência do parceiro → ID externo na Ordem de serviço, único por parceiro.
• Fotos → guardadas fora do núcleo; o Salesforce mantém a referência e o sinalizador de completude.
• Histórico de entregas → arquivado num big object depois de três anos.
• Propriedade → o usuário de integração, com acesso por compartilhamento (módulo 8).
• Destinatário → em aberto, para o checkpoint da Parte 1.

Click to enlarge

Passo 4 de 4: o recorte inteiro, no núcleo, arquivado e fora do núcleo. Toda linha é um relacionamento de pesquisa: a Salesforce construiu o Field Service com relacionamentos de pesquisa, e adotamos as decisões dela junto.

O diagrama não é a arquitetura

Posso lhe entregar esse diagrama, e ele não basta. A arquitetura é o raciocínio por trás dele. Por que Conta? Uma empresa com encaixe limpo. Por que Ordem de serviço e não Delivery__c? A entrega se comporta como trabalho de campo, e o Field Service já está implantado. Por que um Manifesto personalizado? Não há lar padrão limpo. Por que as fotos não são simplesmente Arquivos? Volume e economia de armazenamento. Por que um ID externo? Outro sistema precisa de uma identificação estável através da fronteira. Por que o usuário de integração é dono das Ordens de serviço? A propriedade não determina o acesso aqui, e isso mantém a trilha de auditoria honesta. Por que o Destinatário ainda está em aberto? Ainda não respondemos a perguntas suficientes. As linhas são o resultado; as decisões as produziram.

Então eis o hábito com que quero que você saia do capítulo 3. Aponte para qualquer coisa num modelo físico e pergunte por quê? Por que este objeto, este tipo, este relacionamento, este proprietário, este lugar, esta regra? Você deve conseguir rastrear a resposta de volta: da configuração ao modelo físico, ao modelo lógico, ao requisito de negócio. Se não consegue, alguém projetou a partir do Setup.

E você deve ter notado os números que ainda não trabalhamos por completo: entregas por parceiro, itens de linha, fotos, retenção, arquivamento. Ótimo. Pergunte o número de zeros antes de travar um design: um modelo que funciona lindamente com cinquenta mil registros pode se comportar de forma muito diferente com quinhentos milhões. Isso é a Parte 2.

Além do exame: o que a IA muda. Dê o briefing da Steve Trucking a uma IA e ela vai produzir um esquema em segundos: Conta, Ordem de serviço, objetos personalizados, campos, até metadados de deploy. É um acelerador fantástico, e não é a revisão. O trabalho do arquiteto passa a ser verificar os mapeamentos e suas consequências: encaixe, licenças, propriedade, ciclo de vida, escala, identificação, segurança e o que fica fora da plataforma. A IA é o foguete propulsor; ela não lhe diz se você está apontado na direção certa.

O que um arquiteto decide aqui

• Como cada conceito de negócio se mapeia para o Salesforce: um objeto padrão, um objeto personalizado ou algo fora do núcleo.
• Quais identificadores, campos e relacionamentos implementam o significado de negócio sem mudá-lo em silêncio.
• Que comportamento da plataforma e que licenciamento vêm com um modelo padrão que você adota.
• Quais decisões de propriedade, ciclo de vida, consistência, armazenamento e escala precisam ser tomadas antes de o design estar completo.
• Quais perguntas ficam explicitamente em aberto, em vez de escondidas atrás de uma escolha arbitrária de implementação.

No início deste capítulo perguntamos como o modelo deveria viver no Salesforce. Isso é arquitetura de dados Salesforce: não criar objetos, não decorar o Setup, não desenhar caixas mais bonitas, mas encaixar de forma deliberada o modelo de negócio na forma da plataforma. Cada estrutura é um compromisso. Assuma os que você consegue explicar.

Para saber mais

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) e WorkType (opens in a new tab) (em inglês), consultados em 2026-10-02.
• O briefing da Steve Trucking (em inglês).