Hierarquias e dados nos dois sentidos

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

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

A arquitetura fácil: o ERP é dono do cliente, o Salesforce recebe uma cópia, e pronto. As empresas reais não são tão limpas. O ERP é dono do cliente legal e o Salesforce da relação de vendas; uma divisão vive no SAP, uma empresa adquirida noutro ERP; os prospects existem só no Salesforce. Depois alguém quer que os utilizadores 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 enviar dados nos dois sentidos seja tecnicamente difícil, mas porque, quando os dois sistemas participam na mudança, tem de ser extremamente preciso sobre a autoridade.

Dados nos dois sentidos não significam dois mestres

O ERP é dono da morada de faturação, copiada para o Salesforce. Um comercial fica a saber pelo cliente que ela mudou, e o negócio quer que o comercial a atualize sem sair do Salesforce. Razoável. Agora os dados fluem ERP → Salesforce e Salesforce → ERP. O Salesforce passou a ser coproprietário da morada de faturação? Não. A direção de uma integração não decide a autoridade. O comercial não está a alterar a cópia do Salesforce. Em termos de arquitetura, está a pedir para alterar o valor com autoridade. Não está a alterar o campo do ERP; está a pedir para o alterar. O Salesforce é a interface; o ERP continua a ser o mestre.

Isso muda o design. Se o Salesforce fosse dono do campo, gravar e pronto. Se o ERP é o dono, «gravar» significa que o Salesforce envia a morada proposta, o ERP valida-a e aceita-a, atualiza o seu mestre, e devolve o valor com autoridade. Só então o valor governado mudou: pedir → validar → aceitar → publicar, e não «atualizar os dois sistemas e esperar que se mantenham 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, a morada viola uma regra do ERP, o utilizador não pode alterar moradas legais, o ERP está em baixo, ou outra pessoa alterou o cliente entretanto. Se o Salesforce já mostrava a morada nova, agora temos duas verdades, e o módulo 1 já nos disse qual ganha: a do ERP. Por isso a arquitetura precisa de um estado de pedido, ainda não aceite: um valor proposto separado, um indicador de «mudança pendente», ou esperar pela confirmação antes de o mostrar. O mecanismo depende do caso de uso. A regra não: nunca deixe um pedido rejeitado tornar-se uma verdade concorrente.

Ciclos e colisões

Eis um clássico. O ERP atualiza o Salesforce; a integração do Salesforce vê uma mudança e envia-a ao ERP; o ERP vê uma atualização e devolve-a. Construiu um ciclo muito caro. Um bom design nos dois sentidos sabe onde começou uma mudança, 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 a fundo. O princípio de dados mestres é simples: saiba se está a originar uma mudança ou a refletir uma.

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

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

Sempre que vejo uma integração nos dois sentidos, pergunto o que acontece quando os dois lados alteram os mesmos dados? Se a resposta é «isso provavelmente não vai acontecer», ainda não terminámos. Qual ganha, rejeitamos, pomos em fila, comparamos versões, revemos? O campo devia sequer ser editável nos dois lugares? Às vezes o melhor design nos dois sentidos remove uma direção para um dado atributo: o Salesforce pode pedir; só o ERP publica o valor aceite. Os dados continuam a mover-se nos dois sentidos, mas só um sistema é mestre do campo. Essa diferença é tudo.

Hierarquias também são dados mestres

As relações também podem ser dados mestres. Uma empresa-mãe 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 empresa-mãe? Que subsidiária fica sob que entidade legal? Que contas se consolidam no cliente global? Isto orienta relatórios, territórios, preços, contratos, exposição de crédito, atendimento, acesso a dados e análise. Uma hierarquia pode importar tanto como os registos que contém, e precisa da mesma governação. (O exame refere a gestão de hierarquias; é fácil esquecer.)

No Salesforce, as hierarquias de contas são construídas com o campo Conta principal (Parent Account). A visualização de hierarquia do Lightning mostra até 2.000 contas, e só as que o utilizador pode ver; as 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 principal não responde à pergunta de arquitetura: quem é dono da hierarquia?

Conhecimento para o exame. Conheça o básico da hierarquia de contas: é construída com a Conta principal (Parent Account); a vista do Lightning mostra até 2.000 contas, só as que o utilizador pode ver; as contas pessoais não são suportadas; e o Local da conta (Account Site) distingue as localizações 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 as relações dos prospects até se converterem. É uma arquitetura legítima, desde que toda a gente saiba onde ficam as fronteiras. Decida ramo a ramo.

Click to enlarge

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

Por isso não deixe o campo Conta principal esconder a autoridade. Um utilizador muda a conta principal de uma subsidiária no Salesforce. Tecnicamente trivial. Em termos de arquitetura, acabou de mudar a estrutura legal da empresa? Se o ERP é mestre daquele ramo, provavelmente não, por isso o Salesforce deve bloquear isso, ou transformá-lo num pedido de mudança. Ou talvez o Salesforce mantenha legitimamente uma hierarquia comercial enquanto o ERP mantém a legal. Então talvez nem devessem ser a mesma relação.

Uma empresa pode ter várias hierarquias válidas: legal, de faturação, de vendas, de atendimento, geográfica. A empresa-mãe global assina o contrato, as regiões recebem atendimento por conta própria, a faturação passa por uma entidade financeira partilhada, as vendas gerem por região. Qual é a hierarquia verdadeira? Todas; respondem a perguntas diferentes. O erro é presumir que tem de haver uma só. Deve haver uma autoridade clara para cada tipo de relação: o princípio de atributo do módulo 1, aplicado às relações.

E nem toda a relação pai-filho é dado mestre. Agrupar as entregas de hoje numa rota é uma relação, mas transacional, um evento operacional. Uma hierarquia de clientes descreve uma relação de negócio duradoura. As duas parecem pai-filho num modelo; não partilham um ciclo de vida. Pergunte o que a relação significa e durante 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? Levantam-se mãos todas as vezes. Pergunte porquê, e os ERPs acabam por estar divididos por região (um para a América do Norte, um para a Europa), por função (uma empresa de canalização compra uma empresa de eletricidade, e cada uma mantém o seu próprio ERP) ou simplesmente por história: o negócio foi adquirido, e ainda ninguém o migrou.

Pense na Steve’s Plumbing como cliente. Faz negócio na América do Norte, por isso o ERP norte-americano tem um registo de cliente para ela. Depois abre um escritório em Munique, e o ERP europeu cria um registo de cliente próprio, com o seu próprio número de cliente. A mesma empresa, dois registos, dois IDs. Como represento isso numa única org do Salesforce? Já vi três formas.

Uma hierarquia de contas. A Steve’s Plumbing é a conta principal, com a Steve’s Plumbing North America e a Steve’s Plumbing Europe como contas filhas, cada filha a representar o registo de um ERP. O senão: as filhas já não são exatamente a Steve’s Plumbing. São a Steve’s Plumbing a fazer negócio numa região e, como acabámos de ver, uma hierarquia carrega significado.

Contas pares. Duas contas lado a lado, cada uma com um campo que diz a que ERP 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 inteiro, 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 registo para cada ERP que guarda o ID de cliente desse ERP. Dois ERPs ou dez. Os comerciais veem um cliente e fazem uma encomenda; nos bastidores, flows decidem para que ERP vai cada linha: o trabalho elétrico para o ERP de eletricidade, o de canalização para o ERP de canalização. Mas agora precisa de decidir que ERP é o principal para os valores partilhados, como o nome e a morada, e o que acontece quando o cliente existe num ERP e não no outro.

Click to enlarge

Um cliente, dois ERPs: três formas de o representar no Salesforce.

Pergunte como mantêm os ERPs sincronizados

Então, qual delas? Primeiro: quanto da estrutura dos ERPs devem os comerciais ver? Se 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 lhes esconda isso. Leve essa estrutura para o Salesforce como contas pares. Se o negócio quer uma única Steve’s Plumbing à frente das vendas, está a olhar para uma conta com um filho por ERP.

Depois vem a pergunta que realmente decide, e não é decidida no Salesforce. Pergunto ao cliente: como mantêm esses dois registos sincronizados entre os vossos ERPs? Não as coisas que são locais a cada ERP, como o saldo; isso é transacional. Refiro-me aos dados mestres: a denominação social, as moradas. Se têm uma equipa que mantém os dois ERPs sincronizados, podemos juntá-los numa única conta. Se não os conseguem manter sincronizados nos seus próprios ERPs, como vão esperar que nós os mantenhamos sincronizados no Salesforce? Aí são contas pares, ou uma hierarquia.

Lembre-se do que é um ERP. São sistemas enormes que levam anos a implementar, e vêm com a sua própria forma de gerir dados mestres. Não é o Salesforce que os vai comandar. Nós não controlamos os ERPs. Controlamos a forma como os representamos no Salesforce.

MDM no meio

Alguns clientes já resolveram isto antes de chegarmos. Uma empresa grande, muitos anos de mercado, vários ERPs: depararam-se com este problema muito antes do Salesforce e puseram um produto de MDM dedicado no meio para fazer a intermediação entre os ERPs. É o MDM de coexistência ou centralizado do módulo 2. Agora o Salesforce não se liga a cada ERP. 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ó; em todos os meus anos, trabalhei com um apenas duas ou três vezes. E, mesmo com o hub, pode continuar a precisar daquele objeto filho, para que cada encomenda saiba para que ERP vai.

Click to enlarge

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

Steve Trucking: a hierarquia de quem?

Um Parceiro retalhista tem a sua própria estrutura: empresa-mãe, divisões regionais, centros de distribuição, lojas. A Steve Trucking é dona dessa hierarquia? Não; o parceiro é a autoridade sobre a sua 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ê-lhes nome, e não finja que uma árvore representa todas as relações.

Torne as fronteiras visíveis

Sempre que a autoridade é dividida, quero a fronteira visível: nomes de campos, metadados do registo, identificadores do sistema de origem, permissões, comportamento da integração, documentação. O que não quero é um programador a ler cinco integrações para descobrir que «estes valores de Conta principal 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 pedir mas não fazer uma mudança, torne isso óbvio na experiência.

No Salesforce, isso começa com um campo. Tem de 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 registo; com o Dynamic Forms, já não precisa de um tipo de registo para mostrar os campos do ERP só de leitura (capítulo 5, Um tipo de registo para cada fluxo). Pode permitir que sejam criados registos fora do mestre, mas esteja atento às edições.

Além do exame: o que a IA muda. Um cliente diz a um agente: «mude a nossa morada de faturação 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 sua ação deve codificar o caminho aprovado, enviando um pedido de mudança e dizendo «enviei a alteração para processamento», e não relatando falsamente «atualizei a sua morada de faturação».

O que um arquiteto decide aqui

• Se uma edição no Salesforce altera dados com autoridade ou pede uma mudança ao sistema que é dono deles.
• Como os fluxos nos dois sentidos distinguem mudanças originais de ecos, e tratam rejeição, colisões, latência e falha.
• Quem é dono de cada hierarquia, ramo a 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 cliente mantenha os seus ERPs mais ou menos sincronizados.
• Se hierarquias concorrentes são, na verdade, relações legítimas diferentes: legal, de faturação, de vendas, de atendimento.
• Como as fronteiras de autoridade e os caminhos de gravação aprovados ficam visíveis para utilizadores, integrações, programadores e agentes.

A autoridade partilhada não é o problema. A autoridade ambígua é. Vários ERP podem ser mestres de ramos diferentes, o Salesforce pode ser mestre de alguns atributos e pedir mudanças noutros, e várias hierarquias podem descrever uma empresa. Tudo isso funciona, desde que, para cada atributo e relação importante, consiga dizer quem é o dono, quem o pode alterar, onde é feita a mudança com autoridade, e o que acontece quando os sistemas discordam. Se não consegue, mais uma seta nos dois sentidos 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.