Hierarquias e dados de mão dupla

🌐 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 5 de 6 do capítulo Dados mestres e identidade, capítulo 6 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Um mapa não é uma decisão · Próximo: Checkpoint 1: Steve Trucking

A pergunta que este módulo responde: Como gerenciar dados que mais de um sistema mantém?

A arquitetura fácil: o ERP é dono do cliente, o Salesforce recebe uma cópia, pronto. Empresas reais não são tão limpas. O ERP é dono do cliente legal e o Salesforce do relacionamento de vendas; uma divisão vive no SAP, uma adquirida num ERP diferente; os prospects existem só no Salesforce. Aí alguém quer que os usuários do Salesforce atualizem um campo controlado pelo ERP, e as setas começam a apontar para os dois lados. Como digo quando ensino isto: “O mais difícil são os bidirecionais.” Não porque mandar dados nos dois sentidos seja tecnicamente difícil, mas porque, quando os dois sistemas participam da mudança, você precisa ser extremamente preciso sobre a autoridade.

Dados de mão dupla não significam dois mestres

O ERP é dono do endereço de cobrança, copiado para o Salesforce. Um vendedor fica sabendo pelo cliente que ele mudou, e o negócio quer que o vendedor o atualize sem sair do Salesforce. Razoável. Agora os dados fluem ERP → Salesforce e Salesforce → ERP. O Salesforce agora é codono do endereço de cobrança? Não. A direção de uma integração não decide a autoridade. O vendedor não está alterando a cópia do Salesforce. Em termos de arquitetura, ele está pedindo para alterar o valor com autoridade. Você não está alterando o campo do ERP; está pedindo para alterá-lo. O Salesforce é a interface; o ERP continua sendo o mestre.

Isso muda o design. Se o Salesforce fosse dono do campo, salvar e pronto. Se o ERP é o dono, “salvar” significa que o Salesforce envia o endereço proposto, o ERP o valida e aceita, atualiza seu mestre, e devolve o valor com autoridade. Só então o valor governado mudou: solicitar → validar → aceitar → publicar, e não “atualizar os dois sistemas e torcer para que continuem sincronizados”.

Click to enlarge

Uma integração bidirecional não cria autoridade bidirecional.

Quando o mestre diz não

O ERP rejeita a mudança: o cliente está inativo, o endereço viola uma regra do ERP, o usuário não pode alterar endereços legais, o ERP está fora do ar, ou outra pessoa alterou o cliente nesse meio-tempo. Se o Salesforce já mostrava o endereço novo, agora temos duas verdades, e o módulo 1 já nos disse qual vence: a do ERP. Então a arquitetura precisa de um estado de solicitado, ainda não aceito: um valor proposto separado, um sinalizador de “mudança pendente”, ou esperar a confirmação antes de exibi-lo. O mecanismo depende do caso de uso. A regra não: nunca deixe uma solicitação rejeitada virar uma verdade concorrente.

Loops e colisões

Eis um clássico. O ERP atualiza o Salesforce; a integração do Salesforce vê uma mudança e a envia ao ERP; o ERP vê uma atualização e a devolve. Você construiu um loop muito caro. Um bom design de mão dupla sabe onde uma mudança começou, se o mestre a aceitou, e se esta é uma nova mudança de negócio ou só o eco de uma já processada: identificadores de origem, timestamps, metadados de integração, processamento idempotente. O capítulo de integração vai fundo. O princípio de dados mestres é simples: saiba se você está originando uma mudança ou refletindo uma.

Depois vêm as colisões. Você já viu uma no capítulo 5: um vendedor pede Steve’s Plumbing LLC enquanto alguém no ERP digita Steve’s Plumbing L.L.C. (Proteja o registro governado). Aqui vai outra. O Salesforce propõe Rua Principal, 125; quase no mesmo instante, um usuário do ERP a altera para 130. Qual vence? Não há resposta técnica universal. Talvez o ERP sempre vença porque é dono do campo; talvez a solicitação do Salesforce vá para uma fila de revisão; talvez vença a mudança aceita mais tarde; talvez o ERP rejeite qualquer atualização cujo valor de partida tenha mudado. Isso é concorrência, mas por baixo há uma decisão de autoridade, e nenhum padrão de integração salva você se ninguém decidiu quem pode fazer a mudança com autoridade.

E um único campo é o caso simples. Um endereço é uma rua, uma cidade, um CEP. O Salesforce envia uma rua nova enquanto o ERP acabou de mudar a cidade. Você deixa a rua passar sozinha? Ou trata o endereço como uma única transação, em que os campos vão todos juntos ou nenhum vai, e rejeita a mudança inteira? Decida quais campos viajam como um grupo antes da primeira colisão, não depois.

Sempre que vejo uma integração de mão dupla, pergunto o que acontece quando os dois lados alteram os mesmos dados? Se a resposta é “isso provavelmente não vai acontecer”, ainda não terminamos. Qual vence, rejeitamos, colocamos na fila, comparamos versões, revisamos? O campo deveria sequer ser editável nos dois lugares? Às vezes o melhor design de mão dupla remove uma direção para um dado atributo: o Salesforce pode solicitar; só o ERP publica o valor aceito. Os dados ainda se movem nos dois sentidos, mas só um sistema é mestre do campo. Essa diferença é tudo.

Hierarquias também são dados mestres

Relacionamentos também podem ser dados mestres. Uma controladora global com regiões na América do Norte e na Europa, cada uma com subsidiárias por país: a própria hierarquia carrega significado. Quem é a controladora? Qual subsidiária fica sob qual entidade legal? Quais contas se consolidam no cliente global? Isso guia relatórios, territórios, preços, contratos, exposição de crédito, atendimento, acesso a dados e análise. Uma hierarquia pode importar tanto quanto os registros nela, e precisa da mesma governança. (O exame cita o gerenciamento de hierarquias; é fácil esquecer.)

No Salesforce, as hierarquias de contas são construídas com o campo Conta pai (Parent Account). A visualização de hierarquia do Lightning mostra até 2.000 contas, e só as que o usuário pode ver; contas pessoais não são suportadas na hierarquia; e o Local da conta (Account Site) distingue os locais de uma empresa (Considerations for Using Account Hierarchy (opens in a new tab), em inglês). Mas o campo Conta pai não responde à pergunta de arquitetura: quem é dono da hierarquia?

Conhecimento para o exame. Conheça o básico da hierarquia de contas: ela é construída com a Conta pai (Parent Account); a visualização do Lightning mostra até 2.000 contas, só as que o usuário pode ver; contas pessoais não são suportadas; e o Local da conta (Account Site) distingue as localidades de uma empresa.

Uma hierarquia, vários mestres

Na minha experiência, as hierarquias têm autoridade dividida. As entidades da América do Norte vêm do SAP, as europeias de outro ERP, os prospects novos são montados no Salesforce, e uma subsidiária adquirida ainda não migrou. Quem é dono da hierarquia? Depende do ramo. Cada ERP controla o seu ramo; o Salesforce controla os relacionamentos dos prospects até que se convertam. É uma arquitetura legítima, desde que todo mundo saiba onde ficam as fronteiras. Decida ramo por ramo.

Click to enlarge

A autoridade sobre a hierarquia pode ser atribuída ramo a ramo.

Então não deixe o campo Conta pai esconder a autoridade. Um usuário troca o pai de uma subsidiária no Salesforce. Tecnicamente trivial. Em termos de arquitetura, ele acabou de mudar a estrutura legal da empresa? Se o ERP é mestre daquele ramo, provavelmente não, então o Salesforce deve bloquear isso, ou transformá-lo numa solicitação de mudança. Ou talvez o Salesforce mantenha legitimamente uma hierarquia comercial enquanto o ERP mantém a legal. Então talvez elas nem devessem ser o mesmo relacionamento.

Uma empresa pode ter várias hierarquias válidas: legal, de faturamento, de vendas, de atendimento, geográfica. A controladora global assina o contrato, as regiões recebem atendimento por conta própria, o faturamento passa por uma entidade financeira compartilhada, vendas gerencia por região. Qual é a hierarquia verdadeira? Todas; elas respondem a perguntas diferentes. O erro é presumir que precisa haver uma só. Deve haver uma autoridade clara para cada tipo de relacionamento: o princípio de atributo do módulo 1, aplicado aos relacionamentos.

E nem todo relacionamento pai-filho é dado mestre. Agrupar as entregas de hoje numa rota é um relacionamento, mas transacional, um evento operacional. Uma hierarquia de clientes descreve um relacionamento de negócio durável. Os dois parecem pai-filho num modelo; não compartilham um ciclo de vida. Pergunte o que o relacionamento significa e por quanto tempo esse significado dura.

Um cliente, dois ERPs

Quando ensino isto, pergunto à turma: quem já trabalhou com um cliente que tem um Salesforce e mais de um ERP? Mãos se levantam toda vez. Pergunte por quê, e os ERPs acabam divididos por região (um para a América do Norte, um para a Europa), por função (uma empresa de encanamento compra uma empresa de elétrica, e cada uma mantém o próprio ERP) ou simplesmente por história: o negócio foi adquirido, e ninguém o migrou ainda.

Pegue a Steve’s Plumbing como cliente. Ela faz negócios na América do Norte, então o ERP norte-americano tem um registro de cliente para ela. Aí ela abre um escritório em Munique, e o ERP europeu cria um registro de cliente próprio, com o próprio número de cliente. Mesma empresa, dois registros, dois IDs. Como represento isso numa única org do Salesforce? Já vi três jeitos.

Uma hierarquia de contas. A Steve’s Plumbing é a pai, com a Steve’s Plumbing North America e a Steve’s Plumbing Europe como contas filhas, cada filha representando o registro de um ERP. O porém: as filhas não são mais exatamente a Steve’s Plumbing. Elas são a Steve’s Plumbing fazendo negócios numa região e, como acabamos de ver, uma hierarquia carrega significado.

Contas pares. Duas contas lado a lado, cada uma com um campo que diz a qual ERP ela pertence: um código de empresa, uma região. Nada fica escondido. O custo aparece nos relatórios: para ver a Steve’s Plumbing no mundo todo, você precisa de algo que diga que essas duas contas são a mesma empresa.

Uma conta, com um filho por ERP. Uma única Steve’s Plumbing, e um objeto filho com um registro para cada ERP guardando o ID de cliente daquele ERP. Dois ERPs ou dez. Os vendedores veem um cliente e fazem um pedido; nos bastidores, flows decidem para qual ERP vai cada linha: o trabalho elétrico para o ERP de elétrica, o de encanamento para o ERP de encanamento. Mas agora você precisa decidir qual ERP é o principal para os valores compartilhados, como nome e endereço, e o que acontece quando o cliente existe num ERP e não no outro.

Click to enlarge

Um cliente, dois ERPs: três jeitos de representá-lo no Salesforce.

Pergunte como eles mantêm os ERPs sincronizados

Então, qual deles? Primeiro: quanto da estrutura dos ERPs os vendedores devem ver? Se eles sempre souberam que a América do Norte e a Europa são negócios separados, porque entram num ERP ou no outro, não esconda isso deles. Leve essa estrutura para o Salesforce como contas pares. Se o negócio quer uma única Steve’s Plumbing na frente de vendas, você está olhando para uma conta com um filho por ERP.

Depois vem a pergunta que realmente decide, e ela não é decidida no Salesforce. Pergunto ao cliente: como vocês mantêm esses dois registros sincronizados entre os seus ERPs? Não as coisas que são locais de cada ERP, como o saldo; isso é transacional. Estou falando dos dados mestres: a razão social, os endereços. Se eles têm uma equipe que mantém os dois ERPs sincronizados, podemos juntá-los numa única conta. Se eles não conseguem mantê-los sincronizados nos próprios ERPs, como vão esperar que a gente os mantenha sincronizados no Salesforce? Aí são contas pares, ou uma hierarquia.

Lembre-se do que é um ERP. São sistemas enormes que levam anos para serem implantados, e vêm com o próprio jeito de gerenciar dados mestres. Não é o Salesforce que vai comandá-los. Nós não controlamos os ERPs. Controlamos como os representamos no Salesforce.

MDM no meio

Alguns clientes já resolveram isso antes de chegarmos. Uma empresa grande, muitos anos de mercado, vários ERPs: eles bateram nesse problema muito antes do Salesforce e colocaram um produto de MDM dedicado no meio para intermediar entre os ERPs. É o MDM de coexistência ou centralizado do módulo 2. Agora o Salesforce não se conecta a cada ERP. Ele aponta para um só lugar, o hub de MDM, e recebe uma representação única do cliente. Mas não espere encontrar um com frequência. São implementações grandes por si sós; em todos os meus anos, trabalhei com um só duas ou três vezes. E, mesmo com o hub, você ainda pode precisar daquele objeto filho, para que cada pedido saiba para qual ERP está indo.

Click to enlarge

MDM no meio: o Salesforce aponta para um só lugar.

Steve Trucking: a hierarquia de quem?

Um Parceiro varejista tem sua própria estrutura: controladora corporativa, divisões regionais, centros de distribuição, lojas. A Steve Trucking é dona dessa hierarquia? Não; o parceiro é a autoridade sobre a própria organização. Mas a Steve Trucking pode precisar da sua própria visão comercial desses mesmos locais, para contratos, gestão de contas, atendimento e relatórios, talvez uma conta filha para cada CD sob o parceiro. Duas hierarquias legítimas, duas autoridades. Dê nome a elas, e não finja que uma árvore representa todos os relacionamentos.

Torne as fronteiras visíveis

Sempre que a autoridade é dividida, quero a fronteira visível: nomes de campos, metadados do registro, identificadores do sistema de origem, permissões, comportamento da integração, documentação. O que não quero é um desenvolvedor lendo cinco integrações para descobrir que “estes valores de Conta pai vêm do SAP, exceto os prospects, exceto a Europa”. Isso não é um modelo de autoridade sustentável. Se a hierarquia tem autoridade dividida, documente a divisão. Se a autoridade muda na conversão, documente a mudança. Se o Salesforce pode solicitar mas não fazer uma mudança, deixe isso óbvio na experiência.

No Salesforce, isso começa com um campo. É preciso haver um campo que diga claramente que isto é dado mestre: a chave do ERP, ou um indicador “é dado mestre”. Defina a editabilidade dos campos a partir desse campo, não de um tipo de registro; com o Dynamic Forms, você não precisa mais de um tipo de registro para mostrar os campos do ERP como somente leitura (capítulo 5, Um tipo de registro para cada fluxo). Você pode permitir que registros sejam criados fora do mestre, mas fique de olho nas edições.

Além do exame: o que a IA muda. Um cliente diz a um agente: “mude nosso endereço de cobrança para Rua Principal, 125”. O campo está ali no Salesforce. O agente deve atualizá-lo? Não, se o ERP é dono dele. Um agente precisa de autoridade de gravação, não só de acesso ao campo: a ação dele deve codificar o caminho aprovado, enviando uma solicitação de mudança e dizendo “enviei a alteração para processamento”, e não relatando falsamente “atualizei seu endereço de cobrança”.

O que um arquiteto decide aqui

• Se uma edição no Salesforce altera dados com autoridade ou solicita uma mudança ao sistema que é dono deles.
• Como os fluxos de mão dupla distinguem mudanças originais de ecos, e tratam rejeição, colisões, latência e falha.
• Quem é dono de cada hierarquia, ramo por ramo se for preciso.
• Para um cliente mantido em vários ERPs: uma hierarquia, contas pares, ou uma conta com um filho por ERP, conforme o quanto o cliente mantém os ERPs dele sincronizados.
• Se hierarquias concorrentes são, na verdade, relacionamentos legítimos diferentes: legal, de faturamento, de vendas, de atendimento.
• Como as fronteiras de autoridade e os caminhos de gravação aprovados ficam visíveis para usuários, integrações, desenvolvedores e agentes.

A autoridade compartilhada não é o problema. A autoridade ambígua é. Vários ERPs podem ser mestres de ramos diferentes, o Salesforce pode ser mestre de alguns atributos e solicitar mudanças em outros, e várias hierarquias podem descrever uma empresa. Tudo isso funciona, desde que, para cada atributo e relacionamento importante, você consiga dizer quem é o dono, quem pode alterá-lo, onde a mudança com autoridade é feita, e o que acontece quando os sistemas discordam. Se não consegue, mais uma seta de mão dupla no diagrama não vai resolver.

Para saber mais

• Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab) (em inglês), consultado em 2026-10-14.