Projete o modelo físico Salesforce

🌐 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 10 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Manter os dados consistentes · Próximo: o guia de estudo do capítulo, depois o próximo capítulo, Entender os dados empresariais

A pergunta que este módulo responde: Como transformamos o 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, relações, 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 só diagrama. Quero algo sobre o qual possamos raciocinar: um Parceiro retalhista envia um manifesto, a Steve Trucking entrega o que nele está, 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 retalhista, Destinatário, Manifesto, Entrega, Item de entrega, o tipo de paragem, Equipa, Camião, Centro de distribuição, fotografias. Demos nome às relações e perguntámos o que significam. Não vou repetir isso. A pergunta agora é como vivem estes conceitos no Salesforce. Um facto do briefing importa logo à partida: a Steve Trucking já usa o Field Service para marcações, equipas e a aplicação móvel.

Parceiro retalhista: não invente uma conta

Um Parceiro retalhista é uma empresa para a qual a Steve Trucking trabalha. O Salesforce já tem um objeto projetado para empresas: a Conta. Encaixe limpo. Por isso nada de Retail_Partner__c só porque o negócio diz «parceiro». É uma Conta, com um tipo de registo Retail Partner para a diferenciar de outras organizações, e com ela vêm contratos, casos, Contactos para os gestores de CD, e acesso ao portal para esses Contactos. Decisão fácil. Nem todas são.

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

Cada Parceiro retalhista envia as suas próprias referências. A encomenda de um parceiro tem o aspeto 8843119, a de outro o aspeto A-984732. Estes números importam, mas de quem são? Do parceiro. O Salesforce tem o seu próprio ID de registo, e o parceiro tem a referência que usa quando fala connosco. Os dois podem existir; é o «uma coisa, vários identificadores» do capítulo 2.

Por isso a referência do parceiro torna-se um ID externo que a integração usa para fazer corresponder 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 chegou primeiro, e não ponha uma integração a pesquisar num campo de texto sempre que precisa de encontrar um registo.

Entrega: olhe para a nave-mãe

É aqui que apetece criar Delivery__c. O negócio disse «entrega», por isso precisamos de um objeto Entrega. É exatamente o que não quero que faça primeiro. Olhe para a nave-mãe, como fizemos no módulo 2. O que tem já o Salesforce para trabalho feito num local, com ciclo de vida, itens, agendamento e uma equipa no terreno? A Ordem de trabalho (Work Order) do Field Service: a Salesforce descreve-a como trabalho de serviço de campo a fazer para um cliente (WorkOrder (opens in a new tab), em inglês). A visita agendada e a sua janela horária são a Marcação de serviço (Service Appointment), e é isso que a expedição agenda e a aplicação da equipa mostra.

Então Entrega → Ordem de trabalho. Não porque as palavras coincidem; não coincidem. Porque o comportamento coincide com a capacidade da plataforma pela qual já estamos a pagar e que pretendemos usar. Um objeto padrão não precisa de partilhar o vocabulário do negócio. Precisa de 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 por baixo.

Mas objetos padrão vêm com bagagem

A outra metade: a Ordem de trabalho não é de graça. Traz o licenciamento do Field Service, as suas próprias relações, comportamento de segurança, campos obrigatórios, automação e ciclo de vida, e outras partes da plataforma esperam que se comporte de certa forma. Estamos a escolhê-la porque o encaixe é limpo e porque estamos a usar o que foi construído à sua volta. Se a Steve Trucking não quisesse nada do Field Service e o modelo lutasse contra o processo a cada passo, reconsideraria. A arquitetura é o encaixe, não o rótulo.

Itens de entrega: siga o modelo

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

Que tipo de paragem é esta?

Na Steve Trucking uma paragem é só entrega, entrega com instalação ou entrega com recolha, e cada tipo tem a sua própria duração, competências da equipa 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 trabalho e itens de linha (WorkType (opens in a new tab), em inglês). Então Tipo de paragem → Tipo de trabalho. Mais uma vez, 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 trabalho.

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 o vou forçar num objeto sem relação só para dizer que ficámos no padrão. Manifesto → Manifest__c. É a unidade de receção: de onde veio (um ficheiro, um lote de API), quando, o seu estado e totais e, quando um parceiro o reenvia no próprio dia, o que é comparado. Cada linha do manifesto torna-se uma Ordem de trabalho ligada de volta a ele.

Personalizado não é fracasso. É o que a plataforma nos dá quando um conceito não tem uma casa padrão limpa. 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.

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

«Precisamos das fotografias das entregas no Salesforce.» O que quer dizer «no Salesforce»? Os utilizadores precisam de as ver a partir do Salesforce, sim. Isso significa que os ficheiros de imagem têm de viver no armazenamento do núcleo? Não necessariamente. Conte os zeros: umas quatro fotografias por entrega, mais com instalações, num milhão de entregas por ano, são quatro a cinco milhões de fotografias por ano, e as entregas crescem 30% ao ano.

Por isso a minha posição de partida: não transforme a org do núcleo num repositório gigante de fotografias só porque os utilizadores precisam de aceder a fotografias. Os ficheiros pertencem a um armazenamento feito para esse volume, fora do núcleo, com o Salesforce a guardar o que precisa para os encontrar e mostrar: uma referência, uma contagem, ou um pequeno registo de índice por fotografia, e um indicador de que as fotografias 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 a voltar.

Campos: torne o significado visível

A Ordem de trabalho precisa de campos: a referência do parceiro, a janela de entrega, a hora real da entrega, o estado, notas como «código do portão» ou «cão 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, por isso a sua unicidade faz parte do contrato da integração, não é só uma caixa de verificação. A hora real da entrega é um momento, por isso Data/Hora. O estado determina comportamento, por isso uma lista controlada, nunca texto livre. E as notas de entrega sobre a casa de uma pessoa são dados pessoais, por isso são classificadas. Cada campo rastreia-se até ao significado.

Relações: não ligue só as caixas

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

A propriedade e o Destinatário: não deixe o padrão decidir

Duas decisões que um valor por defeito tomaria por nós com todo o gosto.

Quem é dono de uma entrega? Respondemos a isso no módulo 8, e a resposta passa diretamente para a Ordem de trabalho: a propriedade não determina aqui o acesso de ninguém, por isso o utilizador de integração é dono das Ordens de trabalho que cria. Os expedidores veem as do seu centro de distribuição, as equipas veem as das suas rotas, e cada Parceiro retalhista vê as suas pelo portal, tudo por partilha, não por propriedade. O utilizador de integração não tem função e fica fora dos grupos públicos que as nossas regras de partilha usam, porque a 3.300 por dia passa dos 10 mil registos em três dias. E registamos o que acontece se esse utilizador alguma vez for substituído.

O que é o Destinatário? Um Contacto? Uma conta pessoal? Algo guardado só na entrega? Depende de a Steve Trucking ter ou não alguma relação com estas pessoas (são clientes dos Parceiros retalhistas), de um parceiro poder alguma vez ver os de outro, de quanto tempo os seus dados pessoais podem ser guardados, e da escala: cerca de um milhão de Destinatários novos por ano. Ainda não temos tudo isso, e não faz mal. À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 de os capítulos 4 a 6 nos darem o quadro empresarial 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, por isso um manifesto reenviado faz upsert em vez de duplicar; o estado é uma lista restrita; a hora real da entrega só é obrigatória quando o estado diz Entregue; uma paragem de instalação não pode fechar sem a sua checklist e as suas fotografias. Não um flow gigante. Cada regra no seu próprio degrau.

Onde cada peça vive

Mais uma passagem pelo recorte, com a pergunta do módulo 4: onde vive cada dado? No meu deck de aula é um só diapositivo, 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 todos os dias: a Conta, as Ordens de trabalho e os seus itens de linha, as Marcações de serviço, os Tipos de trabalho, Manifest__c.
• No núcleo, arquivados: as entregas com mais de três anos passam para o Histórico de entregas (Delivery History), um big object, ainda ali para reclamações, no armazém das traseiras.
• Referenciados: os pormenores da encomenda do próprio Parceiro retalhista ficam no sistema do parceiro; guardamos a referência do parceiro como ID externo, e chegamos ao resto por um objeto externo ou pela integração quando alguém precisa.
• Fora do núcleo: as fotografias, num armazenamento feito para milhões de imagens, com uma ligação a partir da Ordem de trabalho.

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

Agora olhe para o recorte inteiro

• Parceiro retalhista → Conta, com um tipo de registo Retail Partner; gestores de CD como Contactos.
• Entrega → Ordem de trabalho do Field Service, agendada através de uma Marcação de serviço.
• Item de entrega → Item de linha da ordem de trabalho.
• Tipo de paragem → Tipo de trabalho.
• Manifesto → Manifest__c personalizado.
• Referência do parceiro → ID externo na Ordem de trabalho, único por parceiro.
• Fotografias → guardadas fora do núcleo; o Salesforce mantém a referência e o indicador de completude.
• Histórico de entregas → arquivado num big object depois de três anos.
• Propriedade → o utilizador de integração, com acesso por partilha (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. Cada linha é uma relação de pesquisa: a Salesforce construiu o Field Service com relações de pesquisa, e adotamos as decisões dela com ele.

O diagrama não é a arquitetura

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

Por isso eis o hábito com que quero que saia do capítulo 3. Aponte para qualquer coisa num modelo físico e pergunte porquê? Porquê este objeto, este tipo, esta relação, este proprietário, este lugar, esta regra? Deve conseguir rastrear a resposta: 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 deve ter reparado nos números que ainda não trabalhámos por completo: entregas por parceiro, itens de linha, fotografias, retenção, arquivo. Ótimo. Pergunte o número de zeros antes de fechar um design: um modelo que funciona lindamente com cinquenta mil registos pode comportar-se 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 produz um esquema em segundos: Conta, Ordem de trabalho, 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 as 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 propulsor do foguetão; não lhe diz se 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.
• Que identificadores, campos e relações implementam o significado de negócio sem o mudar em silêncio.
• Que comportamento da plataforma e que licenciamento vêm com um modelo padrão que adota.
• Que decisões de propriedade, ciclo de vida, consistência, armazenamento e escala têm de ser tomadas antes de o design estar completo.
• Que 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 perguntámos como deveria viver o modelo 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 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).