¿Dónde viven estos datos?

🌐 También en 28 idiomas

English · Español · 日本語 · 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 · 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 4 de 10 del capítulo Arquitectura de datos de Salesforce, el tercer capítulo del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Construye el tuyo: objetos personalizados · Siguiente: Elige el objeto correcto

La pregunta que responde este módulo: antes de crear un objeto, ¿dónde deberían vivir realmente estos datos: en el núcleo, en Salesforce, referenciados donde ya están, o archivados?

Déjame hacerte una pregunta. Te llega un requisito nuevo. ¿Qué es lo primero que haces?

Si eres como la mayoría, abres Setup y creas un objeto personalizado. Lo entiendo. En diez minutos tienes una pestaña, un formato de página y una vista de lista. Y esto es lo que le digo a cada clase: en el momento en que creas ese objeto nuevo, ya estás pensando como un arquitecto, lo quieras o no. Porque cada objeto que creas es un compromiso. Ocupa almacenamiento. Acumula límites. Recibe un modelo de uso compartido, lo hayas diseñado o no. Necesita una licencia para cualquiera que lo toque. Y una vez que las personas y las integraciones dependen de él, buena suerte para quitarlo.

Así que la primera decisión de arquitectura no es qué objeto. Es ¿dónde deberían vivir estos datos? Acierta con eso y el tipo de objeto casi se elige solo.

En el núcleo y fuera del núcleo

Primero, una palabra que voy a usar mucho: núcleo (core). El núcleo es la plataforma de Salesforce sobre la que funciona tu organización: la plataforma multiinquilino basada en metadatos del módulo 1, donde viven los objetos de Sales y Service del módulo 2, y cada objeto personalizado que construyes en el módulo 3. Cuando digo que los datos están en el núcleo, quiero decir que se guardan en tu organización, en sus objetos.

No todos los datos viven ahí. Data 360 guarda sus datos en su propio almacén, fuera de los objetos de tu organización (está cerca del núcleo: se gestiona en el núcleo, y sus datos se alojan fuera del núcleo; más en el capítulo 4). Y luego está todo lo que tu empresa usa que no es Salesforce en absoluto: el ERP, el almacén de datos, el sistema de pedidos, la plataforma del socio. Todo eso está fuera del núcleo. Salesforce puede llegar a ello, mostrarlo y usarlo, pero tu organización no lo guarda.

En el núcleo, hay dos tipos de objetos que realmente guardan tus registros: los sObjects, estándar y personalizados (__c), y los objetos grandes (big objects, __b). Fuera del núcleo, llegas a los datos a través de objetos externos (__x) y las demás herramientas de integración. Ten presentes esos sufijos del módulo 3; te dicen dónde vive un dato solo por su nombre.

Lo pienso como una oficina. Algunas cosas van en tu escritorio, donde las usas todos los días. Otras solo necesitas consultarlas en el archivador de otra persona. Y otras van en cajas al cobertizo del fondo. Eso me da tres respuestas.

1. En el núcleo: vive en tu escritorio

Los datos se crean, se cambian y se usan en Salesforce todos los días: cuentas, casos, oportunidades, órdenes de trabajo. Guardarlos en sObjects es como tenerlos al frente de tu oficina. Para eso son los objetos estándar y personalizados, y lo recibes todo: formatos de página, uso compartido, automatización, informes, búsqueda y ahora las funciones de IA construidas sobre el modelo de datos.

Pero tu escritorio no es gratis. Los datos en el núcleo cuestan almacenamiento, contado como lo cuenta Salesforce, registro por registro, no columna por columna, y los documentos cuentan aparte contra el almacenamiento de archivos. Vimos ambos en el módulo 2. Los grandes volúmenes de fotos y documentos escaneados a menudo deben estar fuera del núcleo, con Salesforce guardando solo un enlace.

2. Referenciados: viven en el archivador de otra persona

Los datos pertenecen a otro sistema (el ERP, un almacén de datos, una plataforma de pedidos), y ese sistema sigue siendo la fuente de la verdad. Los usuarios necesitan verlos en Salesforce, quizá relacionarlos con un registro, pero Salesforce no necesita su propia copia. También oirás llamarlos datos virtuales: aparecen en Salesforce de forma virtual, sin guardarse nunca ahí.

Eso son los objetos externos, a través de Salesforce Connect. Me gusta decir que parece un pato y camina como un pato, pero no es un pato. Aparece como un sObject: puedes ponerlo en formatos de página y listas relacionadas, y relacionarlo con tus propios registros mediante búsquedas externas e indirectas. Pero los datos no se guardan en el núcleo. Cada vez que lo tocas, hace una llamada externa. Abres un registro, cargas una lista relacionada, ejecutas un informe, y Salesforce va y le pregunta al otro sistema. Eso significa latencia, y tu página solo está tan disponible como el sistema que hay detrás.

La gente protesta por el costo de la licencia, así que haz las cuentas como las hago yo en clase. Connect se licencia por punto de conexión, y un punto de conexión puede traer muchos objetos. Ahora pregúntate cuánto cuesta construir y mantener la alternativa: un componente personalizado, el código de llamada externa detrás y un desarrollador de guardia cuando se rompe. A menudo la licencia es más barata, y tus administradores pueden configurarla sin escribir una línea de código. Donde falla: datos que tus usuarios editan todo el día o con los que hacen muchos informes.

Los documentos también se pueden referenciar. Si un contrato ya vive en SharePoint Online, OneDrive, Google Drive o Box, Files Connect permite a los usuarios llegar a él desde Salesforce sin copiarlo.

Salesforce Connect no es la única forma de referenciar datos. A veces es lógica personalizada: código que llama al otro sistema en tiempo real y muestra sus datos en la página, sin guardar ninguna copia. Eso te da control total, y responsabilidad total por la llamada externa, los errores y el mantenimiento. Y Data 360 también puede federar sin copiar. Esa elección tiene su propio capítulo (Virtualización, federación y zero-copy). Aquí la idea es la decisión en sí: referencia, no copies.

3. Archivados: van al cobertizo del fondo

Historial, pistas de auditoría, transacciones antiguas. Tienes que conservarlos, a veces durante años, pero casi nadie los abre. Y este es el que los equipos postergan. Cuando una clase me dice que tiene un objeto con 50 millones de registros y me pregunta por qué archivaría, les devuelvo la pregunta: si no estás archivando hoy, ¿vas a archivar alguna vez? Con 50 millones hoy, vas camino de 100, 150, 200 millones.

Hay dos cobertizos. Uno está en el núcleo: los objetos grandes. Piénsalos como guardar datos en el garaje. Puedes guardar una cantidad enorme de registros, pero no puedes ponerlos en un formato de página, no hay interfaz ni informes estándar, y consultas a través del índice del objeto grande, por coincidencia exacta o por rango (Big Objects Best Practices (opens in a new tab), en inglés). La seguridad son solo permisos de objeto y de campo, sin uso compartido de registros, y la automatización no se ejecuta sobre ellos. He usado Salesforce Connect decenas de veces y los objetos grandes solo una o dos. Funcionan, pero son incómodos, y he escrito mi parte de soluciones alternativas para llegar a los datos. Así que mi consejo: haz un prototipo antes de proponerlos, y planifica cómo encontrará la gente los datos antes de elegirlos.

El otro cobertizo está fuera del núcleo: un almacén de datos o una base de datos en otro lugar (Diseñar para la escala). A menudo ese es el mejor cobertizo, y no tiene por qué quedar fuera de la vista. Los datos archivados fuera del núcleo pueden seguir apareciendo en informes con herramientas como Tableau, y pueden seguir siendo accesibles desde Salesforce, mediante Salesforce Connect u otra forma de virtualizarlos, cuando alguien necesita mirar atrás.

Te cuento un proyecto en el que acertamos desde el principio. Un cliente minorista tenía más de 1,200 ubicaciones. Me dijeron: “Solo hacemos cien citas al día por tienda. No es para tanto”. Luego hice las cuentas: cien al día, seis días a la semana (unos 305 días al año), en 1,200 ubicaciones, son más de 36 millones de citas al año. Luego mencionaron que cada visita creaba dos citas, una en el mostrador y otra para el taller del fondo: más de 73 millones de registros al año. Luego quisieron cinco años de historial: más de 360 millones de registros, antes de cualquier crecimiento. No habíamos salido a producción y ya veía el tren yendo directo a la estación de los grandes volúmenes de datos. Así que el archivo se construyó antes de recoger una sola cita: las citas más antiguas pasaban a objetos grandes, y la pantalla de búsqueda mostraba las citas actuales con las archivadas justo debajo. Años después, sigue funcionando bien.

Click to enlarge

Llevarlo a la práctica: Steve Trucking

Steve Trucking es nuestro escenario de todo el curso: una empresa familiar de entregas de última milla que recoge electrodomésticos y electrónica en los centros de distribución de grandes minoristas, y luego los entrega e instala en las casas de los clientes. Cuatro tipos de datos suyos, tres respuestas:

Datos	Dónde viven	Por qué
Las entregas, equipos y citas de hoy	En el núcleo	Los despachadores y los equipos trabajan con ellos todo el día
Los detalles del pedido del minorista	Referenciados (o una copia mínima en el núcleo)	El sistema del minorista es la fuente de la verdad
El historial de entregas de hace tres años	Archivados	Se conservan para reclamos y tendencias; casi nadie los abre
Las fotos de las entregas	Fuera del núcleo, enlazadas	Miles al día; se guardan fuera de Salesforce con un enlace en la entrega

Aquí está lo mismo como modelo de datos. La entrega está en el núcleo, donde la gente trabaja con ella todo el día. Tres años después, pasa a Historial de entregas (Delivery History), un objeto grande: sigue en el núcleo, pero en el cobertizo. El pedido del socio aparece como un objeto externo, __x: Salesforce relaciona la entrega con él, pero los datos se quedan en el sistema del minorista. Y las fotos viven completamente fuera del núcleo, con un enlace desde la entrega. Un modelo, tres hogares.

Click to enlarge

Toda organización real tiene las tres. Las que se meten en problemas lo pusieron todo en el núcleo, porque crear un objeto era el botón por defecto.

Lo que decide aquí un arquitecto

• El hogar de cada tipo de dato, antes de diseñar cualquier objeto: en el núcleo, referenciado o archivado.
• La fuente de la verdad. Si otro sistema es dueño de los datos, Salesforce no debería convertirse en silencio en un segundo maestro.
• El camino de acceso para todo lo que está fuera del núcleo. Los datos referenciados necesitan un origen disponible y una latencia aceptable; los datos archivados necesitan una forma de que la gente los encuentre.
• El crecimiento del almacenamiento. Haz las cuentas ahora (registros por día, por el crecimiento, por la retención), no cuando llegue el aviso de almacenamiento.

Más allá del examen: la IA sube lo que está en juego con lo que está “en el núcleo”. Las funciones de IA y los agentes funcionan mejor con datos que la plataforma entiende: datos en objetos estándar y personalizados, bien nombrados y bien descritos. Eso empuja a poner más en el núcleo. Resístete con los datos equivocados. Un agente anclado en una copia desactualizada de los datos del ERP da respuestas seguras y equivocadas. A menudo lo mejor es referenciar el origen en vivo, o mantener en el núcleo una porción pequeña y bien descrita. Dónde lee la IA los datos ahora forma parte de decidir dónde viven los datos.

Explora

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (en inglés, consultado el 2026-09-25)
• Files Connect FAQ (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-09-25)
• En este curso: Virtualización, federación y zero-copy y Diseñar para la escala