Correspondência, mesclagem e sobrevivência (survivorship)

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

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

O Salesforce tem dois contatos: Daniel Reyes, Dallas, d.reyes@example.com, e Dan Reyes, Dallas, d.reyes@example.com. A mesma pessoa? Provavelmente. Devemos mesclá-los? Essa é outra pergunta. E, se mesclarmos, qual telefone, endereço e cargo sobrevivem? Outra ainda. Os arquitetos precisam manter três decisões separadas:

• Correspondência: estes registros representam a mesma coisa?
• Mesclagem: eles devem virar um registro só?
• Sobrevivência (survivorship): se combinarmos os dados, quais valores vencem?

A correspondência vem primeiro

O capítulo 3 cobriu as regras de duplicidade e de correspondência do Salesforce, então não vou ensinar a mecânica de novo. A pergunta de arquitetura é que evidência é forte o bastante para dizer que estes podem ser o mesmo? Para uma pessoa: e-mail, telefone, nome mais endereço, um número de cliente, alguma combinação. Para uma empresa: razão social, identificador fiscal, ID de cliente do ERP, endereço, 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 compartilham endereços, empresas usam compras@empresa.com, números de telefone pertencem a lares, nomes e endereços não são únicos, e até identificadores fortes são reutilizados, digitados errado ou reciclados. Correspondência não é comparação de strings. É uma afirmação sobre identidade.

O custo de errar

Quando ensino isto, mudo o domínio. Em dados de marketing automotivo, decidimos erroneamente 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 médicos de duas pessoas diferentes combinados. Mesmo erro de correspondência, consequência completamente diferente. É por isso que não existe um limiar de correspondência “bom” universal. Às vezes o risco maior é perder uma correspondência; às vezes é combinar duas pessoas que não são a mesma. Onde as correspondências falsas custam caro, eu correspondo de 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, abreviações normalizadas, códigos mapeados. Depois você faz a correspondência. Só depois que se sabe que os registros pertencem juntos é que você consolida as informações deles numa representação. Harmonizar não é corresponder, corresponder não é mesclar, e consolidar não é necessariamente gerenciar dados mestres.

Click to enlarge

As decisões de identidade acontecem em etapas.

Uma correspondência não exige uma mesclagem

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

Minha regra de mesclagem: um vencedor claro

Minha posição: mescle só quando houver um vencedor claro e a duplicata não acrescentar nada que você precise guardar. Um vendedor criou ontem uma conta duplicada; a original é claramente o registro estabelecido. Boa candidata à mesclagem. Agora mude o cenário: importamos clientes de um sistema legado, com seus próprios IDs, valores mais antigos, talvez transações ou requisitos de auditoria ligados a eles. Sou muito mais cauteloso. Mantenha as duplicatas de cargas externas quando você puder precisar rastrear valores mais antigos, porque a mesclagem destrói esse histórico.

O que uma mesclagem no Salesforce realmente faz

Um vínculo diz “estes pertencem juntos”. Uma mesclagem diz “estes agora são um”, e no Salesforce é uma mudança real. Para contas, você seleciona até três registros e escolhe um como principal; você escolhe quais valores de campo dos outros manter, enquanto os campos ocultos e somente leitura vêm do principal. O registro mesclado mantém o Criado por e a Data de criação do registro mais antigo, seja qual for o principal. Os registros não principais vão para a Lixeira. Registros relacionados, como atividades, passam para o registro mesclado, com exceções. No Lightning, a mesclagem funciona sobre as duplicatas que suas regras de duplicidade detectam. E, para contas pessoais, os objetos de ponto de contato não suportam mesclagem: os relacionamentos deles se perdem (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 uma mesclagem de contas no Salesforce faz: até três registros; um principal, cujos campos ocultos e somente leitura são mantidos; o Criado por e a Data de criação do registro mais antigo, seja qual for o principal; os outros registros vão para a Lixeira; e, para contas pessoais, os objetos de ponto de contato não são mesclados.

Você não precisa de cada caso extremo para tomar a decisão. Precisa da consequência: depois de uma mesclagem, os registros independentes com que você começou não existem mais. O Teste de Reversibilidade do capítulo 1 vale aqui: vincular é fácil de desfazer; mesclar não é. E um cliente raramente está sozinho: contatos, casos, oportunidades, arquivos, registros de consentimento, filhos personalizados, IDs externos, referências de integração. Antes de mesclar o pai, entenda o que acontece com tudo o que está ligado a ele. Quando duplicatas chegam numa carga, dou às equipes três opções para os filhos: movê-los para o registro sobrevivente; não carregá-los de jeito nenhum, se ninguém precisa deles; ou mantê-los no outro registro, marcado como inativo, para que ainda apareçam na busca. A primeira é o que uma mesclagem faz por você. As outras duas preservam o rastro, e muitas vezes é exatamente isso que importa.

Sobrevivência: qual valor vence?

Os registros pertencem juntos, mas discordam: o Salesforce e o faturamento 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 chance de estar certo. Razoável para um celular. Terrível para uma razão social: se o ERP é dono dela, não me importa que alguém tenha alterado a cópia no Salesforce cinco minutos atrás. “O mais frequente” presume que concordância é evidência, mas três cópias desatualizadas mais adiante não vencem no voto a fonte de registro. “Prioridade da fonte” diz com todas as letras: confiamos mais nesta fonte. Então a sobrevivência pertence à arquitetura e à governança, e cada regra precisa de um dono. Quem decidiu que o endereço mais novo vence, 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 vence, sem precisar de pontuação engenhosa. Os casos difíceis são os atributos em que a autoridade é compartilhada, pouco clara ou baseada em evidências em vez de um único mestre. É aí que as regras de sobrevivência mostram 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, um endereço parecido de apoio. Acima de uma pontuação, é correspondência; abaixo de outra, é diferente; no meio, uma pessoa revisa. O algoritmo não é a lição. O limiar é a sua tolerância ao erro, e ele deve seguir o risco de negócio. E, quando as evidências levantam a dúvida sem resolvê-la, não finja que o sistema sabe. Encaminhe para revisão. Mais lento, e tudo bem: a automação não tem valor quando mescla com toda a confiança dois clientes diferentes.

O enriquecimento acrescenta mais uma pergunta de procedê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 confiável e atual ele é, podemos usá-lo para esta finalidade, ele contém dados pessoais? “Setor = Transporte” vindo de um provedor de dados não é o mesmo que o cliente lhe dizer. Mantenha essa distinção.

Steve Trucking: parecido não é igual

Dois Parceiros varejistas mandam 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 eles são: esses 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 enquanto: não deixe a conveniência da correspondência tomar a decisão de negócio.

Às vezes manter a bagunça lhe diz algo. Este registro veio do sistema antigo, aquele do Salesforce, este da empresa adquirida; os IDs deles, o histórico deles e o fato 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 correspondência ruim costumava significar dois e-mails ou um histórico de atendimento dividido. Agora um agente encontra o que acha ser o cliente e puxa os pedidos, casos, endereços e observações dele. Se duas pessoas foram correspondidas por engano, ele pode agir com as informações 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 sinalizar uma possível duplicata em cada domínio de dados.
• Se uma correspondência confirmada vira uma mesclagem, um vínculo ou uma revisão humana.
• Quais 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 perdida.
• Quais identidades de origem, histórico e registros relacionados precisam ser preservados antes de qualquer mesclagem.

Corresponda com cuidado, mescle de forma deliberada, escolha as regras de sobrevivência com intenção. Um registro de cliente limpo não vale muito se você chegou lá 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.