Steve Trucking, o que eu arquitetaria

🌐 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 6 de 6 do capítulo Dados mestres e identidade, capítulo 6 do curso Data Architect, e o fim da Parte 1. Anterior: Quando a autoridade é compartilhada · Próximo: a Parte 2 começa com Designing for Scale (coming soon)

A pergunta que este checkpoint responde: Você consegue juntar a Parte 1 num cenário real?

Tente o desafio primeiro. Este é o meu passo a passo do desafio do Checkpoint 1. Se você ainda não desenhou o seu próprio design, faça isso antes de continuar lendo. O valor está em comparar o seu raciocínio com o meu, não em ler a resposta.

Isto é “O que eu arquitetaria”: uma solução viável possível, não a resposta, com os trade-offs nomeados e minhas posições tomadas. Ainda não cobrimos grandes volumes de dados, design de consultas, padrões de integração, migração nem transações, e isso é de propósito: a arquitetura se desenvolve à medida que você aprende mais. Mas a Parte 1 nos dá o bastante para montar o esqueleto.

Comece pelos números

Do briefing: cerca de 3.300 entregas por dia útil, um milhão por ano, crescendo 30% ao ano. Cerca de 1,6 item de linha por entrega (1,6 milhão por ano); umas oito mudanças de status por entrega (8 milhões por ano); quatro a cinco milhões de fotos por ano; cerca de 200 mil leituras de GPS por dia; cerca de 180 mil casos por ano; três Parceiros varejistas enviando manifestos de três jeitos diferentes; nove centros de distribuição; 330 caminhões com equipes de duas pessoas. E a Steve Trucking já roda uma org Salesforce com Service Cloud, Field Service e um portal de parceiros. Conte os zeros antes de desenhar uma única caixa. Eles vão decidir várias coisas a seguir.

O núcleo das entregas: olhe para a nave-mãe

As entregas são o coração disto, e o Field Service já faz o despacho. Então começo pelo modelo padrão do Field Service, como fez o recorte do capítulo 3:

Conceito de negócio	Objeto Salesforce	Por quê
Parceiro varejista	Account (tipo de registro Retail Partner)	Uma empresa com a qual a Steve Trucking tem contrato; carrega contratos, casos e acesso ao portal
Pessoal do parceiro (gerentes de CD, pessoal das lojas)	Contact	Usuários do portal precisam ser Contatos
Uma entrega: um Destinatário, um endereço, um pedido do parceiro, um dia	Work Order	A unidade de trabalho do Field Service; o agendamento, o app móvel e os relatórios de serviço dependem dela
Cada item ou serviço: a geladeira, a instalação, o recolhimento	Work Order Line Item	Divide o trabalho, guia os checklists e o faturamento
O tipo de parada: só entrega, com instalação, com recolhimento	Work Type	Define a duração, as habilidades e o checklist de instalação
A visita agendada e sua janela	Service Appointment	O que o Field Service agenda e o app da equipe mostra
Equipes e caminhões; áreas de despacho dos CDs	Service Resource, Service Crew, Service Territory	O Field Service agenda uma equipe como um único recurso
Dúvidas dos Destinatários, reclamações dos parceiros	Case	O console de atendimento, direitos (entitlements), e-mail para caso
A lista do parceiro para terça-feira no CD de Phoenix	Manifest__c (personalizado)	Nada padrão representa a unidade de recebimento, reconciliação e reprocessamento

Todo o resto continua padrão. Resistir a mais objetos personalizados é deliberado: a pergunta do capítulo 1 era quando um arquiteto deve resistir a mais um, e aqui a resposta é “quase sempre”. A linha de pedido do parceiro, por exemplo, não é um objeto novo. É a Ordem de serviço, identificada pela referência do parceiro.

Click to enlarge

Ele cresce a partir do final do capítulo 3 (Projete o modelo físico Salesforce): os mesmos objetos nos mesmos lugares, com a equipe, a área de despacho, o caso e o que o Checkpoint 1 mantém fora do núcleo acrescentados.

A chave que casa o pedido de um parceiro com uma entrega

Cada linha do manifesto vira uma Ordem de serviço, ligada ao seu Manifesto. A chave é a pergunta que mais quero respondida: como sabemos que esta linha do parceiro é aquela entrega? Minha resposta: um ID externo na Ordem de serviço construído a partir do Parceiro varejista e da própria referência de pedido e de entrega do parceiro (algo como KEYSTONE-PHX-8843119-1), marcado como único. Um campo por fonte, um-para-um. É o identificador do parceiro, não o nosso: o “vários identificadores para uma coisa” do capítulo 2, e o “o parceiro é dono da sua referência de pedido” do módulo 1.

Por que importa: os manifestos chegam com um a dois dias de antecedência e são revisados no próprio dia. Com essa chave, cada manifesto reenviado ou revisado faz upsert em vez de criar duplicatas. A revisão atualiza a Ordem de serviço, um campo a registra, e uma mudança numa entrega já roteirizada alerta o coordenador: a mudança do parceiro é aplicada, mas sinalizada até o despacho confirmá-la. É também isso que muda em relação ao desenho do capítulo 4. Hoje todo manifesto cai no RouteDesk, e os coordenadores redigitam as rotas no Salesforce e as paradas concluídas de volta. Neste design, os manifestos entram direto no Salesforce, com upsert pela chave do parceiro; o RouteDesk é aposentado, e a redigitação acaba. O capítulo de integração projeta os três formatos de entrada. A decisão de dados é a chave.

O Destinatário: conta pessoal, Contato ou nenhum dos dois?

Esta é a decisão de dados mais interessante da Parte 1, então aqui estão as opções, e depois a minha escolha.

Opção A: contas pessoais. Cada Destinatário vira uma conta pessoal, ligada a cada entrega. A favor: padrão, funciona naturalmente com o Service Cloud, as mensagens e o console, reconhece Destinatários recorrentes. Contra: cerca de um milhão de novos Destinatários por ano, cada um uma conta pessoal com cerca do dobro do armazenamento de uma conta comercial (Estimated Record Size by Object Type (opens in a new tab), em inglês), então, em dois anos, um dos maiores objetos da org. E os Destinatários não são clientes da Steve Trucking. São clientes de cada Parceiro varejista, e a Steve Trucking nunca pode misturar o cliente de um parceiro com o de outro (S2).

Opção B: Contatos sob a conta do Parceiro varejista. Contra: um milhão de Contatos sob três ou quatro contas é desequilíbrio pai-filho em escala gigantesca, muito além da orientação da Salesforce de cerca de 10 mil filhos por pai (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab), em inglês). Esta é a opção para mostrar, e rejeitar.

Opção C: o Destinatário vive na entrega. O nome, o telefone, o e-mail, o endereço e as observações de entrega do Destinatário são campos na Ordem de serviço (os campos de endereço já são padrão ali), capturados do manifesto. A favor: nenhum objeto grande novo; os dados vivem exatamente enquanto a entrega precisa deles; a exclusão acontece por entrega, no prazo do parceiro; e o isolamento entre parceiros vem de graça, porque cada entrega pertence a um parceiro. Contra: um Destinatário recorrente não é reconhecido como a mesma pessoa.

Esse é o equilíbrio a encontrar. Algum dia vai ser preciso reconhecer várias entregas como sendo da mesma pessoa, no mesmo lugar? Dar um login para essa pessoa? Essa é a linha entre um Destinatário que precisa de um registro próprio e os dados do Destinatário que são simplesmente dados sobre a entrega. E existe um caminho do meio. Leve o próprio ID de cliente do Parceiro varejista como um campo na entrega, um Retail Partner Customer ID (ID de cliente do Parceiro varejista). Ele não cria um registro de Destinatário, mas amarra as entregas que um parceiro envia para o mesmo cliente, o que é o começo de uma experiência do cliente mais unificada, e leva direto de volta ao sistema do Parceiro varejista, onde esse cliente realmente vive. É o identificador deles, então só significa algo junto com o parceiro: o cliente 4417 de um parceiro não tem nada a ver com o de outro.

Na minha opinião profissional, a Opção C é a escolha certa. A parte do não reconhecimento é aceitável, até desejável: a Steve Trucking não tem relacionamento com essas pessoas além da entrega. É o módulo 1 de novo: o Destinatário é cliente do parceiro, e o parceiro é a autoridade sobre quem ele é. E é o capítulo 5: dados pessoais que caem num só lugar, ligados a uma entrega, são muito mais fáceis de proteger, reter e excluir. E ela se sustenta diante das formas normais do capítulo 2: os dados do Destinatário são um para um com a entrega, então pertencem a ela. Um filho Destinatário separado economizaria alguns valores repetidos ao custo de mais um objeto, mais um relacionamento e a sobrecarga dele, e a única forma de economizar mais seria tratar a mesma pessoa como uma só entre Parceiros varejistas, o que não vamos fazer. Então a entrega carrega o Destinatário, com o Retail Partner Customer ID como o caminho de volta ao próprio sistema do parceiro.

Click to enlarge

Eu unificaria os Destinatários entre parceiros?

João Silva, Rua Principal, 123, aparece no manifesto da Redrock e no da Brightwave. Provavelmente a mesma pessoa. A Steve Trucking deve unificá-los? Não, de propósito. Unificar Destinatários entre Parceiros varejistas violaria o S2: um parceiro nunca pode ver os Destinatários de outro, e uma identidade unificada é exatamente a ponte por onde isso vaza. É a posição deste capítulo aplicada: corresponda de menos onde misturar custa caro, e aqui misturar custa muito caro.

Se mais tarde um Parceiro varejista quiser o reconhecimento de Destinatários recorrentes dentro das suas próprias entregas, esse é um trabalho para uma ferramenta de resolução de identidade, como a do Data 360, limitada àquele parceiro: um mapa no estilo registry, não uma conta pessoal, e nunca entre parceiros. Um mapa de quem é quem não concede propriedade, e não concede acesso.

O que fica na org, e o que não fica

O capítulo 3 perguntou onde os dados devem viver. Aqui os zeros respondem:

• O status atual vive no Compromisso de serviço e na Ordem de serviço. O histórico das mudanças de status, cerca de 8 milhões por ano e crescendo, não precisa viver na org do núcleo. Cada mudança é publicada como um evento e guardada no data warehouse, o Snowflake. A org guarda o estado atual; o histórico continua lá para atendimento, operações e análise, só que não no banco de dados operacional.
• As fotos (quatro a cinco milhões por ano, algumas mostrando pessoas ou o interior de uma casa) vivem fora do núcleo, num armazenamento feito para esse volume, enviadas direto do app da equipe. A org guarda só o que precisa: um pequeno registro de índice por foto, ou só uma contagem e um sinalizador de “fotos obrigatórias da instalação completas”. Minha preferência é a opção mais leve: manter a org enxuta, e deixar o repositório de fotos ser dono do seu índice e da sua retenção.
• As leituras de GPS (200 mil por dia) ficam no FleetLink e vão para o Snowflake; a org só precisa da última posição para a página de rastreamento e o mapa do despachante.
• Os oito anos de histórico do RouteDesk (cerca de 5 milhões de entregas) vão para o data warehouse ou um arquivo, acessíveis para reclamações. O que, se é que algo, entra na org é uma decisão de migração para a Parte 2.

Click to enlarge

Checkpoint 1: o que eu arquitetaria. Os mesmos lugares do panorama do capítulo 4 (O panorama da Steve Trucking), sem a redigitação e sem a planilha.

Quem vê o quê, e quem precisa de licença

• Os Parceiros varejistas veem só as suas próprias entregas (S2). Cada Ordem de serviço carrega seu Parceiro varejista; os usuários do portal veem as entregas do seu parceiro, e os gerentes de CD só as do seu CD.
• Os usuários parceiros precisam de uma licença de portal que suporte regras de compartilhamento e papéis: Customer Community Plus ou Partner Community. Os lugares no estádio do capítulo 3: os lugares mais baratos não recebem o compartilhamento de que este design precisa. As duas licenças precisam de papéis para os usuários externos, e a Salesforce avisa que mais papéis deixam a org mais lenta (Experience Cloud User Licenses (opens in a new tab), em inglês). Um papel por parceiro e por CD tudo bem; um papel para cada loja, não.

Conhecimento para o exame. Saiba quais licenças externas trazem compartilhamento padrão: Customer Community Plus e Partner Community (com papéis para os usuários externos), não a Customer Community, que usa conjuntos de compartilhamento.

• Os Destinatários não precisam de licença. A página de rastreamento mostra uma entrega por meio de um link com um token que expira (S3), não de um login.
• Cuidado com o desequilíbrio. Centenas de milhares de Ordens de serviço por ano apontando para três ou quatro contas de parceiros é desequilíbrio de dados na conta. Uma opção é uma conta filha por CD sob cada parceiro, o que espalha os filhos por nove ou mais pais; arquivar as entregas concluídas depois do prazo de reclamações mantém baixo o número de filhos ativos por pai. A Parte 2 enfrenta isso.

O que eu não faria

Eu não criaria uma conta pessoal para cada Destinatário só porque um Destinatário é um indivíduo. Não penduraria um milhão de Contatos em três contas. Não construiria um objeto Entrega personalizado ao lado da Ordem de serviço do Field Service. Não unificaria Destinatários entre parceiros. Não colocaria milhões de fotos ou leituras de GPS no armazenamento do núcleo. E não chamaria um Destinatário unificado de golden record a menos que tivéssemos de fato tomado uma decisão de dados mestres.

O que ainda está em aberto

A Parte 1 montou o esqueleto; a Parte 2 o testa. A régua de grandes volumes de dados no terceiro ano (Ordens de serviço, Compromissos de serviço e itens de linha estão todos em território de grande volume em dois ou três anos), o design de consultas para visualizações de lista limitadas por parceiro, as três integrações de entrada e os três feeds de status, a migração do RouteDesk, as transações no próprio dia, e o design de segurança por trás do portal. A Steve Trucking também vai mudar. Guarde este design; você vai revisitá-lo.

O que um arquiteto decide aqui

• Quais objetos padrão carregam o núcleo (aqui, os do Field Service), e quais objetos personalizados são realmente justificados (aqui, um).
• A chave que casa a linha de pedido de cada parceiro com uma entrega, e por que ela pertence ao parceiro.
• O que é o Destinatário, com base no relacionamento que a Steve Trucking realmente tem com ele.
• Se identidades devem ser unificadas, e onde misturar é caro demais para arriscar.
• O que fica na org, o que vive fora do núcleo, e de quais licenças o design depende.

Para saber mais

• O briefing e os desafios da Steve Trucking (em inglês) (D1, D3, DC1).
• Salesforce Help, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) e Experience Cloud User Licenses (opens in a new tab) (em inglês), consultados em 2026-10-14.
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (em inglês), como citado no capítulo 3.