Steve Trucking, lo que yo diseñaría

🌐 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 6 de 6 del capítulo Datos maestros e identidad, capítulo 6 del curso Data Architect, y el final de la Parte 1. Anterior: Cuando la autoridad es compartida · Siguiente: la Parte 2 empieza con Diseñar para la escala (coming soon)

La pregunta que responde este checkpoint: ¿Puedes unir la Parte 1 en un escenario real?

Haz primero el desafío. Este es mi recorrido por el desafío del Checkpoint 1. Si todavía no has dibujado tu propio diseño, hazlo antes de seguir leyendo. El valor está en comparar tu razonamiento con el mío, no en leer la respuesta.

Esto es “Lo que yo diseñaría”: una posible solución viable, no la respuesta, con las compensaciones nombradas y mis posturas tomadas. Todavía no hemos visto grandes volúmenes de datos, diseño de consultas, patrones de integración, migración ni transacciones, y es a propósito: la arquitectura se desarrolla a medida que aprendes más. Pero la Parte 1 nos da lo suficiente para fijar el esqueleto.

Empieza por los números

Del brief: unas 3,300 entregas por día laborable, un millón al año, con un crecimiento del 30 % anual. Unas 1.6 partidas por entrega (1.6 millones al año); unos ocho cambios de estado por entrega (8 millones al año); de cuatro a cinco millones de fotos al año; unas 200,000 lecturas de GPS al día; unos 180,000 casos al año; tres socios minoristas (Retail Partners) que envían manifiestos de tres formas distintas; nueve centros de distribución; 330 camiones con equipos de dos personas. Y Steve Trucking ya tiene una org de Salesforce con Service Cloud, Field Service y un portal de socios. Cuenta los ceros antes de dibujar una sola caja. Van a decidir varias cosas más abajo.

El núcleo de las entregas: mira a la nave nodriza

Las entregas son el corazón de todo, y Field Service ya hace el despacho. Así que empiezo por el modelo estándar de Field Service, como hizo la porción del capítulo 3:

Concepto de negocio	Objeto de Salesforce	Por qué
Socio minorista	Account (tipo de registro Retail Partner)	Una empresa con la que Steve Trucking tiene contrato; lleva contratos, casos y acceso al portal
Personal del socio (gerentes de centro de distribución, personal de tienda)	Contact	Los usuarios del portal deben ser contactos
Una entrega: un destinatario (Recipient), una dirección, un pedido del socio, un día	Work Order	La unidad de trabajo de Field Service; de ella dependen la programación, la app móvil y los informes de servicio
Cada artículo o servicio: el refrigerador, la instalación, el retiro del aparato viejo	Work Order Line Item	Divide el trabajo, impulsa las listas de verificación y la facturación
El tipo de parada: solo entrega, con instalación, con retiro	Work Type	Fija la duración, las habilidades y la lista de verificación de instalación
La visita programada y su franja horaria	Service Appointment	Lo que programa Field Service y muestra la app del equipo
Cuadrillas y camiones; áreas de despacho de los centros de distribución	Service Resource, Service Crew, Service Territory	Field Service programa un equipo como un solo recurso
Consultas de los destinatarios, reclamaciones de los socios	Case	La consola de servicio, los derechos de soporte (entitlements), email-to-case
La lista del socio para el martes en el centro de distribución de Phoenix	Manifest__c (personalizado)	Nada estándar representa la unidad de recepción, reconciliación y reproceso

Todo lo demás se queda estándar. Resistirse a más objetos personalizados es deliberado: la pregunta del capítulo 1 era cuándo debería un arquitecto resistirse a uno más, y aquí la respuesta es “casi siempre”. La línea del pedido del socio, por ejemplo, no es un objeto nuevo. Es la orden de trabajo, identificada por la referencia del socio.

Click to enlarge

Crece a partir del diagrama final del capítulo 3 (Diseña el modelo físico de Salesforce): los mismos objetos en los mismos lugares, con el equipo, el área de despacho, el caso y lo que el Checkpoint 1 deja fuera del núcleo añadidos.

La clave que empareja el pedido de un socio con una entrega

Cada línea del manifiesto se convierte en una orden de trabajo, vinculada a su Manifest. La clave es la pregunta que más quiero responder: ¿cómo sabemos que esta línea del socio es esa entrega? Mi respuesta: un External ID en la orden de trabajo construido a partir del socio minorista y la propia referencia de pedido y entrega del socio (algo como KEYSTONE-PHX-8843119-1), marcado como único. Un campo por fuente, uno a uno. Es el identificador del socio, no el nuestro: los “varios identificadores para una misma cosa” del capítulo 2, y el “el socio es dueño de su referencia de pedido” del módulo 1.

Por qué importa: los manifiestos llegan con uno o dos días de antelación y se revisan el mismo día. Con esa clave, cada manifiesto reenviado o revisado hace un upsert en lugar de crear duplicados. La revisión actualiza la orden de trabajo, un campo lo registra, y un cambio en una entrega ya asignada a una ruta avisa al coordinador: el cambio del socio se aplica, pero queda marcado hasta que despacho lo confirma. Esto es también lo que cambia respecto a la imagen del capítulo 4. Hoy cada manifiesto llega a RouteDesk, y los coordinadores vuelven a teclear las rutas en Salesforce y las paradas completadas de vuelta. En este diseño, los manifiestos entran directamente en Salesforce, con un upsert por la clave del socio; RouteDesk se retira y se acaba el volver a teclear. El capítulo de Integración diseña los tres formatos de entrada. La decisión de datos es la clave.

El destinatario: ¿cuenta personal, contacto o ninguno de los dos?

Esta es la decisión de datos más interesante de la Parte 1, así que aquí van las opciones, y luego mi elección.

Opción A: cuentas personales. Cada destinatario se convierte en una cuenta personal, vinculada a cada entrega. A favor: es estándar, funciona de forma natural con Service Cloud, la mensajería y la consola, y reconoce a los destinatarios que se repiten. En contra: unos un millón de destinatarios nuevos al año, cada uno una cuenta personal que ocupa aproximadamente el doble que una cuenta de empresa (Estimated Record Size by Object Type (opens in a new tab), en inglés), así que en dos años sería uno de los objetos más grandes de la org. Y los destinatarios no son clientes de Steve Trucking. Son clientes de cada socio minorista, y Steve Trucking nunca debe mezclar al cliente de un socio con el de otro (S2).

Opción B: contactos bajo la cuenta del socio minorista. En contra: un millón de contactos bajo tres o cuatro cuentas es un sesgo padre-hijo (skew) a una escala enorme, muy por encima de la recomendación de Salesforce de unos 10,000 hijos por padre (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab), en inglés). Esta es la opción para mostrar, y rechazar.

Opción C: el destinatario vive en la entrega. El nombre, el teléfono, el correo, la dirección y las notas de entrega del destinatario son campos de la orden de trabajo (los campos de dirección ya son estándar ahí), capturados del manifiesto. A favor: ningún objeto grande nuevo; los datos viven exactamente lo que la entrega los necesita; la eliminación ocurre por entrega, según el calendario del socio; y el aislamiento entre socios sale gratis, porque cada entrega pertenece a un socio. En contra: un destinatario que se repite no se reconoce como la misma persona.

Ese es el equilibrio que hay que encontrar. ¿Alguna vez va a hacer falta reconocer varias entregas como la misma persona, en el mismo lugar? ¿Darle a esa persona un inicio de sesión? Esa es la línea entre un destinatario que necesita un registro propio y unos datos del destinatario que son simplemente datos sobre la entrega. Y hay un camino intermedio. Lleva el propio ID de cliente del socio minorista como un campo de la entrega, un Retail Partner Customer ID. No crea un registro de destinatario, pero une las entregas que un socio envía para el mismo cliente, que es el comienzo de una experiencia del cliente más unificada, y lleva directamente de vuelta al sistema del socio minorista, donde ese cliente vive de verdad. Es su identificador, así que solo significa algo junto con el socio: el cliente 4417 de un socio no tiene nada que ver con el de otro.

En mi opinión profesional, la opción C es la elección correcta. Lo de no reconocerlo es aceptable, incluso deseable: Steve Trucking no tiene ninguna relación con estas personas más allá de la entrega. Es otra vez el módulo 1: el destinatario es cliente del socio, y el socio es la autoridad sobre quién es. Y es el capítulo 5: los datos personales que llegan a un solo lugar, ligados a una sola entrega, son mucho más fáciles de proteger, conservar y eliminar. Y resiste las formas normales del capítulo 2: los datos del destinatario son uno a uno con la entrega, así que pertenecen a ella. Un hijo Recipient aparte ahorraría unos pocos valores repetidos a costa de otro objeto, otra relación y su carga, y la única forma de que ahorrara más sería tratar a la misma persona como una sola entre socios minoristas, cosa que no vamos a hacer. Así que la entrega lleva al destinatario, con el Retail Partner Customer ID como camino de vuelta al propio sistema del socio.

Click to enlarge

¿Unificaría a los destinatarios entre socios?

John Smith, 123 Main Street, aparece en el manifiesto de Redrock y en el de Brightwave. Probablemente sea la misma persona. ¿Debería Steve Trucking unificarlos? No, deliberadamente no. Unificar destinatarios entre socios minoristas violaría S2: un socio nunca debe ver los destinatarios de otro, y una identidad unificada es justo el puente por donde se filtran. Es la postura de este capítulo aplicada: empareja de menos donde mezclar sale caro, y aquí mezclar sale muy caro.

Si más adelante un socio minorista quiere reconocer a los destinatarios que se repiten dentro de sus propias entregas, ese es un trabajo para una herramienta de resolución de identidades, como la de Data 360, limitada a ese socio: un mapa de estilo registro, no una cuenta personal, y nunca entre socios. Un mapa de quién es quién no otorga la propiedad, y no otorga el acceso.

Qué se queda en la org y qué no

El capítulo 3 preguntó dónde deberían vivir los datos. Aquí lo responden los ceros:

• El estado actual vive en la cita de servicio y la orden de trabajo. El historial de cambios de estado, unos 8 millones al año y en aumento, no necesita vivir en la org principal. Cada cambio se publica como un evento y se guarda en el almacén de datos, Snowflake. La org conserva el estado actual; el historial sigue disponible para servicio, operaciones y análisis, solo que no en la base de datos operativa.
• Las fotos (de cuatro a cinco millones al año, algunas con personas o con el interior de una casa) viven fuera del núcleo, en un almacenamiento pensado para ese volumen, subidas directamente desde la app del equipo. La org conserva solo lo que necesita: un pequeño registro de índice por foto, o solo un recuento y un indicador de “fotos de instalación obligatorias completas”. Mi preferencia es la opción más ligera: mantener la org ligera, y dejar que el almacén de fotos sea dueño de su índice y su retención.
• Las lecturas de GPS (200,000 al día) se quedan en FleetLink y van a Snowflake; la org solo necesita la última posición para la página de seguimiento y el mapa del despachador.
• Los ocho años de historial de RouteDesk (unos 5 millones de entregas) van al almacén de datos o a un archivo, accesibles para las reclamaciones. Qué entra en la org, si algo entra, es una decisión de migración para la Parte 2.

Click to enlarge

Checkpoint 1: lo que yo diseñaría. Los mismos lugares que el panorama del capítulo 4 (El panorama de Steve Trucking), sin el volver a teclear ni la hoja de cálculo.

Quién ve qué, y quién necesita una licencia

• Los socios minoristas ven solo sus propias entregas (S2). Cada orden de trabajo lleva su socio minorista; los usuarios del portal ven las entregas de su socio, y los gerentes de centro de distribución solo las de su centro.
• Los usuarios de los socios necesitan una licencia de portal que admita reglas de uso compartido y funciones: Customer Community Plus o Partner Community. Los asientos del estadio del capítulo 3: los asientos más baratos no tienen el uso compartido que necesita este diseño. Las dos licencias necesitan funciones para los usuarios externos, y Salesforce advierte que más funciones hacen más lenta la org (Experience Cloud User Licenses (opens in a new tab), en inglés). Una función por socio y por centro de distribución está bien; una función para cada tienda, no.

Conocimiento para el examen. Conoce qué licencias externas incluyen el uso compartido estándar: Customer Community Plus y Partner Community (con funciones para los usuarios externos), no Customer Community, que usa conjuntos de uso compartido (sharing sets).

• Los destinatarios no necesitan licencia. La página de seguimiento muestra una entrega mediante un enlace con un token que caduca (S3), no con un inicio de sesión.
• Vigila el sesgo (skew). Cientos de miles de órdenes de trabajo al año apuntando a tres o cuatro cuentas de socios es un sesgo de datos de cuenta. Una opción es una cuenta hija por centro de distribución bajo cada socio, lo que reparte los hijos en nueve o más; archivar las entregas completadas después del plazo de reclamaciones mantiene bajo el número de hijos activos por padre. La Parte 2 se ocupa de eso.

Lo que yo no haría

No crearía una cuenta personal para cada destinatario solo porque un destinatario es una persona. No colgaría un millón de contactos de tres cuentas. No construiría un objeto Delivery personalizado junto a la orden de trabajo de Field Service. No unificaría a los destinatarios entre socios. No pondría millones de fotos ni de lecturas de GPS en el almacenamiento principal. Y no llamaría golden record a un destinatario unificado a menos que de verdad hubiéramos tomado una decisión de datos maestros.

Lo que sigue abierto

La Parte 1 fijó el esqueleto; la Parte 2 lo pone a prueba. La regla de LDV en el tercer año (las órdenes de trabajo, las citas de servicio y las partidas entran todos en territorio de gran volumen en dos o tres años), el diseño de consultas para las vistas de lista limitadas a cada socio, las tres integraciones de entrada y los tres flujos de estado, la migración de RouteDesk, las transacciones del día, y el diseño de seguridad detrás del portal. Steve Trucking también va a cambiar. Guarda este diseño; vas a volver a él.

Lo que decide aquí un arquitecto

• Qué objetos estándar llevan el núcleo (aquí, los de Field Service), y qué objetos personalizados están de verdad justificados (aquí, uno).
• La clave que empareja la línea de pedido de cada socio con una entrega, y por qué pertenece al socio.
• Qué es el destinatario, según la relación que Steve Trucking tiene realmente con él.
• Si unificar identidades, y dónde mezclar sale demasiado caro como para arriesgarse.
• Qué se queda en la org, qué vive fuera del núcleo, y de qué licencias depende el diseño.

Explora

• El brief y los desafíos de Steve Trucking (D1, D3, DC1).
• Ayuda de Salesforce, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) y Experience Cloud User Licenses (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (en inglés), como se cita en el capítulo 3.