Las relaciones tienen consecuencias

🌐 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 7 de 10 del capítulo Arquitectura de datos de Salesforce, capítulo 3 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Los campos también son arquitectura · Siguiente: Propiedad y ciclo de vida

La pregunta que responde este módulo: ¿Qué estoy eligiendo realmente cuando conecto dos objetos de Salesforce?

Dibujar una relación es fácil. En el capítulo 2 dibujamos líneas y les pusimos nombre: un socio minorista envía muchos manifiestos, una entrega lleva muchos artículos, equipos y camiones se encuentran en una Asignación de equipo. Hablamos de cardinalidad, opcionalidad e historial. Ahora implementamos esas líneas en Salesforce, y una línea en un diagrama empieza a cargar mucho más peso.

Cuando elijo un tipo de relación en Salesforce, no solo estoy diciendo estos dos registros están conectados. También puedo estar decidiendo quién es dueño del hijo, si puede existir sin el padre, quién puede verlo, qué pasa cuando se elimina el padre, si puede pasar a otro padre, si puedo resumirlo en el padre y qué pasa cuando hay cientos de miles de hijos. Una relación no es solo una línea. Lleva comportamiento.

Empieza por la relación de negocio

Antes de búsqueda o principal-detalle, vuelve al negocio. Toma una entrega y sus artículos de entrega: el refrigerador, la instalación, el retiro del aparato viejo. ¿Puede existir un artículo sin su entrega? No. Si se elimina la entrega, ¿deberían irse también sus artículos? Sí. ¿Los artículos necesitan su propio dueño o su propia seguridad? En realidad no. ¿Debería alguien pasar un artículo de una entrega a otra? Ojalá no por accidente.

Ahora toma una entrega y la ruta en la que está. La entrega existe antes de tener ruta, puede pasar a otra ruta cuando cambia el plan, y eliminar una ruta nunca debería eliminar las entregas que tiene. Dos líneas de uno a muchos que se ven iguales en un diagrama, con un comportamiento completamente distinto. Fíjate en que todavía no hemos dicho “búsqueda” ni “principal-detalle”. Describe primero el comportamiento. La configuración lo implementa.

Los tipos de relación

Abre la pantalla Campo nuevo y Salesforce te ofrece un puñado de tipos de relación (Object Relationships Overview (opens in a new tab), en inglés):

• Búsqueda (lookup): vincula dos objetos. El pan de cada día de las relaciones de Salesforce.
• Principal-detalle (master-detail): un vínculo padre-hijo en el que el padre controla al hijo.
• Muchos a muchos: no es un tipo de campo propio, sino un patrón: un objeto de unión de Salesforce (Salesforce Junction Object), un objeto personalizado con dos relaciones principal-detalle.
• Autorrelación: una búsqueda de un objeto hacia sí mismo.
• Jerárquica: una búsqueda especial que solo existe en el objeto Usuario, como el gerente de un usuario.
• Búsqueda externa e indirecta: las relaciones hacia y desde los objetos externos, los objetos __x del módulo 4. Una búsqueda externa apunta a un objeto externo padre; una búsqueda indirecta apunta desde un objeto externo hacia un objeto estándar o personalizado, emparejado por un ID externo único.

La mayor parte de tu tiempo de diseño se va en los tres primeros. Veámoslos uno por uno.

Búsqueda: estos registros están conectados

Una búsqueda dice: este registro está asociado a ese registro. El hijo conserva su propia identidad, su propio dueño y su propia vida. Una entrega apunta a su ruta. Si se cancela la ruta, las entregas no desaparecen; vuelven a la cola para asignarles una ruta otra vez.

Tiene su gracia: el campo de búsqueda va en el hijo, pero el padre también recibe algo, una lista relacionada de sus hijos. Así que cuando crees uno, ponle nombre a los dos extremos. La Etiqueta de lista relacionada (Related List Label) es lo que la gente ve en el padre, y el Nombre de relación secundaria (Child Relationship Name) es lo que usan los desarrolladores y las integraciones para ir del padre a los hijos. No aceptes los valores predeterminados.

Una búsqueda puede ser obligatoria u opcional. Cuando es opcional, tú decides qué pasa si se elimina el registro al que apunta, y hay tres opciones (Considerations for Object Relationships (opens in a new tab), en inglés):

• Borrar el valor de este campo (Clear the value of this field), la opción predeterminada. El hijo se queda, con la búsqueda vacía.
• No permitir la eliminación del registro de búsqueda. Intenta eliminar la ruta y Salesforce te dice que no: forma parte de una relación.
• Eliminar también este registro (Delete this record also), una eliminación en cascada, como en una principal-detalle. Solo se ofrece para una búsqueda personalizada en un objeto personalizado, está desactivada de forma predeterminada, y Salesforce tiene que activarla para tu organización, porque una eliminación en cascada se salta la seguridad y el uso compartido: los usuarios pueden eliminar registros que ni siquiera podían ver.

Es una decisión de ciclo de vida escondida en una pantalla de configuración.

Los filtros de búsqueda acotan lo que un usuario puede elegir. Digamos que la Entrega tiene una búsqueda Instalador hacia Contacto, y los instaladores son un tipo de registro de contacto entre muchos. Un filtro de búsqueda muestra solo a los instaladores, y puede filtrar por el registro actual, por el registro que se busca y por el usuario: su perfil, su función o sus permisos (Lookup Filters (opens in a new tab), en inglés). Es una forma barata de mantener honesta una búsqueda.

Principal-detalle: este hijo pertenece a ese padre

La principal-detalle hace una afirmación mucho más fuerte. En clase la llamo un vínculo muy estrecho. No puedes tener un detalle sin su principal; el campo principal es obligatorio. El detalle pierde su propio campo Propietario y hereda el propietario de su padre. No hay una tabla de uso compartido separada para el detalle, así que no puedes compartir un hijo por sí solo; hereda el uso compartido de su padre. Por eso un objeto detalle no puede tener reglas de uso compartido, uso compartido manual ni colas: todos necesitan un campo Propietario (Object Relationships Overview (opens in a new tab), en inglés). En Setup, su configuración de uso compartido dice Controlado por principal (Controlled by Parent). Y en el propio campo principal-detalle eliges una Configuración de uso compartido (Sharing Setting): si un usuario necesita acceso de Solo lectura o de Lectura/Escritura al principal para crear, editar o eliminar sus detalles. Eliminar el principal elimina sus detalles. Y el principal obtiene campos de resumen acumulativo.

Así que si el Artículo de entrega es un detalle de la Entrega, estoy diciendo: este artículo pertenece a esta entrega durante toda su vida. Esa es la pregunta que quiero ver respondida antes de que nadie elija Relación principal-detalle en Setup.

La pregunta de la eliminación

Esta es mi forma favorita de averiguar si lo hemos pensado bien: ¿qué debería pasarles a los hijos si alguien elimina al padre? Todo el mundo se incomoda. Bien. Ahora estamos haciendo arquitectura.

Un socio minorista tiene cientos de miles de entregas históricas. Alguien elimina al socio. ¿Deberían desaparecer las entregas? Casi seguro que no: los reclamos, la facturación y el historial dependen de ellas. Quizá eliminar un socio no debería estar permitido en absoluto, y el socio debería desactivarse. Con principal-detalle, eliminar el principal se propaga en cascada a los detalles y a los detalles de estos; recuperar el principal los trae de vuelta (Considerations for Object Relationships (opens in a new tab), en inglés). Así que cuando alguien dice “la principal-detalle nos da resúmenes acumulativos”, mi respuesta es: genial. ¿Qué más acabas de aceptar?

La propiedad viene incluida en el paquete

Con una búsqueda, el hijo puede tener su propio dueño. Con principal-detalle, no; el acceso sigue al principal. Eso es exactamente lo correcto si el detalle de verdad es parte del padre. Pero si el hijo necesita su propio dueño, su propio uso compartido o su propio ciclo de vida, el modelo te está diciendo que principal-detalle es la elección equivocada. El próximo módulo profundiza en la propiedad, y el curso Sharing and Visibility va todavía más allá. Por ahora: el diseño de las relaciones y el diseño de la seguridad no son conversaciones separadas. El modelo de datos da forma al modelo de seguridad antes de que nadie escriba una regla de uso compartido.

¿Padre obligatorio u opcional?

¿Puede existir el hijo antes de que conozcamos a su padre? Importa más de lo que parece. Si las entregas llegan en el manifiesto la noche anterior y las rutas se arman después, una ruta obligatoria en la entrega significaría que la asignación de rutas tiene que ocurrir antes de que el registro pueda siquiera crearse. La relación física tiene que soportar el ciclo de vida real. Así que no diseño las relaciones solo a partir de un diagrama estático. Quiero saber: ¿cómo nacen, pueden existir solos, pueden moverse y cómo mueren?

¿Puede el hijo cambiar de padre?

De forma predeterminada, un hijo de principal-detalle no puede pasar a otro padre. Puedes permitirlo seleccionando Permitir cambio de principal (Allow reparenting) en la relación (Considerations for Object Relationships (opens in a new tab), en inglés). Mi instinto es conservador: si el negocio dice que el hijo pertenece a un padre de por vida, no hago fácil moverlo. Que un artículo pase de una entrega a otra debería ser un evento de negocio deliberado, no la edición de un campo. Otra vez, la configuración no es la arquitectura. La regla del ciclo de vida lo es, y la configuración la implementa.

Dos cosas más que sorprenden a los equipos más tarde. No puedes crear una relación principal-detalle en un objeto que ya tiene datos; creas una búsqueda, la completas en cada registro y luego la conviertes. Y solo puedes volver a convertirla en búsqueda si no hay campos de resumen acumulativo en el principal. Fíjate también en lo que la conversión le hace a la seguridad: convertir una búsqueda en principal-detalle pone el uso compartido del hijo en Controlado por principal, y volver a convertir una principal-detalle en búsqueda pone el valor predeterminado de toda la organización del hijo en Lectura/Escritura pública (Considerations for Object Relationships (opens in a new tab), en inglés). Registros que ayer eran privados hoy están abiertos, hasta que alguien se da cuenta. Elige pronto.

Los resúmenes acumulativos son útiles, pero no son gratis

Me gustan los resúmenes acumulativos. Contar los artículos de una entrega, sumar los importes de las líneas de una factura, encontrar la fecha más reciente: nativo, sin código. El campo principal-detalle va en el hijo, pero el resumen acumulativo va en el padre. Eso sí, tienen letra pequeña (Roll-Up Summary Field (opens in a new tab), en inglés):

• Calcular los valores de resumen después de ciertos cambios (un campo de resumen nuevo, una fórmula de la que depende que cambia, un recálculo forzado) puede llevar hasta 30 minutos, según cuántos registros se vean afectados. He visto a gente preguntarse por qué el número del padre todavía no ha cambiado.
• No pueden resumirlo todo. Un campo de numeración automática no puede ser el campo que agregas. Y un resumen acumulativo puede resumir un campo de fórmula solo si esa fórmula no llega a otro objeto y no usa una función que cambia por sí sola, como NOW() o TODAY(). Una fórmula de “días de atraso” construida sobre TODAY() cambia cada noche sin que nadie guarde un registro, así que el resumen no tiene a partir de qué recalcular. Ese tipo de número necesita un flujo programado, o un informe.
• El filtro también tiene límites: nada de áreas de texto largo, listas de selección múltiple, Descripción, campos del sistema como Última actividad, fórmulas entre objetos ni campos de búsqueda.
• Los resúmenes acumulativos no están en las páginas de edición, así que una regla de validación puede usar uno, pero no puede mostrar su error ahí.

Y no inviertas la decisión. No digas: “Necesitamos un resumen acumulativo, así que esto tiene que ser principal-detalle”. Di: “Este hijo pertenece de verdad a este padre, la propiedad y el ciclo de vida encajan, y uno de los beneficios son los resúmenes acumulativos nativos”. Si la semántica no encaja, resuelve el cálculo de otra forma. No deformes el modelo de datos para conseguir una función.

Entonces, ¿cuál es la otra forma? Construyes el resumen tú mismo: un campo en el padre que guarda el valor calculado, y una automatización que lo mantiene al día. Digamos que el Socio minorista es una búsqueda desde la Entrega, como debe ser, y el negocio quiere ver las Entregas abiertas en el socio. Agrega un campo numérico, Entregas abiertas, al socio. Luego un flujo desencadenado por registro, o un desencadenador de Apex cuando el volumen o la lógica piden código, lo recalcula cada vez que cambia una entrega. Funciona sobre una búsqueda, puede filtrar por cualquier cosa y puede usar fechas y fórmulas que un resumen nativo no puede.

Pero ahora te toca a ti hacerlo bien, y ahí es donde estos fallan. La automatización tiene que dispararse con cada cambio que importa: un hijo nuevo, un hijo editado, un hijo eliminado, un hijo restaurado y un hijo movido a otro padre, lo que significa recalcular tanto el padre anterior como el nuevo. Tiene que aguantar una carga de datos de 200 registros a la vez sin llegar a los límites. Vuelve a contar en lugar de sumar y restar, para que un solo evento perdido no deje el número mal para siempre. Planea una forma de recalcularlo todo, para la primera carga y para el día en que se desvíe. Y recuerda que ahora cada vez que se guarda un hijo se actualiza el padre, así que un padre con miles de hijos trae de vuelta el bloqueo que veremos en un momento. Un resumen nativo hace todo eso por ti; uno personalizado es una pequeña pieza de software que es tuya.

Tres niveles de profundidad: apilar relaciones principal-detalle

La plataforma tiene una forma, y la principal-detalle tiene dos dimensiones de ella. La primera es la profundidad.

Puedes apilar relaciones principal-detalle hasta tres niveles de detalle personalizados de profundidad, y ahí se acaba (Considerations for Object Relationships (opens in a new tab), en inglés). En clase lo dibujo como una cuenta con un pedido (uno), el pedido con sus artículos (dos) y los artículos con sus detalles (tres), y luego intento agregar un cuarto y Salesforce no me deja. En Steve Trucking podría verse así: una Entrega es el principal; sus Artículos de entrega (Delivery Items) son el primer nivel; las Tareas de instalación (Install Tasks) de un artículo son el segundo; y los Pasos de tarea (Task Steps) de cada tarea son el tercero. Un cuarto nivel, digamos una Nota de paso (Step Note), tiene que ser una búsqueda.

Click to enlarge

Con la pila vienen algunas reglas:

• Los objetos estándar no pueden estar del lado detalle de un objeto personalizado. Un objeto personalizado puede ser detalle de Cuenta; Cuenta no puede ser detalle del tuyo.
• Un objeto solo puede aparecer una vez en una pila de varios niveles. Salesforce no quiere que vuelvas sobre ti mismo: un subdetalle no puede ser también el principal de su propio principal.
• El principal no puede resumir directamente el nivel más bajo. Si la Entrega quiere el número de Pasos de tarea, la Tarea de instalación resume sus pasos, el Artículo de entrega resume esos resúmenes y la Entrega resume los artículos: un nivel a la vez.
• La propiedad y el uso compartido vienen de arriba. Cada nivel hereda el propietario y el acceso del principal.
• Eliminar el principal elimina todo lo que tiene debajo, y restaurarlo lo trae todo de vuelta.

Tres niveles suelen ser más que suficientes. Si tu diseño sigue pidiendo un cuarto, pregúntate si cada nivel pertenece de verdad, de por vida, al que tiene encima. Y recuerda que tú eliges qué vínculo rompe la cadena. El cuarto nivel no tiene por qué ser la búsqueda: quizá una Tarea de instalación no pertenece de verdad a su Artículo de entrega, se programa y se asigna por su cuenta, así que ese vínculo pasa a ser una búsqueda, y ahora la Tarea de instalación empieza una cadena nueva con el Paso de tarea y la Nota de paso debajo. Elige el vínculo donde el hijo tiene de verdad vida propia, y haz que ese sea la búsqueda.

Click to enlarge

Ahora la Tarea de instalación tiene su propio propietario y su propio uso compartido, una entrega se puede eliminar sin llevarse sus tareas de instalación, y la Tarea de instalación puede tener dos niveles más debajo. Ese es el intercambio: la cadena es más corta, y la vida de la tarea de instalación es suya.

Dos padres de ancho: el objeto de unión de Salesforce

Primero, unas palabras sobre las palabras, porque “objeto de unión” significa dos cosas, y enseño las dos.

En el capítulo 2 encontramos el objeto de unión lógico: la unión de dos ideas clave que se convierte en una cosa propia, con sus propios atributos. Un perro sabe muchos trucos, un truco lo saben muchos perros, y Truco del perro se sienta entre ellos guardando el nivel de habilidad y la fecha. Eso es un objeto de unión lógico, en el modelo lógico, mucho antes de que nadie decida entre búsqueda o principal-detalle.

Salesforce usa el término de forma más estrecha. Cuando Salesforce dice objeto de unión, se refiere a un objeto personalizado con dos relaciones principal-detalle (Create a Many-to-Many Object Relationship (opens in a new tab), en inglés). A eso lo llamaré objeto de unión de Salesforce (Salesforce Junction Object). Todo objeto de unión de Salesforce es un objeto de unión lógico, pero no todo objeto de unión lógico se convierte en un objeto de unión de Salesforce: constrúyelo con una principal-detalle y una búsqueda, o con dos búsquedas, y sigue siendo un objeto de unión lógico, solo que no del tipo de Salesforce. (Salesforce tampoco es del todo consistente: su propia referencia de objetos llama “objetos de unión” a algunos objetos estándar construidos sobre búsquedas. En el examen, asume la definición estrecha).

Conocimiento para el examen. Un objeto de unión de Salesforce es un objeto personalizado con dos relaciones principal-detalle, y eso es lo que Salesforce quiere decir cuando dice “objeto de unión”. El objeto de unión lógico es la idea de modelado más amplia: cualquier objeto que une a otros dos en una relación de muchos a muchos y lleva sus propios atributos, se construya como se construya.

La segunda dimensión es el ancho. ¿Puede un hijo tener dos padres principal-detalle? Sí. ¿Tres? No. Cada objeto personalizado puede tener hasta dos relaciones principal-detalle (Considerations for Object Relationships (opens in a new tab), en inglés). Dos padres principal-detalle es como construyes un objeto de unión de Salesforce para una relación de muchos a muchos. El equipo y el camión se encuentran en una Asignación de equipo, y como descubrimos en el capítulo 2, no es fontanería: tiene una fecha, una ruta, quizá un estado. El objeto de unión es donde la relación se convierte en un concepto de negocio. Los consejos de Salesforce para construir uno: dale un nombre que diga lo que es, haz que el nombre de su registro sea de numeración automática, y cambia el nombre de la lista relacionada de cada principal por el del otro principal, para que la página del equipo muestre “Camiones” y la del camión muestre “Equipos” (Create a Many-to-Many Object Relationship (opens in a new tab), en inglés).

Aquí está lo intrincado. Uno de los dos padres es el primario, y es aquel cuyo campo principal-detalle creaste primero. No hay ninguna indicación visual de cuál es, así que es una pregunta clásica de examen, y una sorpresa clásica.

¿Qué decide el primario? Tres cosas (Create a Many-to-Many Object Relationship (opens in a new tab), en inglés):

• El aspecto. Las páginas del objeto de unión usan el color y el icono del principal primario.
• El propietario. Los registros del objeto de unión heredan el propietario del registro principal primario. Nunca lo ves, porque un detalle no tiene campo Propietario; solo importa si más adelante eliminas las dos relaciones principal-detalle.
• La división, si tu organización usa divisiones, de la misma manera.

Y el otro es el secundario. ¿Qué significa?

• Es el siguiente en la fila para ser primario. Elimina el campo principal-detalle primario o conviértelo en búsqueda, y el secundario pasa a ser el primario.
• Define el alcance de los informes. Salesforce te da dos tipos de informe: “Primary master with junction object and secondary master” y “Secondary master with junction object and primary master”. El principal que aparece primero decide qué registros puede mostrar el informe.
• Cuenta igual para el acceso. Así lo digo yo: la propiedad viene del primario, el acceso de los dos, y gana el más restrictivo. Un objeto de unión, como cualquier detalle, no tiene tabla de uso compartido propia. Salesforce comprueba el acceso del usuario a los dos registros principales, mediante la Configuración de uso compartido de cada campo principal-detalle. Si las dos están en Lectura/Escritura, el usuario necesita Lectura/Escritura en el equipo y en el camión para editar la Asignación de equipo (Considerations for Object Relationships (opens in a new tab), en inglés).
• Elimina igual. Elimina cualquiera de los dos principales, el equipo o el camión, y sus registros de unión van a la Papelera de reciclaje. Elimina los dos y desaparecen para siempre.

Click to enlarge

Algunas reglas más: los dos principales pueden tener resúmenes acumulativos del objeto de unión, y las fórmulas y reglas de validación del objeto de unión pueden llegar a campos de los dos. Pero un objeto de unión no puede ser el principal de nada más, así que no puede estar en medio de una pila, y los dos principales no pueden ser el mismo objeto; una relación de muchos a muchos de un objeto consigo mismo necesita otro diseño. Y si un padre tiene más de 200 registros de unión y el objeto de unión hace un resumen acumulativo hacia el otro padre, Salesforce no te deja eliminar ese padre hasta que hayas quitado suficientes.

Entonces, ¿qué padre debería ser el primario? Crea primero el que es dueño del significado. Para una Asignación de equipo, el equipo es el que hace el trabajo, así que yo crearía primero Equipo. Y luego déjalo por escrito, porque nada en la pantalla se lo va a decir a la próxima persona.

Dicho todo esto, no acabo teniendo muchos objetos de unión de Salesforce. Normalmente un objeto tiene un padre principal-detalle, y es el mismo tipo de datos: datos de clientes bajo datos de clientes, transaccionales bajo transaccionales (recuerda los tipos de datos del capítulo 2: de clientes, transaccionales, de referencia). Cuando su otro padre es de otro tipo, normalmente un objeto de referencia, esa relación es una búsqueda. Un Artículo de entrega pertenece a su Entrega: principal-detalle, los dos transaccionales. Apunta al Producto que lleva con una búsqueda, porque un producto son datos de referencia con vida propia, y nadie quiere que eliminar un producto se lleve consigo años de historial de entregas. El Artículo de entrega sigue siendo un objeto de unión lógico entre una entrega y los productos que lleva; solo que no es un objeto de unión de Salesforce.

Autorrelaciones: cuando la línea vuelve

Un objeto puede relacionarse consigo mismo: una cuenta principal, un gerente, un centro de distribución que depende de un centro regional. Salesforce trae dos integradas que vas a encontrar en casi todas las organizaciones: Cuenta a Cuenta, el campo Cuenta principal que construye la jerarquía de cuentas, y Caso a Caso, el Caso principal del módulo 2 que agrupa casos relacionados. Una autorrelación tiene que ser una búsqueda, y un registro no puede apuntarse a sí mismo, aunque dos registros sí pueden apuntarse el uno al otro (Considerations for Object Relationships (opens in a new tab), en inglés). En el objeto Usuario es un tipo especial propio, la relación jerárquica, que se usa para cosas como el gerente de un usuario. La mecánica es fácil; el nombre importa. Una búsqueda de Centro de distribución a Centro de distribución llamada Distribution_Center__c no ayuda a nadie. ¿Padre? ¿Respaldo? ¿Desborde? Nombra la relación por el rol, no por el objeto al que apunta.

Click to enlarge

Jerárquica: la relación propia del objeto Usuario

Esta es pequeña, y es exactamente el tipo de dato poco conocido y único en su clase que esperaría que apareciera en un examen. La relación jerárquica es una búsqueda especial que existe solo en el objeto Usuario. Vincula a un usuario con otro usuario, y Salesforce no deja que la cadena dé la vuelta: un usuario no puede apuntarse a sí mismo, ni directa ni indirectamente (Object Relationships Overview (opens in a new tab), en inglés). Si el gerente de María es Dev, el gerente de Dev no puede ser María, ni nadie que dependa de María.

Esa es la diferencia con las autorrelaciones de arriba. En Cuenta o en un objeto personalizado, dos registros pueden apuntarse el uno al otro. En Usuario, la jerarquía tiene que seguir siendo una jerarquía. Y es la única forma de relacionar Usuario con Usuario: no se ofrece una búsqueda normal de Usuario hacia sí mismo.

Ya tienes una. El campo estándar Gerente (Manager) de Usuario es una relación jerárquica, y las aprobaciones pueden usarlo: envía esta solicitud al gerente de quien la presenta. También puedes crear las tuyas, digamos un Contacto de escalamiento o un Aprobador suplente, y una aprobación puede seguirlas de la misma manera (ApprovalProcess, Metadata API (opens in a new tab), en inglés). No la confundas con la jerarquía de funciones, que determina el acceso a los registros. Un campo jerárquico es solo una relación entre usuarios; no comparte ni un solo registro.

Conocimiento para el examen. La relación jerárquica existe solo en el objeto Usuario, como el campo estándar Gerente, y un usuario no puede apuntarse a sí mismo, ni directa ni indirectamente. No es la jerarquía de funciones.

Las relaciones también tienen límites

Cada objeto puede tener como máximo dos relaciones principal-detalle. Los campos de búsqueda y de principal-detalle juntos cuentan como campos de relación: 40 por objeto de forma predeterminada, 50 como máximo si se solicita. Campos de resumen acumulativo: 25 por objeto de forma predeterminada, 40 como máximo (Increase the Maximum Relationships Allowed per Object (opens in a new tab); Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab), en inglés). Salesforce agrega que subir cualquiera de los dos límites puede afectar el rendimiento.

No necesitas diseñar en función de esos números; necesitas darte cuenta cuando estás cerca de ellos. Un objeto del que cuelga relación tras relación te está diciendo algo. Quizá de verdad es así de central. O quizá el modelo está mal. (Y aplica la regla del margen del capítulo 18: quédate muy por debajo de un límite, medido contra el tercer año.)

La pregunta de los 10.000 hijos

Luego está el padre con demasiados hijos. La propia recomendación de Salesforce es no superar unos 10.000 registros hijos por cada padre de principal-detalle (Considerations for Object Relationships (opens in a new tab), en inglés), y su guía de acceso a registros a escala dice lo mismo de las relaciones padre-hijo en general (Parent-Child Data Skew (opens in a new tab), en inglés). El registro 10.001 no rompe la organización. Pero pasado ese punto, guardar un hijo puede bloquear al padre, y los cambios de uso compartido en el padre repercuten en cada hijo.

Así que cuando veo un padre con una cantidad enorme de hijos, pregunto: ¿por qué están todos bajo el mismo padre, quién es su dueño, cómo se consultan y qué automatización toca al padre? Todas las entregas bajo una sola cuenta “Steve Trucking” pasarían de 10.000 en pocos días. Una relación de uno a muchos inocente se convierte en un problema de sesgo (skew). El próximo módulo adelanta el sesgo, y la Parte 2 lo trata a fondo.

No diseñes la línea por la función

Este es el hábito que quiero de este módulo. No empieces por “necesito un resumen acumulativo”, “necesito que sea obligatorio”, “quiero uso compartido heredado”. Son pistas de implementación. Empieza por el negocio: ¿el hijo tiene vida propia, quién es su dueño, puede existir solo, puede moverse, qué pasa cuando el padre desaparece, la relación lleva datos y qué tan grande puede llegar a ser cada lado? Luego elige la relación que implementa las respuestas.

Click to enlarge

Más allá del examen: lo que cambia la IA. La IA puede proponer relaciones en segundos. No puede decirte si el negocio eliminará alguna vez al padre. Diagramar más rápido no hace más barato revertir una relación equivocada una vez que millones de registros y decenas de automatizaciones dependen de ella.

Lo que decide aquí un arquitecto

• Si el hijo tiene su propio ciclo de vida o pertenece de verdad al padre, y si la propiedad y el acceso deberían ser propios o heredados.
• Si el hijo puede existir sin un padre, moverse entre padres o sobrevivir a la eliminación del padre.
• Qué hace cada búsqueda cuando se elimina su padre: vaciar, bloquear o eliminar en cascada.
• Si una relación de muchos a muchos es fontanería o un concepto de negocio, si el objeto de unión lógico se convierte en un objeto de unión de Salesforce, qué padre es el primario y qué significan los dos padres para el acceso.
• Si el modelo encaja con la forma de la plataforma: tres niveles de detalle personalizados de profundidad, dos padres principal-detalle de ancho, los límites de relaciones y de resúmenes acumulativos.
• Si la cantidad y la distribución esperadas de hijos crean un riesgo de sesgo que debería cambiar el diseño.

Una relación es un conjunto de promesas sobre cómo se comportan juntos dos datos. Hazlas de forma deliberada.

Explora

• Ayuda de Salesforce, Considerations for Object Relationships (opens in a new tab) (en inglés), consultado el 2026-10-13.
• Ayuda de Salesforce, Object Relationships Overview (opens in a new tab) y Create a Many-to-Many Object Relationship (opens in a new tab) (en inglés), consultado el 2026-10-13.
• Ayuda de Salesforce, Roll-Up Summary Field (opens in a new tab) (en inglés), consultado el 2026-10-13.
• Salesforce Developers, Metadata API, ApprovalProcess (opens in a new tab) (en inglés), consultado el 2026-10-13.
• Ayuda de Salesforce, Lookup Filters (opens in a new tab) (en inglés), consultado el 2026-10-13.
• Ayuda de Salesforce, Increase the Maximum Relationships Allowed per Object (opens in a new tab) y Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab) (en inglés), consultado el 2026-10-02.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (opens in a new tab) (en inglés), consultado el 2026-10-02.