Emparejar, fusionar y la supervivencia

🌐 También en 28 idiomas

English · 日本語 · Português (Brasil) · 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)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 3 de 6 del capítulo Datos maestros e identidad, capítulo 6 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Las cuatro formas de gestionar datos maestros · Siguiente: Un mapa no es una decisión

La pregunta que responde este módulo: ¿Cómo encuentras duplicados, y cómo decides qué valores sobreviven?

Salesforce tiene dos contactos: Daniel Reyes, Dallas, d.reyes@example.com, y Dan Reyes, Dallas, d.reyes@example.com. ¿La misma persona? Probablemente. ¿Deberíamos fusionarlos? Esa es otra pregunta. Y si lo hacemos, ¿qué teléfono, qué dirección y qué cargo sobreviven? Otra distinta. Los arquitectos necesitan mantener separadas tres decisiones:

• Emparejar: ¿estos registros representan lo mismo?
• Fusionar: ¿deberían convertirse en un solo registro?
• Supervivencia: si combinamos los datos, ¿qué valores ganan?

Primero se empareja

El capítulo 3 cubrió las reglas de duplicados y de coincidencia de Salesforce, así que no volveré a enseñar la mecánica. La pregunta de arquitectura es ¿qué evidencia es lo bastante fuerte para decir que estos podrían ser lo mismo? Para una persona: correo electrónico, teléfono, nombre más dirección, un número de cliente, alguna combinación. Para una empresa: nombre legal, identificación fiscal, ID de cliente del ERP, dirección, dominio web. No “¿puede Salesforce comparar estos campos?”, sino “¿qué combinación nos da suficiente confianza para actuar?”

Y exacto no es seguro. Un correo compartido es una señal fuerte, no una prueba: las familias comparten direcciones, las empresas usan purchasing@company.com, los números de teléfono pertenecen a hogares, los nombres y las direcciones no son únicos, e incluso los identificadores fuertes se reutilizan, se escriben mal o se reciclan. Emparejar no es comparar cadenas de texto. Es una declaración sobre la identidad.

El costo de equivocarse

Cuando enseño esto, cambio de dominio. En datos de marketing automotriz, decidimos por error que dos Daniel Reyes son la misma persona, y al equivocado le llega una oferta de un SUV. No es bueno, pero el riesgo es bajo. Ahora comete el mismo falso emparejamiento en datos médicos: los historiales médicos de dos personas distintas, combinados. El mismo error de emparejamiento, una consecuencia completamente distinta. Por eso no existe un umbral de emparejamiento “bueno” universal. A veces el riesgo mayor es no detectar una coincidencia; a veces es combinar a dos personas que no son la misma. Donde los falsos emparejamientos salen caros, emparejo de menos a propósito.

Armoniza, luego empareja, luego consolida

Emparejar también depende de la forma de los datos. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. La armonización hace que los valores sean comparables: formatos estándar, abreviaturas normalizadas, códigos mapeados. Después emparejas. Solo cuando se sabe que los registros van juntos consolidas su información en una sola representación. Armonizar no es emparejar, emparejar no es fusionar, y consolidar no es necesariamente gestionar como maestro.

Click to enlarge

Las decisiones de identidad se toman por etapas.

Una coincidencia no exige una fusión

Esta es una de las distinciones más importantes del capítulo. Estamos seguros de que dos registros de cliente de dos sistemas antiguos son la misma empresa. ¿Tenemos que fusionarlos? No. Cada uno puede llevar una identidad del sistema de origen; las transacciones históricas pueden apuntar a cada uno; los auditores pueden necesitar el rastro; puede que sigamos migrando; puede que necesitemos saber exactamente qué decía el sistema antiguo. Saber que dos registros son lo mismo no nos obliga a colapsarlos. Podemos vincularlos, y a menudo esa es la arquitectura más segura.

Mi regla para fusionar: un ganador claro

Mi postura: fusiona solo cuando hay un ganador claro y el duplicado no aporta nada que necesites conservar. Un representante creó ayer una cuenta duplicada; el original es claramente el registro establecido. Buen candidato para fusionar. Ahora cámbialo: importamos clientes de un sistema heredado, con sus propios ID, valores más antiguos, quizá transacciones o requisitos de auditoría ligados a ellos. Soy mucho más prudente. Conserva los duplicados de las cargas externas cuando puedas necesitar rastrear valores anteriores, porque la fusión destruye ese historial.

Lo que hace de verdad una fusión en Salesforce

Un vínculo dice “estos van juntos”. Una fusión dice “ahora son uno”, y en Salesforce es un cambio real. Para las cuentas, seleccionas hasta tres registros y eliges uno como el principal; eliges qué valores de campo de los demás conservar, mientras que los campos ocultos y de solo lectura vienen del principal. El registro fusionado conserva el Created By y el Created Date del registro más antiguo, sea cual sea el principal. Los registros que no son el principal van a la Papelera de reciclaje. Los registros relacionados, como las actividades, pasan al registro fusionado, con excepciones. En Lightning, la fusión funciona sobre los duplicados que detectan tus reglas de duplicados. Y para las cuentas personales, los objetos de punto de contacto no admiten la fusión: sus relaciones se pierden (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab), en inglés).

Conocimiento para el examen. Conoce lo que hace una fusión de cuentas en Salesforce: hasta tres registros; un principal, del que se conservan los campos ocultos y de solo lectura; el Created By y el Created Date del registro más antiguo, sea cual sea el principal; los demás registros van a la Papelera de reciclaje; y en las cuentas personales, los objetos de punto de contacto no se fusionan.

No necesitas conocer cada caso límite para tomar la decisión. Necesitas la consecuencia: después de una fusión, los registros independientes con los que empezaste ya no existen. Se aplica la Prueba de Reversibilidad del capítulo 1: vincular es fácil de deshacer; fusionar no. Y un cliente rara vez está solo: contactos, casos, oportunidades, archivos, registros de consentimiento, hijos personalizados, ID externos, referencias de integración. Antes de fusionar el padre, entiende qué les pasa a todos los registros que dependen de él. Cuando llegan duplicados con una carga, les doy a los equipos tres opciones para los hijos: moverlos al registro que sobrevive; no cargarlos en absoluto, si nadie los necesita; o dejarlos en el otro registro, marcado como inactivo, para que sigan apareciendo en las búsquedas. La primera es lo que hace una fusión por ti. Las otras dos conservan el rastro, y a menudo de eso se trata.

Supervivencia: ¿qué valor gana?

Los registros van juntos, pero no coinciden: Salesforce y facturación dicen 602-555-0100, el ERP dice 602-555-0188. Las reglas de supervivencia (survivorship) eligen al ganador. Las habituales: el más reciente (la última actualización), el más frecuente (el valor en el que coinciden más fuentes) y la prioridad de la fuente (confía en esta fuente antes que en aquella), además de combinaciones, umbrales, pesos y reglas propias del negocio. Ninguna es correcta por naturaleza.

“El más reciente” no es un ajuste técnico. Es una declaración sobre la confianza: cuando los sistemas no coinciden, el valor más nuevo tiene más probabilidades de ser el correcto. Razonable para un número de móvil. Terrible para un nombre legal: si el ERP es su dueño, me da igual que alguien haya cambiado la copia de Salesforce hace cinco minutos. “El más frecuente” supone que el acuerdo es evidencia, pero tres copias desactualizadas aguas abajo no le ganan la votación a la fuente de referencia. “La prioridad de la fuente” lo dice sin rodeos: confiamos más en esta fuente. Así que la supervivencia pertenece a la arquitectura y al gobierno de datos, y cada regla necesita un dueño. ¿Quién decidió que gana la dirección más nueva, o que el ERP está por encima de Salesforce?

Si el mapa de autoridad del módulo 1 ya dice que el ERP es dueño del límite de crédito, la supervivencia es fácil: gana el ERP, sin necesidad de puntuaciones ingeniosas. Los casos difíciles son los atributos cuya autoridad es compartida, poco clara o basada en la evidencia en lugar de en un solo maestro. Ahí es donde las reglas de supervivencia se ganan su lugar.

Click to enlarge

Las reglas de supervivencia son declaraciones sobre la confianza.

Umbrales, revisión y enriquecimiento

Algunos emparejamientos ponderan la evidencia: coincidir en el ID de cliente es muy fuerte, el correo electrónico fuerte, el teléfono moderado, un nombre parecido débil, una dirección parecida un apoyo. Por encima de una puntuación, coinciden; por debajo de otra, son distintos; entre ambas, una persona lo revisa. La lección no es el algoritmo. El umbral es tu tolerancia al error, y debería seguir el riesgo del negocio. Y cuando la evidencia plantea la pregunta sin resolverla, no finjas que el sistema lo sabe. Envíalo a revisión. Es más lento, y está bien: la automatización no aporta valor cuando fusiona con toda seguridad a dos clientes distintos.

El enriquecimiento añade otra pregunta de procedencia. Los datos de referencia postales, los códigos de industria, los datos de empresa y las puntuaciones de riesgo externas mejoran los datos maestros, pero ¿de dónde vino cada valor, qué tan fiable y actual es, podemos usarlo para este propósito, contiene datos personales? “Industria = Transporte” según un proveedor de datos no es lo mismo que si te lo dice el cliente. Mantén esa distinción.

Steve Trucking: parecido no es lo mismo

Dos socios minoristas (Retail Partners) envían entregas a John Smith, 123 Main Street, Columbus, con el mismo número de teléfono. ¿La misma persona? Probablemente. ¿Debería Steve Trucking unificarlos? Recuerda de quién son: esos destinatarios (Recipients) son clientes de los socios, y un socio nunca debe ver los de otro. Un falso emparejamiento mezclaría datos a través de esa frontera. De pronto ya no es una pregunta de calidad de datos, sino de privacidad y aislamiento, y por eso mismo los umbrales dependen de las consecuencias. El checkpoint toma la decisión. Por ahora: no dejes que la comodidad del emparejamiento tome la decisión de negocio.

A veces conservar el desorden te dice algo. Este registro vino del sistema antiguo, aquel de Salesforce, este otro de la empresa adquirida; sus ID, su historial y el hecho de que no coincidieran pueden importar. Los datos limpios son valiosos. La trazabilidad también. El arquitecto decide qué importa más para cada uso.

Más allá del examen: lo que cambia la IA. Antes, un mal emparejamiento significaba dos correos o un historial de servicio partido. Ahora un agente encuentra lo que cree que es el cliente y trae sus pedidos, casos, direcciones y notas. Si dos personas se emparejaron por error, puede actuar sobre la información de una persona en nombre de otra. La decisión de emparejamiento se ha convertido en parte de la frontera de seguridad, y donde mezclar sale caro, un emparejamiento más estricto es el diseño más seguro.

Lo que decide aquí un arquitecto

• Qué evidencia basta para marcar un posible duplicado en cada dominio de datos.
• Si una coincidencia confirmada se convierte en una fusión, un vínculo o una revisión humana.
• Qué valores sobreviven a un desacuerdo, y quién es dueño de cada regla de supervivencia.
• Cuánto riesgo de falso emparejamiento puede tolerar el negocio frente al riesgo de no detectar una coincidencia.
• Qué identidades de origen, historial y registros relacionados deben conservarse antes de cualquier fusión.

Empareja con cuidado, fusiona de forma deliberada, elige las reglas de supervivencia con intención. Un registro de cliente limpio no vale mucho si llegaste a él combinando a los clientes equivocados.

Explora

• Ayuda de Salesforce, Considerations for Merging Duplicate Accounts (opens in a new tab) y Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Ayuda de Salesforce, Things to Know About Duplicate Rules (opens in a new tab) (en inglés), consultado el 2026-10-14.