Objeto Lookup o Junction: Guía de decisiones para arquitectos de Salesforce

En el trabajo diario de los arquitectos y analistas de negocio de Salesforce, algunos requisitos parecen muy claros y la decisión de crear un Lookup a otro objeto se toma rápidamente. Sin embargo, hay ocasiones en las que puede merecer la pena explorar el proceso y la configuración empresarial en torno al requisito un poco más a fondo antes de incurrir en refactorizaciones técnicas y migraciones que requieren mucho tiempo, ya que pueden afectar significativamente a la experiencia del usuario, la disponibilidad del sistema y los costes de mantenimiento;

En este artículo, presento una guía de decisión basada en tres simples preguntas para reducir el riesgo de pensar demasiado pequeño con un Lookup, o demasiado grande con un Junction Object.

Tipos de relación en Salesforce

Cuando dos entidades necesitan relacionarse entre sí, en arquitectura técnica podemos hacer uso principalmente de dos soluciones: 

• Lookup: Representa una relación de uno a muchos
• Objeto de unión: Representa una relación de muchos a muchos

Para simplificar, no cubriremos las relaciones jerárquicas padre-hijo o maestro-detalle.

Relación Lookup

La relación Lookup se crea añadiendo un campo personalizado al objeto que será el «muchos» en la relación uno a muchos y apuntará a la entidad «uno», que tendrá el enlace entrante.

En la captura de pantalla anterior, hemos añadido un campo personalizado llamado «Order» como Lookup en el objeto asset. Observe cómo también podemos definir la «fuerza» de la relación especificando qué sucede si se elimina el registro Lookup. ¿Puede existir un activo sin el pedido conectado?

Volviendo a la definición de la relación Lookup: En este ejemplo, un activo está conectado exactamente a un pedido y un pedido está conectado al menos a un activo. Un activo podría ser la representación «física» de un producto (por ejemplo, un ordenador portátil específico, con un número de serie);

Vamos a un ejemplo práctico. El pedido forma parte de un proceso de compra, durante el cual se adquiere un producto genérico «Portátil de empresa» y, a continuación, se vincula un bien específico a dicho pedido. Si luego nos fijamos en el portátil específico, podemos rastrearlo hasta el pedido de compra. Obviamente, en este caso, un pedido puede referirse a muchos activos. Un cliente puede haber pedido también un ratón y un teclado;

Pista: Los ejemplos de ERD (Entity Relationship-Diagram) utilizan la notación de pata de gallo, que puede resultar difícil para los interesados no técnicos. La notación Chen podría ser una opción más fácil o simplemente anotar la relación con explicaciones sencillas.

Objeto de unión

La relación many-to-many se crea añadiendo un Junction Object que conecta «n» activos con «m» pedidos.

Para el Junction Object, hemos creado un Custom Object llamado «Asset Order», que contiene dos Lookups, uno al activo y otro al pedido. Así se crea cada vínculo entre un activo y un pedido. Esta relación muchos-a-muchos se puede comprobar visualmente en el «Schema Builder»:

Si un activo puede tener más de un pedido conectado (venta inicial, devolución, segunda venta), podríamos volver al ejemplo con el portátil concreto que ha pedido un cliente. Otros pedidos relacionados con ese bien podrían, por ejemplo, ser el resultado de procesos de devolución (el cliente quiere devolver el artículo) o el vendedor ofrece recomprar el artículo, lo reacondiciona y lo vuelve a vender como artículo de segunda mano 

En ese caso, la multitud de órdenes se pueden rastrear en el activo específico, como podemos ver en la siguiente captura de pantalla que muestra un activo en particular y diferentes órdenes de su ciclo de vida.

Un ejemplo existente en Salesforce: Miembros de campaña

Un gran ejemplo para entender un Junction Object, y la relación many-to-many es echando un vistazo a Campaign Members.

Una Campaña puede estar conectada a múltiples Contactos:

Un Contacto puede ser objetivo de diferentes Campañas:

Análisis del proceso de negocio y escenario

Pongamos los ejemplos anteriores en el contexto adecuado. Un analista de negocio y un arquitecto están trabajando en el traspaso entre el proceso de pedido y el de cobro de un cliente de comercio electrónico. Lead-to-order es el proceso que abarca la cualificación, nutrición y conversión de un lead en un pedido, mientras que el order-to-cash está relacionado con todas las actividades que siguen desde un pedido ganado hasta la entrega y el pago.

En el «borde» entre los dos procesos, los artículos genéricos (productos) que un cliente ha seleccionado, como parte de su carrito, están vinculados con artículos específicos que están en stock (activos).

El analista de negocio y el arquitecto entrevistan a su principal parte interesada en el proceso de pedido de clientes potenciales, que es el departamento de marketing online. En sus requisitos, cada producto está vinculado a un pedido (que ya se cumple con el producto de pedido estándar). A partir de ahí, pueden realizar análisis específicos y obtener información sobre las tasas de conversión y otros KPI relevantes. El producto y el activo están estrechamente conectados, por lo que el activo también está modelado para estar en una relación de uno a muchos con el pedido, mediante el uso de un Lookup.

Incorporación de las siguientes partes interesadas

Un par de meses después, el siguiente departamento se incorpora a Salesforce. Este departamento está dirigido por el director de operaciones y se centra en las operaciones. Los temas principales que deben conseguirse con Salesforce son el proceso logístico de devoluciones y la obtención de ingresos adicionales con negocios renovados. Tras entrevistar a los gestores de procesos, el analista de negocio y el arquitecto descubrieron que la relación de entidades existente era incompatible con los nuevos requisitos: pedidos de devolución y reventa de activos existentes;

Necesitan crear una relación de muchos a muchos entre pedidos y activos, así como introducir diferentes tipos de pedidos. Esto no sólo conduce a una situación en la que un proceso ya en marcha tiene que ser cambiado, sino también a una cuidadosamente planificada «in-situ-migración» de los datos existentes en el nuevo Junction Object (por no hablar de la modificación de los informes existentes y la re-formación de los usuarios finales).

Guía de decisión de 3 preguntas

No todos los requisitos empresariales pueden preverse y, a veces, una solución pragmática hoy puede ser mejor que una solución «perfecta» dentro de tres meses. Pero aumentar la posibilidad de reconocer la necesidad de un enfoque diferente al obvio, puede lograrse con tres simples preguntas.

<h3 class="wp-block-heading" id="h-¿Cómo-es-el-ciclo-de-vida-de-las-entidades-pertinentes?

¿Cómo es el ciclo de vida de las entidades pertinentes?

Esta pregunta no está relacionada con el objeto de Salesforce en sí, sino con la entidad como parte de un conjunto de procesos empresariales. No es necesario mapear el proceso central del cliente en varios niveles, pero tener una comprensión general del proceso de extremo a extremo, especialmente el que está siendo soportado por Salesforce y aquellos que interactúan, es crucial;

Para esta pregunta, el analista de negocio pregunta a varias partes interesadas sobre los diferentes estados por los que puede pasar la entidad, hoy y en un futuro próximo. Aquí, es importante separar entre requisitos «reales» y «deseos remotos» que podrían ser menos relevantes y conducir a soluciones de sobreingeniería. Al preguntar al director de operaciones sobre los activos, el analista de negocio habría descubierto que un activo no «termina» tras el proceso de pedido a cobro, sino que es necesario en los procesos de emisión a resolución y recompra a reacondicionamiento.

¿Qué requisitos de negocio soportaría una solución diferente?

El objetivo de esta pregunta es realizar ingeniería inversa de una solución en posibles requisitos. ¿Qué pasaría si en lugar de utilizar un Lookup, utilizáramos un Junction Object? ¿Qué sería posible? ¿En qué casos se vincularía un activo a varios pedidos? Las respuestas teóricas a estas preguntas pueden cuestionarse con las partes interesadas y utilizarse para comprobar si coinciden con los requisitos empresariales reales.

Esta pregunta también puede aplicarse a implementaciones no relacionadas con Lookups y Junction Objects, ya que proporciona un buen campo de pruebas para un análisis amplio.

¿Cuál es el impacto, si nuestra solución necesita adaptarse?

Este enfoque acepta el hecho de que una solución no siempre puede satisfacer el 100% de los requisitos actuales o futuros. Permite al arquitecto crear un plan de contingencia y comunicárselo al cliente de forma abierta. «Si tenemos que cambiar de un Lookup a un Junction Object porque se descubren o cambian nuevos requisitos, este es el impacto y este es el plan…» La respuesta a esta pregunta también muestra el posible coste de una solución frente a otra y ayuda al equipo a estar preparado de antemano y tomar decisiones informadas.

Al igual que en el caso de la segunda pregunta, este análisis de impacto puede adaptarse para ser utilizado en varias implementaciones, ya que ayuda a planificar contingencias.

Resumen

El diseño de una arquitectura sólida en Salesforce se basa siempre en el análisis de los requisitos empresariales y sus respectivos procesos. Mediante la formulación de tres sencillas preguntas que se muestran en esta guía, un equipo puede reducir el riesgo derivado de requisitos desconocidos o no identificados que podrían dar lugar a cambios, refactorizaciones y migraciones.

1. Ciclo de vida: ¿Cómo es el ciclo de vida de las entidades relevantes?
3. Requisitos de ingeniería inversa: ¿Qué requisitos empresariales soportaría una solución diferente?
4. Impacto de las alternativas: ¿Cuál es el impacto si nuestra solución necesita ser adaptada?