Jerarquías y datos en dos sentidos

🌐 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

Módulo 5 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: Un mapa no es una decisión · Siguiente: Checkpoint 1: Steve Trucking

La pregunta que responde este módulo: ¿Cómo gestionas los datos que mantiene más de un sistema?

La arquitectura fácil: el ERP es dueño del cliente, Salesforce recibe una copia, listo. Las empresas reales no son tan limpias. El ERP es dueño del cliente legal y Salesforce de la relación comercial; una división vive en SAP, otra adquirida en un ERP distinto; los prospectos existen solo en Salesforce. Luego alguien quiere que los usuarios de Salesforce actualicen un campo que controla el ERP, y las flechas empiezan a apuntar en los dos sentidos. Como digo cuando enseño esto: “Lo más difícil son las bidireccionales.” No porque enviar datos en los dos sentidos sea técnicamente difícil, sino porque, en cuanto los dos sistemas participan en el cambio, tienes que ser extremadamente preciso con la autoridad.

Datos en dos sentidos no significa dos maestros

El ERP es dueño de la dirección de facturación, copiada en Salesforce. Una representante se entera por el cliente de que ha cambiado, y el negocio quiere que la actualice sin salir de Salesforce. Razonable. Ahora los datos fluyen ERP → Salesforce y Salesforce → ERP. ¿Salesforce pasa a ser codueño de la dirección de facturación? No. La dirección de una integración no decide la autoridad. La representante no está cambiando la copia de Salesforce. En términos de arquitectura, está pidiendo cambiar el valor con autoridad. No estás cambiando el campo del ERP; estás pidiendo cambiarlo. Salesforce es la interfaz; el ERP sigue siendo el maestro.

Eso cambia el diseño. Si Salesforce fuera dueño del campo, guardar y listo. Si el ERP es su dueño, “guardar” significa que Salesforce envía la dirección propuesta, el ERP la valida y la acepta, actualiza su maestro y devuelve el valor con autoridad. Solo entonces ha cambiado el valor gobernado: solicitar → validar → aceptar → publicar, no “actualizar los dos sistemas y esperar que sigan sincronizados”.

Click to enlarge

Una integración en dos sentidos no crea una autoridad en dos sentidos.

Cuando el maestro dice que no

El ERP rechaza el cambio: el cliente está inactivo, la dirección incumple una regla del ERP, el usuario no puede cambiar direcciones legales, el ERP está caído, o alguien más cambió el cliente mientras tanto. Si Salesforce ya mostraba la nueva dirección, ahora tenemos dos verdades, y el módulo 1 ya nos dijo cuál gana: la del ERP. Así que la arquitectura necesita un estado de solicitado, todavía no aceptado: un valor propuesto aparte, un indicador de “cambio pendiente”, o esperar la confirmación antes de mostrarlo. El mecanismo depende del caso de uso. La regla no: nunca dejes que una solicitud rechazada se convierta en una verdad que compite.

Bucles y colisiones

Este es un clásico. El ERP actualiza Salesforce; la integración de Salesforce ve un cambio y lo envía al ERP; el ERP ve una actualización y la devuelve. Has construido un bucle muy caro. Un buen diseño en dos sentidos sabe dónde empezó un cambio, si el maestro lo ha aceptado, y si se trata de un cambio de negocio nuevo o solo del eco de uno ya procesado: identificadores de origen, marcas de tiempo, metadatos de integración, procesamiento idempotente. El capítulo de Integración profundiza en ello. El principio de datos maestros es simple: sabe si estás originando un cambio o reflejándolo.

Luego, las colisiones. Ya viste una en el capítulo 5: una representante pide Steve’s Plumbing LLC mientras alguien en el ERP escribe Steve’s Plumbing L.L.C. (Protege el registro gobernado). Aquí va otra. Salesforce propone 125 Main Street; casi en el mismo momento, un usuario del ERP la cambia a 130. ¿Cuál gana? No hay una respuesta técnica universal. Quizá el ERP gana siempre porque es dueño del campo; quizá la solicitud de Salesforce va a una cola de revisión; quizá gana el cambio aceptado más tarde; quizá el ERP rechaza cualquier actualización cuyo valor de partida haya cambiado. Eso es concurrencia, pero debajo hay una decisión de autoridad, y ningún patrón de integración te salva si nadie decidió quién puede hacer el cambio con autoridad.

Y un solo campo es el caso sencillo. Una dirección es una calle, una ciudad, un código postal. Salesforce envía una calle nueva mientras el ERP acaba de cambiar la ciudad. ¿Dejas pasar la calle por su cuenta? ¿O tratas la dirección como una sola transacción, de modo que todos los campos van juntos o no va ninguno, y rechazas el cambio completo? Decide qué campos viajan como grupo antes de la primera colisión, no después.

Siempre que veo una integración en dos sentidos, pregunto ¿qué pasa cuando los dos lados cambian los mismos datos? Si la respuesta es “eso probablemente no va a pasar”, no hemos terminado. ¿Cuál gana, rechazamos, encolamos, comparamos versiones, revisamos? ¿Debería el campo poder editarse en los dos lugares? A veces el mejor diseño en dos sentidos elimina una dirección para un atributo concreto: Salesforce puede solicitar; solo el ERP publica el valor aceptado. Los datos siguen moviéndose en los dos sentidos, pero solo un sistema gestiona el campo como maestro. Esa diferencia lo es todo.

Las jerarquías también son datos maestros

Las relaciones también pueden ser datos maestros. Una matriz global con regiones de Norteamérica y Europa, cada una con filiales por país: la jerarquía en sí tiene significado. ¿Quién es la matriz? ¿Qué filial está bajo qué entidad legal? ¿Qué cuentas se consolidan en el cliente global? Eso impulsa los informes, los territorios, los precios, los contratos, la exposición crediticia, el servicio, el acceso a los datos y el análisis. Una jerarquía puede importar tanto como los registros que contiene, y necesita el mismo gobierno. (El examen menciona la gestión de jerarquías; es fácil olvidarla.)

En Salesforce, las jerarquías de cuentas se construyen con el campo Parent Account (cuenta principal). La vista de jerarquía de Lightning muestra hasta 2,000 cuentas, y solo las que el usuario puede ver; las cuentas personales no se admiten en la jerarquía; y Account Site distingue las ubicaciones de una empresa (Considerations for Using Account Hierarchy (opens in a new tab), en inglés). Pero el campo Parent Account no responde la pregunta de arquitectura: ¿quién es dueño de la jerarquía?

Conocimiento para el examen. Conoce lo básico de la jerarquía de cuentas: se construye con Parent Account; la vista de Lightning muestra hasta 2,000 cuentas, solo las que el usuario puede ver; las cuentas personales no se admiten; y Account Site distingue las ubicaciones de una empresa.

Una jerarquía, varios maestros

Según mi experiencia, las jerarquías tienen varios maestros. Las entidades de Norteamérica vienen de SAP, las europeas de otro ERP, los nuevos prospectos se construyen en Salesforce, y una filial adquirida todavía no ha migrado. ¿Quién es dueño de la jerarquía? Depende de la rama. Cada ERP controla su rama; Salesforce controla las relaciones de los prospectos hasta que se convierten. Es una arquitectura legítima, siempre que todos sepan dónde están las fronteras. Decide rama por rama.

Click to enlarge

La autoridad sobre la jerarquía se puede asignar rama por rama.

Así que no dejes que el campo Parent Account esconda la autoridad. Un usuario cambia en Salesforce la cuenta principal de una filial. Técnicamente trivial. En términos de arquitectura, ¿acaba de cambiar la estructura legal de la empresa? Si el ERP gestiona esa rama como maestro, probablemente no, así que Salesforce debería bloquearlo, o convertirlo en una solicitud de cambio. O quizá Salesforce mantiene legítimamente una jerarquía comercial mientras el ERP mantiene la legal. Entonces quizá no deberían ser la misma relación en absoluto.

Una empresa puede tener varias jerarquías válidas: legal, de facturación, de ventas, de servicio, geográfica. La matriz global firma el contrato, las regiones reciben servicio por su cuenta, la facturación pasa por una entidad financiera compartida, ventas gestiona por región. ¿Cuál es la jerarquía verdadera? Todas; responden preguntas distintas. El error es suponer que tiene que haber una sola. Debería haber una autoridad clara para cada tipo de relación: el principio por atributo del módulo 1, aplicado a las relaciones.

Y no toda relación padre-hijo es un dato maestro. Agrupar las entregas de hoy en una ruta es una relación, pero es transaccional, un evento operativo. Una jerarquía de clientes describe una relación de negocio duradera. Las dos parecen padre-hijo en un modelo; no comparten ciclo de vida. Pregunta qué significa la relación y cuánto dura ese significado.

Un cliente, dos ERP

Cuando enseño esto, le pregunto a la sala: ¿quién ha trabajado con un cliente que tiene un Salesforce y más de un ERP? Siempre se levantan manos. Pregunta por qué, y resulta que los ERP están divididos por región (uno para Norteamérica, otro para Europa), por función (una empresa de plomería compra una empresa eléctrica, y cada una conserva su propio ERP) o simplemente por historia: el negocio se adquirió y nadie lo ha migrado todavía.

Toma a Steve’s Plumbing como cliente. Hace negocios en Norteamérica, así que el ERP de Norteamérica tiene un registro de cliente para ella. Luego abre una oficina en Múnich, y el ERP europeo crea su propio registro de cliente, con su propio número de cliente. La misma empresa, dos registros, dos ID. ¿Cómo lo represento en una sola org de Salesforce? He visto tres formas.

Una jerarquía de cuentas. Steve’s Plumbing es la principal, con Steve’s Plumbing North America y Steve’s Plumbing Europe como cuentas hijas, y cada hija representa el registro de un ERP. La trampa: las hijas ya no son realmente Steve’s Plumbing. Son Steve’s Plumbing haciendo negocios en una región, y como acabamos de ver, una jerarquía tiene significado.

Cuentas pares. Dos cuentas una al lado de la otra, cada una con un campo que dice a qué ERP pertenece: un código de empresa, una región. No se esconde nada. El costo aparece en los informes: para ver Steve’s Plumbing en todo el mundo, necesitas algo que diga que esas dos cuentas son la misma empresa.

Una cuenta, con un hijo por ERP. Una sola Steve’s Plumbing, y un objeto hijo con un registro para cada ERP que guarda el ID de cliente de ese ERP. Dos ERP o diez. Los vendedores ven un solo cliente y hacen un solo pedido; tras bambalinas, unos flujos deciden a qué ERP va cada línea: el trabajo eléctrico al ERP eléctrico, la plomería al ERP de plomería. Pero ahora tienes que decidir qué ERP es el principal para los valores compartidos, como el nombre y la dirección, y qué pasa cuando el cliente existe en un ERP y no en el otro.

Click to enlarge

Un cliente, dos ERP: tres formas de representarlo en Salesforce.

Pregunta cómo mantienen sincronizados los ERP

¿Entonces cuál? Primero: ¿cuánto de la estructura de los ERP deberían ver los vendedores? Si siempre han sabido que Norteamérica y Europa son negocios separados, porque entran en un ERP o en el otro, no se lo escondas. Lleva esa estructura a Salesforce como cuentas pares. Si el negocio quiere una sola Steve’s Plumbing frente a ventas, estás hablando de una cuenta con un hijo por ERP.

Luego, la pregunta que de verdad lo decide, y no se decide en Salesforce. Le pregunto al cliente: ¿cómo mantienen sincronizados esos dos registros entre sus ERP? No lo que es local de cada ERP, como el saldo; eso es transaccional. Me refiero a los datos maestros: el nombre legal, las direcciones. Si tienen un equipo que mantiene sincronizados los dos ERP, podemos juntarlos en una sola cuenta. Si no pueden mantenerlos sincronizados en sus propios ERP, ¿cómo van a esperar que nosotros los mantengamos sincronizados en Salesforce? Entonces son cuentas pares, o una jerarquía.

Recuerda lo que es un ERP. Son sistemas enormes que tardan años en implantarse, y traen su propia forma de gestionar los datos maestros. Salesforce no los va a dirigir. No controlamos los ERP. Controlamos cómo los representamos en Salesforce.

MDM en el medio

Algunos clientes ya lo resolvieron antes de que lleguemos. Una empresa grande, muchos años en el negocio, varios ERP: se toparon con este problema mucho antes de Salesforce y pusieron un producto de MDM dedicado en el medio para hacer de intermediario entre los ERP. Es el MDM de coexistencia o centralizado del módulo 2. Ahora Salesforce no se conecta a cada ERP. Apunta a un solo lugar, el hub de MDM, y obtiene una única representación del cliente. Pero no esperes encontrarte uno a menudo. Son implementaciones grandes por sí mismas; en todos mis años he trabajado con uno solo dos o tres veces. E incluso con el hub, puede que sigas necesitando ese objeto hijo, para que cada pedido sepa a qué ERP va.

Click to enlarge

MDM en el medio: Salesforce apunta a un solo lugar.

Steve Trucking: ¿de quién es la jerarquía?

Un socio minorista (Retail Partner) tiene su propia estructura: matriz corporativa, divisiones regionales, centros de distribución, tiendas. ¿Steve Trucking es dueño de esa jerarquía? No; el socio es la autoridad sobre su propia organización. Pero Steve Trucking puede necesitar su propia vista comercial de esas mismas ubicaciones, para contratos, gestión de cuentas, servicio e informes, quizá una cuenta hija para cada centro de distribución bajo el socio. Dos jerarquías legítimas, dos autoridades. Ponles nombre, y no finjas que un solo árbol representa todas las relaciones.

Haz visibles las fronteras

Siempre que la autoridad está repartida, quiero que la frontera sea visible: nombres de campos, metadatos de los registros, identificadores del sistema de origen, permisos, comportamiento de la integración, documentación. Lo que no quiero es que un desarrollador tenga que leer cinco integraciones para descubrir que “estos valores de Parent Account vienen de SAP, excepto los prospectos, excepto Europa”. Ese no es un modelo de autoridad mantenible. Si la jerarquía tiene varios maestros, documenta la división. Si la autoridad cambia en la conversión, documenta el cambio. Si Salesforce puede solicitar pero no hacer un cambio, hazlo evidente en la experiencia.

En Salesforce, eso empieza con un campo. Tiene que haber un campo que diga claramente que esto son datos maestros: la clave del ERP, o un indicador de “es dato maestro”. Haz que la posibilidad de editar los campos dependa de ese campo, no de un tipo de registro; con Dynamic Forms ya no necesitas un tipo de registro para mostrar en solo lectura los campos del ERP (capítulo 5, Un tipo de registro para cada flujo). Puedes permitir que se creen registros fuera del maestro, pero vigila las ediciones.

Más allá del examen: lo que cambia la IA. Un cliente le dice a un agente: “cambia nuestra dirección de facturación a 125 Main Street”. El campo está ahí mismo en Salesforce. ¿Debería actualizarlo el agente? No si el ERP es su dueño. Un agente necesita autoridad de escritura, no solo acceso al campo: su acción debería codificar el camino aprobado, enviar una solicitud de cambio y decir “He enviado el cambio para que se procese”, no informar falsamente “He actualizado su dirección de facturación”.

Lo que decide aquí un arquitecto

• Si una edición en Salesforce cambia datos con autoridad o solicita un cambio al sistema que es su dueño.
• Cómo distinguen los flujos en dos sentidos los cambios originales de los ecos, y cómo manejan el rechazo, las colisiones, la latencia y los fallos.
• Quién es dueño de cada jerarquía, rama por rama si hace falta.
• Para un cliente que está en varios ERP: una jerarquía, cuentas pares o una cuenta con un hijo por ERP, según lo bien que el cliente mantenga sincronizados sus ERP.
• Si las jerarquías que compiten son en realidad relaciones legítimas distintas: legal, de facturación, de ventas, de servicio.
• Cómo se hacen visibles las fronteras de autoridad y los caminos de escritura aprobados para los usuarios, las integraciones, los desarrolladores y los agentes.

La autoridad compartida no es el problema. La autoridad ambigua sí. Varios ERP pueden gestionar ramas distintas, Salesforce puede gestionar algunos atributos y solicitar cambios en otros, y varias jerarquías pueden describir una misma empresa. Todo eso funciona, siempre que para cada atributo y relación importante puedas decir quién es su dueño, quién puede cambiarlo, dónde se hace el cambio con autoridad y qué pasa cuando los sistemas no coinciden. Si no puedes, otra flecha en dos sentidos en el diagrama no lo va a arreglar.

Explora

• Ayuda de Salesforce, Considerations for Using Account Hierarchy (opens in a new tab) (en inglés), consultado el 2026-10-14.