Los modelos de datos estándar
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)
Módulo 2 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: La plataforma de datos de Salesforce: más que una base de datos · Siguiente: Construye el tuyo: objetos personalizados
La pregunta que responde este módulo: ¿Qué ya modeló Salesforce por ti, y cómo está armado?
En el módulo 1 te dije que mires a la nave nodriza: antes de inventar algo, mira cómo lo hace el propio Salesforce. En este módulo es donde de verdad miramos. Salesforce ya modeló gran parte del negocio por ti, en sus objetos estándar, y dos de esos modelos hacen la mayor parte del trabajo en la mayoría de las organizaciones en las que entro: el modelo de ventas (Sales) y el modelo de servicio (Service). Antes de poder decidir si algo merece un objeto personalizado, necesitas saber qué hay ya. De eso tratan los próximos dos módulos.
Qué hace que un objeto sea estándar
Sección titulada «Qué hace que un objeto sea estándar »Un objeto estándar viene listo para usar. Lo construyó Salesforce, tiene un propósito definido y trae sus propios campos y relaciones. Puedes agregarle campos, construir automatizaciones a su alrededor y cambiar sus formatos de página, pero no puedes rediseñarlo: los campos y las relaciones estándar son de Salesforce.
Mira los nombres. Account, Contact, Case. Sin prefijo, sin sufijo. Es Salesforce reservándose ese espacio. Todo lo que construimos nosotros termina en __c, así que Salesforce puede agregar objetos estándar nuevos en cualquier momento sin chocar nunca con nada de tu organización. Y lo hace, en cada versión.
En algún momento del camino alguien construyó un objeto producto que no funcionó y hubo que dejarlo atrás. Por eso el nombre de API es Product2. Es mi primera prueba de fuego cuando alguien me dice que conoce Salesforce.
El modelo de ventas
Sección titulada «El modelo de ventas »Empieza por la izquierda, con el prospecto (Lead): alguien que podría convertirse en cliente. Un prospecto todavía no es realmente parte del modelo. Es una zona de espera. Cuando lo conviertes, Salesforce crea los registros reales: una cuenta, un contacto y, si hay un negocio, una oportunidad. Por eso dibujo el prospecto a un lado.
La cuenta es la empresa. Sus contactos son las personas que trabajan en ella. Una oportunidad es un negocio con esa cuenta. Hasta aquí, nada que no esperaras.
Después se pone interesante. ¿Qué hay en el negocio? Cada línea es un producto de oportunidad (Opportunity Product), y un producto de oportunidad no apunta directamente a un producto. Apunta a una entrada de lista de precios (Price Book Entry): este producto, a este precio, en esta lista de precios. La entrada de lista de precios se sitúa entre el producto y la lista de precios (Price Book), así que el mismo producto puede tener un precio en la lista de precios estándar y otro en tu lista de precios para socios.
Son dos relaciones que se convirtieron en cosas, una detrás de otra. ¿Te acuerdas del Artículo de entrega del capítulo 2, entre la Entrega y el Producto, y del Truco del perro entre el Perro y el Truco? Salesforce hizo exactamente lo mismo aquí, dos veces: el producto de oportunidad entre la oportunidad y la entrada de lista de precios, y la entrada de lista de precios entre el producto y la lista de precios. Cuando sabes leer eso, sabes leer la mayor parte del modelo de datos estándar.
Aquí está esa cadena de cerca, con los campos que la mantienen unida:
Una regla con la que la gente tropieza: hay una lista de precios estándar, y una entrada de lista de precios en cualquier otra lista de precios puede simplemente usar el precio estándar del producto. Ten claro qué lista de precios usa una oportunidad antes de cargar sus productos.
El modelo de servicio
Sección titulada «El modelo de servicio »Ahora el otro lado de la casa. La misma cuenta, los mismos contactos. Cuando algo sale mal, el cliente abre un caso.
El caso normalmente trata sobre algo que el cliente tiene, y Salesforce tiene un objeto para eso: el activo (Asset). En el módulo 5 lo llamaré el objeto estándar que la gente pasa por alto. Es una cosa que el cliente tiene, la haya comprado a ti o no.
¿Y a qué tiene derecho el cliente? Eso es el derecho (Entitlement): el soporte que una cuenta puede recibir, a menudo ligado a un activo, a un producto o a un contrato de servicio. Pon un derecho en un caso, y ahora el caso sabe qué nivel de soporte se supone que debe recibir.
Mira la línea que va del caso de vuelta a sí mismo. Cada caso tiene un campo Caso principal (Parent Case), y apunta a otro caso. Eso es una búsqueda a sí mismo (self-lookup): una relación de un objeto consigo mismo. Confunde a mucha gente la primera vez que la ve, así que aquí van las dos razones por las que la uso.
Una: un problema grande que se divide en otros más pequeños. El cliente reporta que toda la instalación está caída. Abrimos subcasos para la red, el hardware y la configuración, cada uno trabajado por separado, y todos se resuelven hacia arriba: el caso principal no está terminado hasta que lo estén ellos.
Dos: el historial. Un caso se cerró el mes pasado, y ahora el mismo problema volvió. El caso nuevo apunta al original, así que cualquiera que lo abra puede ver que esto ya pasó antes, y qué se hizo al respecto.
Volveremos a las búsquedas a sí mismo cuando lleguemos a las relaciones en el módulo 7.
Fíjate en que la cuenta y el contacto están en el mismo lugar en los dos diagramas. Son los mismos registros. Un representante de ventas y un agente de servicio miran al mismo cliente, desde lados distintos de la casa. Ese es uno de los argumentos más fuertes para quedarse con lo estándar: los modelos se construyeron para encontrarse.
Archivos y datos adjuntos
Sección titulada «Archivos y datos adjuntos »No todo lo que hay en un registro es un campo. Los contratos, las fotos, los PDF y las hojas de cálculo son archivos, y pertenecen a Salesforce Files, no al viejo modelo de datos adjuntos (Attachments), que es heredado. Si el documento ya vive en SharePoint Online, OneDrive, Google Drive o Box, Files Connect permite que los usuarios lleguen a él desde Salesforce sin copiarlo.
Los archivos se cuentan de forma distinta a los registros. Salesforce divide el almacenamiento en dos: el almacenamiento de archivos guarda los datos adjuntos, Files, Salesforce CRM Content, los archivos de Chatter y similares, y el almacenamiento de datos guarda tus registros. El almacenamiento de archivos sube rápido cuando cada registro recibe fotos o escaneos, así que los grandes volúmenes de imágenes, como las fotos de una aplicación de campo, a menudo pertenecen por completo fuera de Salesforce, y Salesforce guarda solo un enlace. El módulo 4 vuelve sobre eso.
Dos columnas o doscientas
Sección titulada «Dos columnas o doscientas »El almacenamiento de datos también se cuenta de forma distinta a una base de datos. En una base de datos normal, una tabla con dos columnas y un millón de filas es pequeña, y una tabla con cien columnas y un millón de filas es un elefante. Salesforce las pesa igual: la mayoría de los registros cuentan como unos 2 KB, sin importar cuántos campos tengan. Hay excepciones. Una campaña cuenta más, un mensaje de correo electrónico cuenta por su tamaño real, y una cuenta personal cuenta como unos 4 KB, porque es una cuenta y un contacto.
Un consejo. Cada vez que entro en una organización nueva, uno de los primeros lugares a los que voy es Setup → Storage Usage (Uso del almacenamiento). Hasta le pido una captura de pantalla al cliente en la primera llamada. Esa pantalla no miente. Te dice qué objetos están creciendo, y cuáles ya son los elefantes.
Cuentas personales: cuando el cliente es una persona
Sección titulada «Cuentas personales: cuando el cliente es una persona »El modelo de cuenta y contacto funciona de maravilla para una empresa y las personas que trabajan en ella. ¿Pero qué pasa si tu cliente no es una empresa? ¿Qué pasa si es una persona?
Eso es la cuenta personal: una cuenta y un contacto combinados en un solo registro, para personas individuales. Sus campos de contacto vienen con ella, y los personalizados aparecen con su propio sufijo, __pc. Cada una cuenta tanto para el almacenamiento de cuentas como para el de contactos, porque por debajo es las dos cosas.
Una advertencia antes de activarlas: una vez habilitadas las cuentas personales, no se pueden deshabilitar. Esa es la Prueba de Reversibilidad del capítulo 1 en su forma más pura. El módulo 5 te da mi postura sobre cuándo valen la pena.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- Qué partes del negocio ya modeló Salesforce, antes de diseñar nada nuevo.
- Si un concepto cae en el modelo de ventas, en el de servicio o en los dos, sabiendo que comparten la cuenta y el contacto.
- Dónde viven los documentos y las imágenes: Salesforce Files, un sistema de archivos conectado, o fuera de la plataforma con un enlace.
- Cuánto costarán los datos en almacenamiento, contados como los cuenta Salesforce: registros, no columnas.
- Si el cliente es una empresa o una persona, antes de activar algo que no se puede desactivar.
¿Y cuando Salesforce no tiene lo que necesitas? Lo construyes. Eso viene a continuación.
Explora
Sección titulada «Explora »- OpportunityLineItem (opens in a new tab), Object Reference for the Salesforce Platform (en inglés, consultado el 2026-10-12): “un miembro de la lista de productos Product2 asociados a una oportunidad”; la entrada de lista de precios es obligatoria.
- PricebookEntry (opens in a new tab), Object Reference (en inglés, consultado el 2026-10-12): “una asociación entre un Pricebook2 y un Product2”; una entrada puede usar el precio estándar.
- Case (opens in a new tab), Object Reference (en inglés, consultado el 2026-10-12): ParentId, “el ID del caso principal en la jerarquía. La etiqueta es Parent Case”; una búsqueda a Case.
- Entitlement (opens in a new tab), Object Reference (en inglés, consultado el 2026-10-12): “el soporte al cliente que una cuenta o un contacto puede recibir”, posiblemente basado en un activo, un producto o un contrato de servicio.
- Data and Storage Resources (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-10-12): qué incluyen el almacenamiento de archivos y el almacenamiento de datos.
- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-10-12): “La mayoría de los registros de Salesforce consumen aproximadamente 2 KB de almacenamiento de datos”; las cuentas personales, unos 4 KB.
- Enable Person Accounts (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-10-12): “Una vez habilitadas las cuentas personales, no se pueden deshabilitar”.
- Files Connect FAQ (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-09-25).