Datos maestros e identidad

🌐 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)

Imagen generada con IA

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

Guía de estudio del capítulo 6 del curso Data Architect. Lee primero los seis módulos, incluido el recorrido del Checkpoint 1; esta página te ayuda a comprobar lo que te quedó.

Sobre esta guía de estudio. Está construida solo con el contenido de este curso y con la lista de objetivos publicada en la guía del examen de Salesforce. Nunca se basa en preguntas reales del examen, y no pretende saber qué hay en el examen. Si ya hiciste el examen, por favor no me envíes preguntas: el acuerdo de certificación prohíbe compartirlas, y memorizar respuestas es, de todos modos, la forma equivocada de convertirse en arquitecto.

Este capítulo lleva la sección Master Data Management del examen (5%) y la vista única del cliente de Salesforce Data Management. Es una sección pequeña por su peso, pero sus ideas (autoridad, emparejamiento, supervivencia) aparecen dentro de muchos otros escenarios. Los números de la plataforma cambian, así que comprueba los actuales antes de confiar en ellos.

Para el examen

Márcalos a medida que avanzas. Cada uno enlaza con el lugar donde se enseña.

MDM-2: un golden record y un sistema de verdad

• Sé que la autoridad se asigna por atributo, no por registro: una cuenta puede tener campos gestionados como maestros en el ERP y campos gestionados en Salesforce. (La verdad pertenece a un atributo)
• Pregunto dónde se crea, se edita y se referencia cada atributo, y cuál es su latencia de cambio. (¿Dónde se crea, se edita, se referencia, y con qué rapidez?)
• Puedo construir un mapa de autoridad, y sé que el dueño de negocio y el sistema con la autoridad no son lo mismo. (Construye un mapa de autoridad)
• Sé que la autoridad puede cambiar a lo largo del ciclo de vida (un prospecto en Salesforce se convierte en un cliente gobernado por el ERP), y que una copia no es autoridad. (La autoridad cambia a lo largo del ciclo de vida, Una copia no es autoridad)

MDM-1: técnicas de MDM

• Conocimiento para el examen: conozco los cuatro estilos de implementación de MDM, registro, consolidación, coexistencia y centralizado: qué centraliza cada uno y si devuelve los valores. (Los cuatro lado a lado)
• Puedo distinguir los cuatro estilos de MDM: registro, consolidación, coexistencia y centralizado, y elegir el más ligero que resuelva el problema. (Los cuatro lado a lado)
• Sé que un modelo de datos canónico armoniza la estructura, pero no decide la autoridad. (Un modelo común no es una verdad común)
• Sé el orden: armonizar, luego emparejar, luego consolidar. (Armoniza, luego empareja, luego consolida)
• Sé que los umbrales reflejan la tolerancia al error, y que el enriquecimiento necesita procedencia. (Umbrales, revisión y enriquecimiento)
• Conocimiento para el examen: conozco la gestión de jerarquías: Parent Account construye la jerarquía (la vista de Lightning muestra hasta 2,000 cuentas, sin cuentas personales), las jerarquías suelen tener varios maestros, y una empresa puede tener varias jerarquías válidas. (Las jerarquías también son datos maestros, Una jerarquía, varios maestros)

MDM-3: elegir los atributos ganadores

• Mantengo separados emparejar, fusionar y la supervivencia. (Emparejar, fusionar y la supervivencia)
• Conozco las reglas de supervivencia: el más reciente, el más frecuente, la prioridad de la fuente, y sé que cada regla necesita un dueño. (Supervivencia: ¿qué valor gana?)
• Sé que una coincidencia no exige una fusión, y fusiono solo cuando hay un ganador claro, decidiendo primero qué pasa con los hijos. (Una coincidencia no exige una fusión, Mi regla para fusionar: un ganador claro)
• Conocimiento para el examen: sé lo que hace una fusión de cuentas en Salesforce: hasta tres registros, uno principal, se conservan el Created By y el Created Date más antiguos, los demás van a la Papelera de reciclaje, y en las cuentas personales los objetos de punto de contacto no se fusionan. (Lo que hace de verdad una fusión en Salesforce)

SDM-3: una vista única del cliente

• Sé que la resolución de identidades de Data 360 vincula perfiles de origen en un perfil unificado y conserva los vínculos de vuelta: lo más parecido a un registro. (La resolución de identidades responde “¿quién?”)
• Conocimiento para el examen: conozco las reglas de emparejamiento de Data 360: todos los criterios de una regla deben coincidir, y basta con que coincida cualquier regla; más criterios para la precisión, menos para la consolidación. (Reglas de emparejamiento)
• Conozco los métodos de emparejamiento (Exact, Exact Normalized, Fuzzy con tres niveles de precisión): un método menos preciso aumenta la consolidación, y el riesgo de falsos emparejamientos. (Reglas de emparejamiento)
• Conocimiento para el examen: sé que las reglas de reconciliación (Last Updated, Most Frequent, Source Priority) deciden lo que muestra el perfil unificado, pero no cambian las fuentes; los puntos de contacto no se reconcilian. (Reconciliar sigue sin ser gestionar como maestro)
• Puedo elegir entre la gestión de duplicados, la resolución de identidades y una plataforma de MDM dedicada según el trabajo. (Tres herramientas para tres trabajos)

MDM-4 y los datos en dos sentidos

• Sé que datos en dos sentidos no significa dos maestros: una edición en Salesforce de un campo que es del ERP es una solicitud, así que diseño solicitar → validar → aceptar → publicar, con un estado pendiente. (Datos en dos sentidos no significa dos maestros, Cuando el maestro dice que no)
• Sé cómo evitar los bucles y las colisiones: distinguir un cambio original de su eco, y decidir qué campos viajan juntos como una sola transacción. (Bucles y colisiones)
• Para un cliente que está en dos ERP, puedo elegir una jerarquía, cuentas pares o una cuenta con un hijo por ERP, según lo bien que el cliente mantenga sincronizados sus ERP. (Un cliente, dos ERP, Pregunta cómo mantienen sincronizados los ERP)

Checkpoint 1: unir la Parte 1

• Conocimiento para el examen: sé qué licencias externas incluyen el uso compartido estándar: Customer Community Plus y Partner Community, que necesitan funciones para los usuarios externos; Customer Community usa conjuntos de uso compartido (sharing sets). (Quién ve qué, y quién necesita una licencia)

Más allá del examen

El examen es el piso, no el techo. Estos son los hábitos de este capítulo que necesita un arquitecto, los pregunte o no el examen.

• “Única fuente de verdad”: ¿qué verdad? Es una arquitectura de la verdad, no un registro.
• Haz visible la autoridad en el esquema: un prefijo para los campos de los que es dueño otro sistema.
• La confianza necesita más que un valor: la fuente, la última confirmación, quién lo cambió.
• Empieza por el problema, no por el producto de MDM. El MDM es una decisión de negocio sobre la autoridad.
• Vincular no es gestionar como maestro.
• Donde los falsos emparejamientos salen caros, empareja de menos a propósito.
• Conserva los duplicados de las cargas externas cuando puedas necesitar rastrear su origen.
• Un perfil unificado es un mapa. Un golden record es una decisión.
• Presentar no es tener autoridad.
• Unificar la identidad no borra las fronteras de seguridad.
• Lo más difícil son las bidireccionales. La autoridad compartida no es el problema; la autoridad ambigua sí.
• Nunca dejes que una solicitud rechazada se convierta en una verdad que compite.
• Un campo que diga que esto son datos maestros determina si se puede editar, no un tipo de registro.
• No controlamos los ERP. Controlamos cómo los representamos en Salesforce.

Palabras que conviene conocer

Término	En una línea
Gestión de datos maestros (MDM)	Establecer y gobernar la identidad y los valores con autoridad de los datos clave entre sistemas
Mapa de autoridad	Para cada atributo: quién lo crea, quién es dueño de la decisión, qué sistema tiene la autoridad, quién puede cambiarlo
Golden record	Una decisión gobernada sobre qué valores tienen la autoridad
Golden record híbrido	Un registro con algunos atributos gestionados en otro lugar y copiados, y otros propios
Registro (registry)	MDM que vincula registros como la misma entidad sin cambiar las fuentes
Consolidación	MDM que combina los datos de forma central, normalmente para análisis, sin devolverlos
Coexistencia	MDM que decide el valor maestro y lo vuelve a publicar en las fuentes
MDM centralizado	MDM en el que los datos gobernados se crean en el maestro y se distribuyen
Modelo de datos canónico	Una forma empresarial acordada para un concepto, usada para mapear los sistemas entre sí
Armonización	Hacer comparables los valores: formatos, códigos y abreviaturas estándar
Emparejamiento (matching)	Decidir si unos registros representan lo mismo
Supervivencia (survivorship)	Reglas sobre qué valor gana cuando las fuentes no coinciden
Registro principal	En una fusión de Salesforce, el registro que sobrevive y conserva sus campos ocultos y de solo lectura
Método de emparejamiento	Cómo compara los valores un criterio de emparejamiento de Data 360: exacto, exacto normalizado o difuso (fuzzy)
Resolución de identidades	El emparejamiento de Data 360 de perfiles de origen en perfiles unificados
Perfil unificado	Un conjunto de claves que vincula los registros de origen que representan a una persona o empresa
Reglas de reconciliación	Reglas de Data 360 sobre qué valor muestra un perfil unificado
Jerarquía con varios maestros	Una jerarquía cuyas ramas son de sistemas distintos

Ponte a prueba

Escenarios cortos al estilo del curso. Decide tu respuesta antes de abrirla.

1. "Salesforce es nuestra única fuente de verdad para el cliente." ¿Qué preguntas?

¿Qué verdad? La autoridad es por atributo: el ERP puede ser dueño del nombre legal, la dirección de facturación y el límite de crédito mientras Salesforce es dueño del ejecutivo de cuenta y el nivel de éxito. Construye un mapa de autoridad. Vuelve a leer La verdad pertenece a un atributo.

2. Los agentes de servicio necesitan ver que un contacto de Salesforce es la misma persona que compró en línea. Nadie necesita que los sistemas cambien. ¿Qué estilo de MDM?

Un registro: vincula los registros como una identidad sin cambiar las fuentes, que es lo que hace la resolución de identidades de Data 360. Elige el patrón más ligero que resuelva el problema. Vuelve a leer Registro: dime quién es quién.

3. La supervivencia está configurada como "gana el más reciente" para todos los campos. Alguien cambia la copia en Salesforce del nombre legal, que es del ERP. ¿Qué pasa, y qué está mal?

Gana el valor más nuevo, y la copia se impone a la autoridad. “El más reciente” es una declaración sobre la confianza que encaja con algunos atributos (un número de móvil) y no con otros. Donde el mapa de autoridad dice que el ERP es dueño del campo, gana el ERP. Vuelve a leer Supervivencia: ¿qué valor gana?.

4. Se importan registros de clientes de un sistema heredado y coinciden con cuentas existentes. ¿Los fusionas?

Con prudencia. Una coincidencia no exige una fusión, y la fusión destruye los ID heredados y los valores antiguos que puedes necesitar rastrear. Vincúlalos, salvo que haya un ganador claro y el duplicado no aporte nada que necesites. Vuelve a leer Mi regla para fusionar: un ganador claro.

5. El perfil unificado en Data 360 muestra Dallas. El equipo dice que Dallas es ahora el valor maestro para todos los sistemas. ¿Lo es?

No. La reconciliación decide lo que muestra el perfil unificado; no cambia las fuentes ni toma una decisión de datos maestros. Si todos los sistemas deben usar un valor gobernado, eso es coexistencia o MDM centralizado, con un dueño. Vuelve a leer Reconciliar sigue sin ser gestionar como maestro.

6. Emparejar registros médicos frente a registros de marketing: ¿las mismas reglas?

No. Un falso emparejamiento en marketing envía la oferta equivocada; en datos médicos combina los historiales de dos personas. Fija lo estricto según el costo de equivocarse, y empareja de menos donde mezclar sale caro. Vuelve a leer El costo de equivocarse.

7. Los representantes quieren actualizar desde Salesforce una dirección de facturación que es del ERP. ¿Cómo lo diseñas?

Como una solicitud, no como una edición: Salesforce envía el valor propuesto, el ERP lo valida y lo acepta, y vuelve a publicar el valor con autoridad. Mantén un estado pendiente hasta entonces, y maneja el rechazo, las colisiones y los ecos. Vuelve a leer Datos en dos sentidos no significa dos maestros.

8. En Steve Trucking, el mismo John Smith aparece en los manifiestos de dos socios minoristas. ¿Lo unificas?

No, deliberadamente. Ningún socio debe ver los destinatarios de otro, y una identidad unificada es el puente por donde se filtran. Empareja de menos donde mezclar sale caro; si un socio quiere reconocer a los que se repiten, limítalo solo a ese socio. Vuelve a leer ¿Unificaría a los destinatarios entre socios?.

9. Una representante envía una calle nueva para una dirección que es del ERP mientras, en el mismo minuto, alguien en el ERP cambia la ciudad. ¿Qué decides?

Si la dirección viaja como una sola transacción. Si es así, todos los campos van juntos o no va ninguno, y la solicitud se rechaza porque la dirección cambió mientras tanto. Decídelo antes de la primera colisión, y recuerda que la solicitud pide cambiar el valor del ERP, no lo cambia. Vuelve a leer Bucles y colisiones.

10. Una empresa cliente tiene a uno de sus clientes en dos ERP, y nadie mantiene sincronizados los dos registros. Ventas quiere una sola cuenta. ¿Qué recomiendas?

Una sola cuenta, no. Si no pueden mantener sincronizados los registros en sus propios ERP, Salesforce no puede hacerlo por ellos: represéntalos como cuentas pares o como una jerarquía, y muestra la estructura que ventas ya conoce. Una cuenta con un hijo por ERP necesita un cliente que mantenga sincronizados los valores compartidos. Vuelve a leer Pregunta cómo mantienen sincronizados los ERP.

Explora

• Guía del examen Salesforce Certified Platform Data Architect (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-09-25): la lista oficial de objetivos y sus pesos. Revisa siempre la versión actual antes de reservar el examen.
• La sección Explora de cada módulo enumera la documentación de Salesforce detrás de sus datos, con la fecha en que se comprobaron.