Diseña el modelo físico de Salesforce

🌐 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 10 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: Mantener los datos consistentes · Siguiente: la guía de estudio del capítulo y luego el próximo capítulo, Entender los datos de la empresa

La pregunta que responde este módulo: ¿Cómo convertimos nuestro modelo lógico en una arquitectura de Salesforce?

Este capítulo ha sido un largo argumento de que la plataforma tiene una forma: objetos estándar y personalizados, lugares donde pueden vivir los datos, tipos de campo, relaciones, propiedad, licencias, reglas de consistencia, almacenamiento y escala. Cada uno puede cambiar cómo se construye el modelo lógico del capítulo 2. Ahora juntémoslo en una porción de Steve Trucking.

Una porción, no toda la empresa. Un error que veo cometer a los arquitectos es intentar resolver toda la empresa en un solo diagrama. Quiero algo sobre lo que podamos razonar: un socio minorista envía un manifiesto, Steve Trucking entrega lo que hay en él, y conservamos lo que necesitamos de cada entrega. Luego tomamos las decisiones físicas de una en una. El diseño completo es el punto de control de la Parte 1.

Empieza por lo que ya sabemos

El capítulo 2 hizo el trabajo conceptual: Socio minorista, Destinatario, Manifiesto, Entrega, Artículo de entrega, el tipo de parada, Equipo, Camión, Centro de distribución, fotos. Pusimos nombre a las relaciones y preguntamos qué significan. No lo voy a repetir. La pregunta ahora es cómo viven esos conceptos en Salesforce. Un dato del planteamiento importa de inmediato: Steve Trucking ya usa Field Service para las citas, los equipos y la aplicación móvil.

Socio minorista: no inventes una cuenta

Un socio minorista es una empresa para la que trabaja Steve Trucking. Salesforce ya tiene un objeto diseñado para empresas: la cuenta (Account). Ajuste limpio. Así que nada de Retail_Partner__c solo porque el negocio dice “socio”. Es una cuenta, con un tipo de registro Socio minorista para distinguirla de otras organizaciones, y con ella vienen los contratos, los casos, los contactos para los gerentes de los centros de distribución y el acceso al portal para esos contactos. Decisión fácil. No todas lo son.

El número de pedido del socio no es nuestra identidad

Cada socio minorista envía sus propias referencias. El pedido de un socio se ve como 8843119, el de otro como A-984732. Esos números importan, pero ¿de quién son? Del socio. Salesforce tiene su propio ID de registro, y el socio tiene la referencia que usa cuando habla con nosotros. Pueden existir ambos; es el “una cosa, varios identificadores” del capítulo 2.

Así que la referencia del socio se convierte en un ID externo que la integración usa para emparejar las actualizaciones. Y como dos socios podrían usar el mismo número, la identidad es el socio más la referencia, no la referencia sola. No hagas del número de un socio la identidad universal de la entrega porque llegó primero, y no hagas que una integración busque en un campo de texto cada vez que necesita encontrar un registro.

Entrega: mira a la nave nodriza

Aquí es donde tienta crear Delivery__c. El negocio dijo “entrega”, así que necesitamos un objeto Entrega. Eso es exactamente lo que no quiero que hagas primero. Mira a la nave nodriza, como hicimos en el módulo 2. ¿Qué tiene ya Salesforce para un trabajo que se realiza en un lugar, con un ciclo de vida, artículos, programación y un equipo en campo? La orden de trabajo (Work Order) de Field Service: Salesforce la describe como trabajo de servicio de campo que se realiza para un cliente (WorkOrder (opens in a new tab), en inglés). La visita programada y su franja horaria es la cita de servicio (Service Appointment), y eso es lo que programa el despacho y lo que muestra la aplicación del equipo.

Así que Entrega → orden de trabajo. No porque las palabras coincidan; no coinciden. Porque el comportamiento coincide con la capacidad de la plataforma que ya estamos pagando y que pensamos usar. Un objeto estándar no tiene que compartir el vocabulario del negocio. Tiene que representar correctamente el concepto.

Click to enlarge

Paso 1 de 4: la nave nodriza. Cada tarjeta es el concepto de negocio, con su objeto de Salesforce debajo.

Pero los objetos estándar vienen con equipaje

La otra mitad: la orden de trabajo no es gratis. Trae las licencias de Field Service, sus propias relaciones, comportamiento de seguridad, campos obligatorios, automatización y ciclo de vida, y otras partes de la plataforma esperan que se comporte de cierta manera. La elegimos porque el ajuste es limpio y porque usamos lo que está construido a su alrededor. Si Steve Trucking no quisiera nada de Field Service y el modelo se peleara con el proceso a cada paso, lo reconsideraría. La arquitectura es el ajuste, no la etiqueta.

Artículos de entrega: sigue el modelo

Una vez que la entrega es una orden de trabajo, mira el resto de ese modelo antes de inventar nada. Una partida de orden de trabajo (Work Order Line Item) es una subtarea de una orden de trabajo (WorkOrderLineItem (opens in a new tab), en inglés): el refrigerador, la instalación, el retiro del aparato viejo. Así que Artículo de entrega → partida de orden de trabajo. Fíjate en que la primera decisión dio forma a la segunda. No estamos eligiendo un objeto para cada entidad por separado. Adopta un modelo, y entiende el resto de él antes de construir estructuras personalizadas a su alrededor.

¿Qué tipo de parada es esta?

En Steve Trucking una parada es solo entrega, entrega con instalación o entrega con retiro del aparato viejo, y cada tipo tiene su propia duración, sus habilidades del equipo y su lista de verificación de instalación. En el capítulo 2 decidimos que eso es una entidad, no una etiqueta. Field Service ya tiene una: el tipo de trabajo (Work Type), una plantilla para un tipo de trabajo que se puede aplicar a órdenes de trabajo y partidas (WorkType (opens in a new tab), en inglés). Así que Tipo de parada → tipo de trabajo. Otra vez, no porque exista algo llamado tipo de trabajo, sino porque el concepto y el comportamiento coinciden.

Click to enlarge

Paso 2 de 4: sigue el modelo. Las partidas y el tipo de trabajo vienen con la orden de trabajo.

Manifiesto: ahora sí quiero un objeto personalizado

¿Hay un objeto estándar para “la lista del socio para el martes en el centro de distribución de Phoenix”? En realidad no, y no voy a forzarlo dentro de un objeto sin relación solo para decir que nos quedamos en lo estándar. Manifiesto → Manifest__c. Es la unidad de recepción: de dónde vino (un archivo, un lote de la API), cuándo, su estado y sus totales y, cuando un socio lo reenvía el mismo día, qué se compara. Cada línea del manifiesto se convierte en una orden de trabajo vinculada a él.

Lo personalizado no es un fracaso. Es lo que nos da la plataforma cuando un concepto no tiene un hogar estándar limpio. El error no es crear un objeto personalizado; es crearlo sin comprobar si la plataforma ya tiene el concepto.

Click to enlarge

Paso 3 de 4: el único objeto personalizado, donde ningún objeto estándar encaja.

Fotos: que Salesforce pueda guardarlas no significa que deba

“Necesitamos las fotos de las entregas en Salesforce”. ¿Qué significa “en Salesforce”? Los usuarios necesitan verlas desde Salesforce, sí. ¿Eso significa que los archivos de imagen tienen que vivir en el almacenamiento del núcleo? No necesariamente. Cuenta los ceros: unas cuatro fotos por entrega, más con las instalaciones, con un millón de entregas al año, son de cuatro a cinco millones de fotos al año, y las entregas crecen un 30 % anual.

Así que mi posición de partida: no conviertas la organización principal en un repositorio gigante de fotos porque los usuarios necesitan acceder a las fotos. Los archivos pertenecen a un almacenamiento construido para ese volumen, fuera del núcleo, y Salesforce conserva lo que necesita para encontrarlas y mostrarlas: una referencia, un recuento o un pequeño registro de índice por foto, y un indicador de que las fotos obligatorias de la instalación están completas. Acceder a los datos y dónde viven físicamente los datos son dos preguntas distintas. Es el módulo 4 que vuelve.

Campos: haz visible el significado

La orden de trabajo necesita campos: la referencia del socio, la franja de entrega, la hora real de entrega, el estado, notas como “código del portón” o “perro en el patio”. No voy a convertir esto en un catálogo de campos; eso lo hizo el módulo 6. Haz las preguntas para cada uno: qué significa, quién es su dueño, si cambia, si es un identificador, un vocabulario controlado, guardado o derivado, sensible. La referencia del socio es el ID externo, así que su unicidad es parte del contrato de integración, no solo una casilla. La hora real de entrega es un momento, así que Fecha/hora. El estado determina el comportamiento, así que una lista controlada, nunca texto libre. Y las notas de entrega sobre la casa de una persona son datos personales, así que se clasifican. Cada campo se rastrea hasta su significado.

Relaciones: no te limites a conectar las cajas

Cuenta a orden de trabajo, orden de trabajo a sus partidas, Manifiesto a orden de trabajo, tipo de trabajo describiendo la parada. Luego las preguntas del módulo 7 para cada línea: ¿puede existir solo el hijo, quién es su dueño, el acceso se hereda, puede moverse, qué pasa al eliminar, cuántos hijos pueden acumularse? Cada orden de trabajo bajo un puñado de cuentas de socios minoristas significa cientos de miles de hijos por padre: una cuestión de sesgo que responderemos en la Parte 2. Y para las relaciones estándar de Field Service, comprueba cómo las construyó ya Salesforce en lugar de suponer que coinciden con lo que nosotros habríamos diseñado. Cuando adoptas un modelo estándar, adoptas las decisiones que Salesforce tomó dentro de él. Entiéndelas antes de construir encima.

La propiedad y el destinatario: no dejes que decida el valor predeterminado

Dos decisiones que un valor predeterminado tomaría por nosotros con mucho gusto.

¿Quién es dueño de una entrega? Lo respondimos en el módulo 8, y se traslada directamente a la orden de trabajo: aquí la propiedad no determina el acceso de nadie, así que el usuario de integración es dueño de las órdenes de trabajo que crea. Los despachadores ven las de su centro de distribución, los equipos las de sus rutas y cada socio minorista las suyas a través del portal, todo mediante el uso compartido, no la propiedad. El usuario de integración no tiene función y se queda fuera de los grupos públicos que usan nuestras reglas de uso compartido, porque con 3.300 al día pasa de 10.000 registros en tres días. Y dejamos por escrito qué pasa si algún día se reemplaza ese usuario.

¿Qué es el destinatario? ¿Un contacto? ¿Una cuenta personal? ¿Algo que se guarda solo en la entrega? Depende de si Steve Trucking tiene siquiera una relación con estas personas (son clientes de los socios minoristas), de si un socio podría ver alguna vez los de otro, de cuánto tiempo se pueden conservar sus datos personales, y de la escala: alrededor de un millón de destinatarios nuevos al año. Todavía no tenemos todo eso, y está bien. A veces la respuesta correcta es todavía no sabemos lo suficiente. Anota la pregunta y ve a buscar la información; no entierres la incertidumbre en un objeto personalizado. Lo respondemos en el checkpoint de la Parte 1, después de que los capítulos 4 a 6 nos den el panorama de la empresa y de los datos maestros.

Consistencia: protege el modelo en la capa correcta

Se aplica la escalera del módulo 9: la referencia del socio es un ID externo, único, así que un manifiesto reenviado hace upsert en lugar de duplicar; el estado es una lista restringida; la hora real de entrega solo es obligatoria una vez que el estado dice Entregada; una parada de instalación no puede cerrarse sin su lista de verificación y sus fotos. No un flujo gigante. Cada regla en su propio peldaño.

Dónde vive cada pieza

Una pasada más sobre la porción, con la pregunta del módulo 4: ¿dónde vive cada dato? En mi presentación de clase es una sola diapositiva, lógico frente a físico: las entidades lógicas del capítulo 2 y dónde aterriza físicamente cada una: en el núcleo, como sObject (__c si es personalizado) o como objeto grande (big object, __b), o fuera del núcleo, como objeto externo (__x) o como datos que nunca entran en Salesforce.

• En el núcleo, con trabajo diario: la cuenta, las órdenes de trabajo y sus partidas, las citas de servicio, los tipos de trabajo, Manifest__c.
• En el núcleo, archivado: las entregas de más de tres años pasan a Historial de entregas (Delivery History), un objeto grande; siguen ahí para los reclamos, en el cobertizo del fondo.
• Referenciado: los detalles del pedido del propio socio minorista se quedan en el sistema del socio; guardamos la referencia del socio como ID externo y llegamos al resto mediante un objeto externo o la integración cuando alguien lo necesita.
• Fuera del núcleo: las fotos, en un almacenamiento construido para millones de imágenes, con un enlace desde la orden de trabajo.

Eso es el modelo físico: no solo qué objeto, sino qué hogar.

Ahora mira la porción completa

• Socio minorista → cuenta, con un tipo de registro Socio minorista; los gerentes de los centros de distribución como contactos.
• Entrega → orden de trabajo de Field Service, programada mediante una cita de servicio.
• Artículo de entrega → partida de orden de trabajo.
• Tipo de parada → tipo de trabajo.
• Manifiesto → Manifest__c personalizado.
• Referencia del socio → ID externo en la orden de trabajo, único por socio.
• Fotos → guardadas fuera del núcleo; Salesforce conserva la referencia y el indicador de que están completas.
• Historial de entregas → archivado en un objeto grande después de tres años.
• Propiedad → el usuario de integración, con el acceso mediante el uso compartido (módulo 8).
• Destinatario → abierto, para el checkpoint de la Parte 1.

Click to enlarge

Paso 4 de 4: la porción completa, en el núcleo, archivada y fuera del núcleo. Cada línea es una relación de búsqueda: Salesforce construyó Field Service sobre relaciones de búsqueda, y con él adoptamos sus decisiones.

El diagrama no es la arquitectura

Puedo darte ese diagrama, y no basta. La arquitectura es el razonamiento que hay detrás. ¿Por qué cuenta? Una empresa con ajuste limpio. ¿Por qué orden de trabajo y no Delivery__c? La entrega se comporta como trabajo de campo, y Field Service ya está implantado. ¿Por qué un Manifiesto personalizado? No tiene un hogar estándar limpio. ¿Por qué las fotos no son simplemente Archivos? Volumen y economía del almacenamiento. ¿Por qué un ID externo? Otro sistema necesita una identidad estable a través de la frontera. ¿Por qué el usuario de integración es dueño de las órdenes de trabajo? Aquí la propiedad no determina el acceso, y así la pista de auditoría sigue siendo honesta. ¿Por qué sigue abierto el destinatario? Todavía no hemos respondido suficientes preguntas. Las líneas son el resultado; las decisiones las produjeron.

Así que este es el hábito con el que quiero que salgas del capítulo 3. Señala cualquier cosa de un modelo físico y pregunta ¿por qué? ¿Por qué este objeto, este tipo, esta relación, este propietario, este lugar, esta regla? Deberías poder rastrear la respuesta hacia atrás: de la configuración al modelo físico, al modelo lógico, al requisito del negocio. Si no puedes, alguien diseñó desde Setup.

Y habrás notado los números que no hemos trabajado del todo: entregas por socio, partidas, fotos, retención, archivo. Bien. Pide el número de ceros antes de fijar un diseño: un modelo que funciona de maravilla con cincuenta mil registros puede comportarse de forma muy distinta con quinientos millones. Eso es la Parte 2.

Más allá del examen: lo que cambia la IA. Dale a una IA el planteamiento de Steve Trucking y producirá un esquema en segundos: cuenta, orden de trabajo, objetos personalizados, campos, incluso los metadatos de despliegue. Es un acelerador fantástico, y no es la revisión. El trabajo del arquitecto pasa a ser comprobar los mapeos y sus consecuencias: el ajuste, las licencias, la propiedad, el ciclo de vida, la escala, la identidad, la seguridad y lo que se queda fuera de la plataforma. La IA es el cohete propulsor; no te dice si estás apuntando en la dirección correcta.

Lo que decide aquí un arquitecto

• Cómo corresponde cada concepto de negocio a Salesforce: un objeto estándar, un objeto personalizado o algo fuera del núcleo.
• Qué identificadores, campos y relaciones implementan el significado de negocio sin cambiarlo en silencio.
• Qué comportamiento de la plataforma y qué licencias vienen con un modelo estándar que adoptas.
• Qué decisiones de propiedad, ciclo de vida, consistencia, almacenamiento y escala hay que tomar antes de que el diseño esté completo.
• Qué preguntas quedan explícitamente abiertas, en lugar de esconderse detrás de una elección de implementación arbitraria.

Al principio de este capítulo preguntamos cómo debería vivir el modelo en Salesforce. Eso es la arquitectura de datos de Salesforce: no crear objetos, no memorizar Setup, no dibujar cajas más bonitas, sino encajar de forma deliberada el modelo del negocio en la forma de la plataforma. Cada estructura es un compromiso. Haz las que puedas explicar.

Explora

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) y WorkType (opens in a new tab) (en inglés), consultado el 2026-10-02.
• El planteamiento de Steve Trucking.