Correspondência, fusão e sobrevivência (survivorship)

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

A pergunta que este módulo responde: Como encontrar duplicados, e decidir que valores sobrevivem?

O Salesforce tem dois contactos: Daniel Reyes, Dallas, d.reyes@example.com, e Dan Reyes, Dallas, d.reyes@example.com. A mesma pessoa? Provavelmente. Devemos fundi-los? Essa é outra pergunta. E, se os fundirmos, que telefone, morada e cargo sobrevivem? Outra ainda. Os arquitetos precisam de manter três decisões separadas:

• Correspondência: estes registos representam a mesma coisa?
• Fusão: devem tornar-se um só registo?
• Sobrevivência (survivorship): se combinarmos os dados, que valores ganham?

A correspondência vem primeiro

O capítulo 3 tratou das regras de duplicados e de correspondência do Salesforce, por isso não vou voltar a ensinar a mecânica. A pergunta de arquitetura é que evidência é suficientemente forte para dizer que estes podem ser o mesmo? Para uma pessoa: e-mail, telefone, nome mais morada, um número de cliente, alguma combinação. Para uma empresa: denominação social, número de identificação fiscal, ID de cliente do ERP, morada, domínio na web. Não «o Salesforce consegue comparar estes campos?», mas «que combinação nos dá confiança suficiente para agir?»

E exato não é certo. Um e-mail em comum é um sinal forte, não uma prova: famílias partilham endereços, empresas usam purchasing@company.com, números de telefone pertencem a lares, nomes e moradas não são únicos, e até identificadores fortes são reutilizados, mal escritos ou reciclados. Correspondência não é comparação de strings. É uma afirmação sobre identidade.

O custo de errar

Quando ensino isto, mudo de domínio. Em dados de marketing automóvel, decidimos por engano que dois Daniel Reyes são a mesma pessoa, e o errado recebe uma oferta de SUV. Não é bom, mas o risco é baixo. Agora faça a mesma correspondência falsa em dados médicos: os históricos clínicos de duas pessoas diferentes combinados. O mesmo erro de correspondência, uma consequência completamente diferente. É por isso que não existe um limiar de correspondência «bom» universal. Às vezes o risco maior é falhar uma correspondência; às vezes é combinar duas pessoas que não são a mesma. Onde as correspondências falsas custam caro, faço correspondências a menos de propósito.

Harmonize, depois corresponda, depois consolide

A correspondência também depende da forma dos dados. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. A harmonização torna os valores comparáveis: formatos padrão, abreviaturas normalizadas, códigos mapeados. Depois faz a correspondência. Só depois de se saber que os registos pertencem uns aos outros é que consolida a sua informação numa representação. Harmonizar não é fazer corresponder, fazer corresponder não é fundir, e consolidar não é necessariamente gerir dados mestres.

Click to enlarge

As decisões de identidade acontecem em etapas.

Uma correspondência não exige uma fusão

Esta é uma das distinções mais importantes do capítulo. Estamos confiantes de que dois registos de cliente de dois sistemas antigos são a mesma empresa. Precisamos de os fundir? Não. Cada um pode carregar uma identidade do sistema de origem; transações históricas podem apontar para cada um; os auditores podem precisar do rasto; podemos ainda estar a migrar; podemos precisar de saber exatamente o que dizia o sistema antigo. Saber que dois registos são a mesma coisa não nos obriga a fundi-los. Podemos associá-los, e muitas vezes essa é a arquitetura mais segura.

A minha regra de fusão: um vencedor claro

A minha posição: funda só quando houver um vencedor claro e o duplicado não acrescentar nada que precise de guardar. Um comercial criou ontem uma conta duplicada; a original é claramente o registo estabelecido. Boa candidata a fusão. Agora mude o cenário: importámos clientes de um sistema legado, com os seus próprios IDs, valores mais antigos, talvez transações ou requisitos de auditoria associados. Sou muito mais cauteloso. Mantenha os duplicados de cargas externas quando puder precisar de rastrear valores mais antigos, porque a fusão destrói esse histórico.

O que faz realmente uma fusão no Salesforce

Uma associação diz «estes pertencem uns aos outros». Uma fusão diz «estes são agora um», e no Salesforce é uma mudança real. Para contas, seleciona até três registos e escolhe um como principal; escolhe que valores de campo dos outros manter, enquanto os campos ocultos e só de leitura vêm do principal. O registo fundido mantém o Criado por e a Data de criação do registo mais antigo, seja qual for o principal. Os registos não principais vão para a Reciclagem. Os registos relacionados, como atividades, passam para o registo fundido, com exceções. No Lightning, a fusão funciona sobre os duplicados que as suas regras de duplicados detetam. E, para contas pessoais, os objetos de ponto de contacto não suportam fusão: as suas relações perdem-se (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab), em inglês).

Conhecimento para o exame. Saiba o que faz uma fusão de contas no Salesforce: até três registos; um principal, cujos campos ocultos e só de leitura são mantidos; o Criado por e a Data de criação do registo mais antigo, seja qual for o principal; os outros registos vão para a Reciclagem; e, para contas pessoais, os objetos de ponto de contacto não são fundidos.

Não precisa de cada caso extremo para tomar a decisão. Precisa da consequência: depois de uma fusão, os registos independentes com que começou já não existem. O Teste de Reversibilidade do capítulo 1 vale aqui: associar é fácil de desfazer; fundir não é. E um cliente raramente está sozinho: contactos, casos, oportunidades, ficheiros, registos de consentimento, filhos personalizados, IDs externos, referências de integração. Antes de fundir o pai, entenda o que acontece a tudo o que lhe está ligado. Quando chegam duplicados numa carga, dou às equipas três opções para os filhos: movê-los para o registo sobrevivente; não os carregar de todo, se ninguém precisa deles; ou mantê-los no outro registo, marcado como inativo, para que continuem a aparecer na pesquisa. A primeira é o que uma fusão faz por si. As outras duas preservam o rasto, e muitas vezes é exatamente isso que importa.

Sobrevivência: que valor ganha?

Os registos pertencem uns aos outros, mas discordam: o Salesforce e a faturação dizem 602-555-0100, o ERP diz 602-555-0188. As regras de sobrevivência (survivorship) escolhem o vencedor. As comuns: o mais recente (a última atualização), o mais frequente (o valor com que mais fontes concordam), e a prioridade da fonte (confiar nesta fonte mais do que naquela), além de combinações, limiares, pesos e regras específicas do negócio. Nenhuma delas é intrinsecamente certa.

«O mais recente» não é uma configuração técnica. É uma afirmação sobre confiança: quando os sistemas discordam, o valor mais novo tem mais probabilidade de estar certo. Razoável para um telemóvel. Terrível para uma denominação social: se o ERP é dono dela, não me importa que alguém tenha alterado a cópia no Salesforce há cinco minutos. «O mais frequente» presume que a concordância é evidência, mas três cópias desatualizadas a jusante não ganham por votos à fonte de registo. «Prioridade da fonte» di-lo com todas as letras: confiamos mais nesta fonte. Por isso a sobrevivência pertence à arquitetura e à governação, e cada regra precisa de um dono. Quem decidiu que a morada mais nova ganha, ou que o ERP tem prioridade sobre o Salesforce?

Se o mapa de autoridade do módulo 1 já diz que o ERP é dono do limite de crédito, a sobrevivência é fácil: o ERP ganha, sem precisar de pontuações engenhosas. Os casos difíceis são os atributos em que a autoridade é partilhada, pouco clara ou baseada em evidências em vez de um único mestre. É aí que as regras de sobrevivência mostram o seu valor.

Click to enlarge

As regras de sobrevivência são afirmações sobre confiança.

Limiares, revisão e enriquecimento

Alguns processos de correspondência pesam as evidências: uma correspondência de ID de cliente é muito forte, um e-mail forte, um telefone moderado, um nome parecido fraco, uma morada parecida de apoio. Acima de uma pontuação, é correspondência; abaixo de outra, é diferente; no meio, uma pessoa revê. O algoritmo não é a lição. O limiar é a sua tolerância ao erro, e deve seguir o risco de negócio. E, quando as evidências levantam a dúvida sem a resolver, não finja que o sistema sabe. Encaminhe para revisão. Mais lento, e não faz mal: a automação não tem valor quando funde com toda a confiança dois clientes diferentes.

O enriquecimento acrescenta mais uma pergunta de proveniência. Dados de referência postal, códigos de setor, dados firmográficos, pontuações de risco externas melhoram os dados mestres, mas de onde veio cada valor, quão fiável e atual é, podemos usá-lo para esta finalidade, contém dados pessoais? «Setor = Transportes» vindo de um fornecedor de dados não é o mesmo que o cliente dizer-lho. Mantenha essa distinção.

Steve Trucking: parecido não é o mesmo

Dois Parceiros retalhistas enviam entregas para João Silva, Rua Principal, 123, Columbus, com o mesmo telefone. A mesma pessoa? Provavelmente. A Steve Trucking deve unificá-los? Lembre-se de quem são: estes Destinatários são clientes dos parceiros, e um parceiro nunca pode ver os de outro. Uma correspondência falsa misturaria dados através dessa fronteira. De repente não é uma questão de qualidade de dados, mas de privacidade e isolamento, e é exatamente por isso que os limiares dependem das consequências. O checkpoint toma a decisão. Por agora: não deixe a conveniência da correspondência tomar a decisão de negócio.

Às vezes manter a confusão diz-lhe algo. Este registo veio do sistema antigo, aquele do Salesforce, este da empresa adquirida; os seus IDs, o seu histórico e o facto de discordarem podem todos importar. Dados limpos têm valor. A rastreabilidade também. O arquiteto decide o que importa mais para o uso.

Além do exame: o que a IA muda. Uma má correspondência costumava significar dois e-mails ou um histórico de atendimento dividido. Agora um agente encontra o que acha ser o cliente e vai buscar as suas encomendas, casos, moradas e notas. Se duas pessoas foram correspondidas por engano, pode agir com a informação de uma pessoa para outra. A decisão de correspondência passou a fazer parte da fronteira de segurança e, onde misturar custa caro, uma correspondência mais rigorosa é o design mais seguro.

O que um arquiteto decide aqui

• Que evidência basta para assinalar um possível duplicado em cada domínio de dados.
• Se uma correspondência confirmada se torna uma fusão, uma associação ou uma revisão humana.
• Que valores sobrevivem a uma discordância, e quem é dono de cada regra de sobrevivência.
• Quanto risco de correspondência falsa o negócio tolera versus o risco de correspondência falhada.
• Que identidades de origem, histórico e registos relacionados têm de ser preservados antes de qualquer fusão.

Faça correspondências com cuidado, funda de forma deliberada, escolha as regras de sobrevivência com intenção. Um registo de cliente limpo não vale muito se lá chegou combinando os clientes errados.

Para saber mais

• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab) e Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (em inglês), consultados em 2026-10-14.
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (em inglês), consultado em 2026-10-14.