Vincular no es gestionar como maestro
También en 28 idiomas
English · Español · 日本語 · 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 · Français (Canada) · Deutsch (Schweiz)
Capítulo 6 de Data Architect, Parte 1: Convertirse en Data Architect. Anterior: Calidad y gobierno de datos.
“Necesitamos una única fuente de verdad.” Es una de las frases más repetidas en arquitectura, y una de las menos examinadas. ¿Para qué? Toma una cuenta. El ERP puede ser dueño de su nombre legal, su dirección de facturación y su límite de crédito; Salesforce, de su ejecutivo de cuenta y su nivel de soporte; una plataforma de consentimiento, de sus preferencias de marketing. Tres autoridades sobre un mismo registro, y eso es normal. Así que cuando alguien dice “Salesforce es nuestra única fuente de verdad para el cliente”, mi siguiente pregunta es siempre: ¿qué verdad?
Este capítulo trata de responder esa pregunta a propósito. La autoridad se asigna atributo por atributo. Vincular registros no es gestionarlos como maestros. Y Salesforce te da herramientas distintas para trabajos distintos: la gestión de duplicados y la fusión dentro de una org; la resolución de identidades de Data 360 para tener una sola vista entre varias fuentes; una plataforma de MDM dedicada cuando los valores deben decidirse una vez y devolverse a todas partes. Termina con el Checkpoint 1, donde la Parte 1 se une en Steve Trucking.
Imagen generada con IA.
Las posturas de este capítulo
Sección titulada «Las posturas de este capítulo »- Una verdad por atributo. Pregunta dónde se crea, se edita y se referencia cada dato, y con qué rapidez cambia. Muestra la autoridad externa en el esquema con un prefijo de sistema, como
sap_oerp_. - Los prospectos son distintos. Viven en Salesforce antes de que el ERP los conozca; la autoridad del ERP se aplica después de la conversión.
- El registro (registry) es lo habitual en los proyectos de Salesforce, seguido de la consolidación y la coexistencia; el MDM centralizado puro es raro.
- Fusiona solo cuando hay un ganador claro. Conserva los duplicados de las cargas externas cuando puedas necesitar rastrear su origen; la fusión destruye ese historial. Y decide qué pasa con los hijos: muévelos, no los cargues o déjalos en un registro inactivo.
- Un perfil unificado es un mapa; un golden record es una decisión. Esto puede confundir a la gente: la resolución de identidades crea un individuo unificado, pero no un golden record.
- Lo estricto que es el emparejamiento es una decisión de riesgo. Donde mezclar personas sale caro, empareja de menos a propósito.
- Tres herramientas para tres trabajos: fusión, resolución de identidades, MDM.
- Las jerarquías tienen varios maestros. Decide la autoridad rama por rama.
- “Lo más difícil son las bidireccionales.” Una integración en dos sentidos no crea dos maestros. Decide qué campos viajan juntos como una sola transacción antes de la primera colisión.
- Haz visibles los datos maestros. Un campo que diga que esto son datos maestros (la clave del ERP o un indicador) es lo que determina si se puede editar, no un tipo de registro.
- No controlamos los ERP. Controlamos cómo los representamos en Salesforce: un cliente en dos ERP es una jerarquía, cuentas pares o una cuenta con un hijo por ERP, según lo bien que el cliente mantenga sincronizados sus ERP.
Tres herramientas para tres trabajos
Sección titulada «Tres herramientas para tres trabajos »| El trabajo | La herramienta | Qué les hace a las fuentes |
|---|---|---|
| Duplicados dentro de una org, con un ganador claro | Gestión de duplicados y fusión | Fusiona hasta tres registros; los demás van a la Papelera de reciclaje |
| Una identidad y una sola vista entre varias fuentes | Resolución de identidades de Data 360 | Las vincula; no cambia ninguna (un registro) |
| Un valor gobernado, devuelto a cada sistema | Una plataforma de MDM dedicada | Decide el valor y lo distribuye (coexistencia o centralizado) |
El recorrido por este capítulo
Sección titulada «El recorrido por este capítulo »Seis módulos y un desafío, cada uno independiente.
- Una fuente de verdad por atributo. El mapa de autoridad, el golden record híbrido y las señales de confianza.
- Las cuatro formas de gestionar datos maestros. Registro, consolidación, coexistencia y centralizado, y por qué un modelo común no es una verdad común.
- Emparejar, fusionar y la supervivencia. El costo de un falso emparejamiento, lo que hace de verdad una fusión en Salesforce (y qué pasa con los hijos), y la supervivencia como una declaración sobre la confianza.
- Un mapa no es una decisión. Reglas y métodos de emparejamiento, reglas de reconciliación, y por qué un perfil unificado no es un golden record.
- Cuando la autoridad es compartida. Solicitudes frente a actualizaciones, bucles y colisiones, jerarquías con varios maestros, y un cliente en dos ERP.
- El desafío del Checkpoint 1, y después Checkpoint 1: Steve Trucking, lo que yo diseñaría. Haz primero el desafío: dibuja y defiende el diseño de la Parte 1, luego compáralo con el mío y mira qué cambia respecto al panorama del capítulo 4.
Cuando termines, ponte a prueba con la guía de estudio del capítulo: una lista de verificación para el examen, los hábitos que van más allá, las palabras que conviene conocer y algunas preguntas. Cierra la Parte 1; la guía de estudio de la Parte 1 reúne los seis capítulos.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- Qué sistema tiene la autoridad sobre cada atributo importante, y cómo se refleja eso en el modelo.
- Qué estilo de gestión de datos maestros encaja con cada dominio de datos, y cuánta autoridad recibe la capa de datos maestros.
- Cuándo fusionar, cuándo vincular, y quién es dueño de cada regla de supervivencia.
- Qué tan estricto debe ser el emparejamiento, según lo que cuesta un falso emparejamiento.
- Dónde los datos en dos sentidos y las jerarquías compartidas necesitan fronteras explícitas.
Más allá del examen: los agentes necesitan una identidad sobre la que actuar, y eso sube lo que está en juego en los dos sentidos. Emparejar de más se convierte en un incidente de privacidad, y un agente que “actualiza al cliente” tiene que escribir en el sistema de registro de cada atributo, no en el perfil unificado. Cada módulo termina con lo que cambia la IA.
Explora
Sección titulada «Explora »- Salesforce Architects, Data 360 Architecture (opens in a new tab) (en inglés), consultado el 2026-10-14.
- Ayuda de Salesforce, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) e Identity Resolution Reconciliation Rules (opens in a new tab) (en inglés), consultado el 2026-10-14.
Siguiente: la Parte 2 empieza con Diseñar para la escala (coming soon).