Claves y propiedad de la escritura

🌐 También en 19 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés Esta sección cambió en inglés y aún no se ha vuelto a traducir. (2)

Módulo 2 de 4 del capítulo Integración y movimiento de datos, capítulo 9 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Antes de la flecha · Siguiente: Prueba de entrega

La pregunta que responde este módulo: ¿cómo siguen emparejados los registros, y quién puede cambiar qué?

Cada vez que una integración toca un registro, tiene que responder a dos preguntas: ¿qué registro es este? y ¿de quién es este valor? Si fallas en la primera, creas duplicados o actualizas el registro equivocado. Si fallas en la segunda, sobrescribes datos de los que es dueño otro. No son casos aislados. Son dos de las formas más habituales en que las integraciones dañan una buena arquitectura de datos.

Empieza por los flujos

En el capítulo 6 dibujamos la integración más habitual que veo: un Salesforce y un ERP. Los clientes y los productos entran desde el ERP; los pedidos y las partidas de pedido salen desde Salesforce. Varios flujos, en orden.

Clic para ampliar

Del capítulo 6: Salesforce y el ERP, varios flujos en orden.

Ahora acércate a la primera flecha: los clientes hacia Account. Cada registro que la cruza plantea las dos preguntas. ¿Qué cuenta es este cliente? ¿Y cuáles de sus campos puede escribir el ERP?

“Encuentra el cliente”

El ERP envía un cliente: Steve’s Plumbing, condiciones de pago Net 30. ¿Qué cuenta? ¿Buscar por nombre? Entonces te encuentras con Steve’s Plumbing, Steve’s Plumbing LLC, Steve’s Plumbing - West y un Steve’s Plumbing & Heating que no tiene nada que ver. Todo el mundo sabe que los dos primeros son la misma empresa, y la integración no. Los nombres son útiles para las personas y pésimos como claves de integración. La integración necesita un identificador estable.

Un registro, una clave

Así que cuando un registro de Salesforce se corresponde uno a uno con un registro de un sistema externo importante, guarda la clave de ese sistema en el registro de Salesforce, en un campo marcado como External ID. El número de cliente 10442 del ERP vive en la cuenta. Ahora las actualizaciones del ERP no necesitan adivinar.

Y un External ID puede dirigir un upsert: una sola llamada que decide por ti. Si no se encuentra la clave, se crea el registro (salvo que la llamada diga solo actualizar). Si se encuentra una vez, se actualiza ese registro. Si se encuentra más de una vez, la llamada falla con un error y no se crea ni se actualiza nada (Insert or Update (Upsert) a Record Using an External ID (se abre en una pestaña nueva), REST API Developer Guide, consultado el 2026-10-27). Eso hace que las integraciones sean mucho más fáciles de reanudar con seguridad.

Esa última regla es la razón por la que marco también el campo como Único. External ID dice que este campo guarda el identificador de otro sistema y se puede usar para emparejar. Único dice que dos registros nunca pueden compartir el valor (Custom Field Attributes (se abre en una pestaña nueva), Salesforce Help, consultado el 2026-10-27). Si la arquitectura depende de una correspondencia uno a uno, prefiero encontrarme el conflicto en el momento en que alguien crea una segunda cuenta con 10442 que descubrirlo como un misterio de integración seis meses después.

Conocimiento para el examen. El upsert empareja por un campo External ID: sin coincidencia crea un registro, con una coincidencia lo actualiza, con más de una falla sin cambiar nada. Marcar el campo External ID como Único evita los duplicados que causan ese fallo. Un objeto puede tener hasta 25 campos External ID, y los campos marcados como Único cuentan para ese límite.

Dos comprobaciones antes de confiar en él

Primera: ¿la relación es de verdad uno a uno? Un registro de Salesforce para un registro externo, y a la inversa. Si un cliente del ERP corresponde a tres cuentas de Salesforce, o tres clientes del ERP corresponden legítimamente a una cuenta porque Salesforce modela el padre de otra manera, el External ID no puede ser una clave uno a uno. No fuerces una relación complicada en un campo porque los External ID sean cómodos; diseña otra forma de identificar los registros.

Segunda: ¿el campo guarda la clave de un solo sistema, con un solo significado? Si un campo a veces guarda el número del ERP y a veces el de un socio, ¿de quién es el número 847291? El campo ya no dice qué significa su valor. Un campo de clave, un significado.

Cuando el cliente está en dos ERP

Luego la empresa abre una oficina en Múnich, y el ERP europeo crea su propio registro de cliente para Steve’s Plumbing: el cliente 88310. La misma empresa, dos registros en ERP, dos claves. No pueden vivir los dos en un solo campo External ID de una sola cuenta.

La respuesta es la regla del capítulo 6: añade registros, no campos. Da a cada registro del ERP su propio registro de Salesforce, uno a uno: cuentas hijas bajo un padre, cuentas pares, o una cuenta con un objeto hijo por ERP. Cuál depende de cuánto de la estructura del ERP debe ver ventas, y de lo bien que el cliente mantenga sincronizados sus propios ERP.

Clic para ampliar

Una de las tres maneras: un objeto hijo por cada registro del ERP. Las tres, y los costes de cada una, están en el capítulo 6: Un cliente, dos ERP.

Lo que no quiero es la cuarta respuesta: una cuenta con un campo de clave por cada ERP, NA_ERP_ID__c, EMEA_ERP_ID__c, y otro cada vez que la empresa compra un negocio. Es un antipatrón que no me gusta. Esconde una estructura repetida en campos, convierte cada ERP nuevo en un cambio de esquema y gasta la asignación de campos External ID del objeto adquisición a adquisición. Las integraciones hacen tentador ese error, porque cada flecha nueva parece necesitar “su” campo. No es así. Necesita su registro.

Steve Trucking: un campo, el origen en el valor

Ahora nuestro propio panorama. En el módulo 1 nos acercamos a los manifiestos de Redrock: unas 1.100 entregas al día, cada una convertida en una orden de trabajo. En el Checkpoint 1 dimos a cada orden de trabajo un campo External ID, único, que guarda la propia referencia de pedido y de entrega del socio con el nombre del socio en el valor.

Clic para ampliar

Un campo de clave en cada orden de trabajo. El valor dice de quién es la entrega.

¿Es la misma regla? Sí. Una orden de trabajo procede exactamente de un socio, así que cada registro tiene exactamente una clave de un origen. El significado del campo nunca cambia: la referencia de entrega del socio minorista. Y como el valor nombra al socio, REDROCK-8472914-1 nunca puede chocar con una entrega de Keystone que tenga casualmente el mismo número.

Ahora el cambio de última hora del encargo: un cuarto socio, Oakline, quiere ponerse en marcha en tres centros de distribución en 90 días.

Clic para ampliar

Un socio nuevo son datos nuevos, no un cambio de esquema.

Con un campo de clave por socio, Oakline supondría un campo nuevo, una lógica de emparejamiento nueva y una implementación antes del primer manifiesto. Con un solo campo y el origen en el valor, supone un prefijo nuevo. La cuenta y la orden de trabajo acaban siguiendo la misma regla desde direcciones distintas: una clave por registro. Cuando una cosa del negocio tiene varios registros externos, añade registros. Cuando cada registro tiene un solo origen, basta con un campo, siempre que el valor diga qué origen.

Las claves hacen seguros los reintentos

Recuerda el final del módulo 1. El manifiesto de Redrock de esta noche agotó el tiempo de espera de camino a Salesforce, y la capa de integración no sabía si se había guardado algo (Y cuando falla). Así que volvió a enviar el manifiesto. Una inserción a ciegas habría creado una segunda orden de trabajo por cada entrega que ya se había guardado. Un upsert por la clave del socio empareja los registros existentes y crea solo lo que falta. Ese es el principio de la idempotencia: repetir una operación no debería seguir creando efectos adicionales. El módulo 3 va más allá. Los reintentos seguros empiezan por las claves.

Una clave no es autoridad

La clave le dice a Salesforce qué cliente. No significa que el ERP sea dueño de todos los campos de la cuenta. Identificar el registro y la autoridad son preguntas distintas, por eso “el ERP sincroniza las cuentas con Salesforce” es un diseño peligroso. ¿Todos los campos? ¿Algunos? ¿En los dos sentidos? ¿Cuál gana? Eso no es una arquitectura de datos; es una discusión esperando a ocurrir.

Cuando enseño esto, le pregunto a la sala: ¿qué campos vienen de SAP? El nombre, la dirección, las direcciones de facturación y de envío, las condiciones de pago. Esos son los campos de datos maestros del ERP. Luego: ¿podemos añadir en Salesforce nuestros propios campos que no enviamos a SAP? Sí. Una valoración de ventas, la fecha del último pedido, prácticamente cualquier cosa relacionada con marketing. Así que la cuenta en Salesforce es un golden record que en realidad es híbrido: el ERP es el sistema de registro para algunos campos, Salesforce para otros.

Clic para ampliar

Un registro, dos dueños. La integración escribe los campos del ERP; ventas edita los de Salesforce.

Esa es la regla del capítulo 6, la autoridad se asigna atributo por atributo (Una fuente de verdad por atributo), hecha ejecutable. La regla no es “el ERP puede actualizar Account”. Es “el ERP puede actualizar los campos de los que es dueño el ERP”. Un contrato mucho más sólido.

Y protégelo en la organización, no solo en un documento. Una construcción habitual que he visto en muchas implementaciones: separar las cuentas del ERP por tipo de registro, y dejar que solo la integración las cree. Los vendedores crean y editan sus propias cuentas de ventas; las cuentas de cliente del ERP entran por la integración, con los campos del ERP de solo lectura en el formato de página (Un tipo de registro para cada flujo).

Conocimiento para el examen. La autoridad de escritura se hace cumplir en la organización, no solo en la integración. Espera tener que separar por tipo de registro los registros de los que es dueña la integración, hacer de solo lectura para los usuarios los campos de la integración con formatos de página y seguridad a nivel de campo, y dar al usuario de integración solo el acceso que necesita su contrato.

Cuando Salesforce quiere cambiar un campo que es del ERP

Un comercial necesita cambiar las condiciones de pago. Son del ERP. Mala respuesta número uno: dejar que Salesforce las cambie localmente hasta que el ERP las sobrescriba. El cambio del usuario parece funcionar y luego desaparece misteriosamente. Mala respuesta número dos: dejar que los dos sistemas las escriban y que gane la última escritura. Eso no es gestionar como maestro; es una condición de carrera.

Si el ERP es dueño del campo, un cambio desde Salesforce es una solicitud al sistema con la autoridad. A veces el ERP es incluso dueño de la creación: no puedes simplemente crear la cuenta, envías una solicitud mediante una API y el ERP la crea.

Clic para ampliar

Una solicitud, no una edición. El ERP la acepta o la rechaza, y su respuesta vuelve por la integración.

El ERP la acepta o la rechaza, y el valor con autoridad vuelve por la misma flecha de siempre (Cuando la autoridad es compartida). La integración es donde ese modelo de autoridad se hace real.

Movimiento en dos sentidos, un dueño por campo

“Necesitamos una integración bidireccional.” De acuerdo, pero eso no me dice lo suficiente. Los datos pueden moverse en los dos sentidos mientras cada campo sigue teniendo un solo dueño. Mira las flechas de Redrock en Steve Trucking: el manifiesto entra, y Redrock es dueño de lo que se pidió y de adónde va; el estado vuelve a salir, y Salesforce es dueño de la cita, el equipo y el estado de la entrega. Movimiento en dos sentidos, autoridad clara, muy distinto de “los dos sistemas pueden actualizarlo todo”. El movimiento bidireccional no exige autoridad bidireccional.

Y cuando los dos sistemas pueden escribir de verdad el mismo campo, aparece el bucle: Salesforce cambia el número de teléfono, lo envía al ERP, el ERP ve un cambio y lo devuelve, Salesforce ve un cambio… Un buen diseño de integración distingue un cambio de negocio real del eco de uno que acaba de enviar, y hay varias maneras técnicas de hacerlo. Pero el arquitecto de datos debería ver la causa de fondo: la autoridad de escritura y la procedencia de los cambios no están lo bastante claras. Cuanto más limpio es el modelo de autoridad, menos bucles tienes que esquivar con ingeniería.

Haz visible la autoridad, y pregunta por qué copias

Por eso me gustan los nombres que muestran quién es dueño de los datos de propiedad externa: a veces ERP_Credit_Status__c es mejor que Credit_Status__c, porque el propio campo dice “esto viene del ERP”. No todo campo integrado necesita un prefijo; usa el criterio. Pero cuando la autoridad importa, un futuro desarrollador no debería necesitar un documento de arquitectura de 90 páginas para enterarse de “no actualices eso, es del ERP”. Debería decirlo el modelo.

Y si el ERP es dueño del estado de crédito, ¿necesita Salesforce siquiera una copia? Quizá: si la gente lo necesita constantemente, la automatización depende de él, los informes lo usan y la frescura necesaria es alcanzable. Pero cada copia es una responsabilidad de sincronización. Si Salesforce solo necesita el valor de vez en cuando y debe estar siempre al día, traerlo de la fuente puede ser mejor; eso es la virtualización, en la Parte 3. La pregunta no es “¿podemos integrar el campo?”. Es “¿por qué lo copiamos?”.

Las claves también tienen ciclo de vida

Los identificadores externos no siempre son permanentes. Los sistemas fusionan clientes, las organizaciones se consolidan, una empresa adquirida trae su propio ERP, se retiran ID heredados, los registros reciben números nuevos en una conversión. Para cada clave importante entre sistemas: ¿quién la asigna, cuándo, puede cambiar, puede reutilizarse, qué pasa en una fusión o una migración, y conservamos el ID antiguo para la trazabilidad? Cuando una empresa compra un negocio que tiene su propio ERP, la respuesta es un registro nuevo por cada registro del ERP, no un campo nuevo. Una clave forma parte del ciclo de vida de los datos.

Lo mismo vale entre orgs de Salesforce. Tras una adquisición, la org A y la org B: un ID de registro de la org A significa algo en la org A. No es automáticamente la clave de la empresa. Si la org B debe emparejar la misma entidad de negocio, sigues necesitando una estrategia deliberada de identidad entre sistemas. A estos efectos, dos orgs de Salesforce son dos sistemas.

Las claves hacen posible la recuperación

Un trabajo nocturno se dispone a enviar 20.000 actualizaciones de clientes y falla en la 12.417. Mañana, ¿qué? ¿Empezar de nuevo? ¿Continuar? ¿Cuáles salieron ya bien? Con claves estables y upserts seguros, tienes opciones: reintentar, reanudar, conciliar, detectar duplicados, comparar origen y destino, demostrar que está completo. Sin ellas, la recuperación se complica enseguida. Identificar bien los registros no es solo una cuestión de modelado. Es fiabilidad operativa.

Más allá del examen: lo que cambia la IA. “Agente, actualiza el cliente.” ¿Qué cliente, con qué clave, y actualizar qué: todo lo que técnicamente pueda alcanzar? Un agente es otro cliente de integración. Sus acciones necesitan claves explícitas y contratos de escritura estrechos: encontrar el registro correcto, respetar el origen con la autoridad, escribir solo los campos que esa acción puede escribir, convertir en solicitudes los cambios en campos de otro sistema, conservar la procedencia y no convertir los reintentos en duplicados. La autonomía hace que esos controles sean más importantes, no menos.

Lo que decide aquí un arquitecto

• Qué clave estable identifica el mismo registro de negocio en cada frontera importante entre sistemas, y si la relación es de verdad uno a uno.
• Cuando una cosa del negocio tiene varios registros externos, qué registros los representan: una jerarquía, pares o un objeto hijo, nunca un campo de clave por sistema.
• Qué sistema es dueño de cada atributo importante, y por tanto qué integración puede escribirlo, aplicado con tipos de registro, formatos de página y seguridad a nivel de campo.
• Cómo un cambio en un campo del que es dueño otro sistema se convierte en una solicitud a ese sistema.
• Cómo el movimiento en dos sentidos mantiene clara la autoridad, en lugar de convertirse en que gane la última escritura.
• Si los datos de propiedad externa deberían copiarse en absoluto, y cómo se aplican las mismas reglas a los agentes y a otras orgs de Salesforce.

Cada escritura de una integración tiene que responder ¿qué registro? y ¿de quién es el valor? La clave responde a la primera; el modelo de autoridad, a la segunda. Así que no te conformes con “el ERP sincroniza las cuentas”. Dime cómo identifica el ERP la cuenta, qué clave guardamos y en qué registro, si es de verdad uno a uno, de qué campos es dueño cada sistema, qué pasa cuando Salesforce quiere cambiar un valor del ERP y qué pasa al reintentar. Conoce el registro. Conoce al dueño. Luego deja que la integración escriba.

Explora

• Salesforce Developers, REST API Developer Guide, Insert or Update (Upsert) a Record Using an External ID (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce Help, Custom Field Attributes (se abre en una pestaña nueva) (External ID and Unique), checked 2026-11-01. ⟲
• Este curso, capítulo 6: Cuando la autoridad es compartida, para los varios flujos y las tres maneras de representar un cliente en dos ERP.
• El curso Integration Architect: Los patrones de integración y Multi-org (coming soon).