Elige el objeto correcto

🌐 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 5 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: ¿Dónde viven estos datos? · Siguiente: Los campos también son arquitectura

La pregunta que responde este módulo: ¿En qué tipo de objeto de Salesforce debería convertirse este concepto de negocio, y qué permiten las licencias?

Una de las cosas más fáciles de hacer en Salesforce es crear un objeto personalizado. Precisamente por eso creo que creamos demasiados.

Estás en una sesión de requisitos y alguien dice: “Necesitamos llevar el seguimiento de nuestros distribuidores”. Nuevo objeto personalizado: Distribuidor. Listo. Salvo que quiero que el arquitecto haga antes otra pregunta: ¿qué es un distribuidor? Es una empresa. Salesforce ya tiene una forma bastante buena de representar una empresa. Se llama cuenta. Eso no significa que la respuesta sea siempre la cuenta. Pero si tengo que explicar por qué una empresa no es una cuenta, quiero una razón mejor que “el negocio los llama distribuidores”.

Aquí es donde el modelo lógico del capítulo 2 se encuentra con la plataforma, y mi posición de partida es sencilla: si el concepto de negocio encaja limpiamente con el propósito previsto de un objeto estándar, empieza por ahí.

Empieza por el significado

Incluso cuando algo merece ser un objeto, no merece automáticamente ser un objeto personalizado. Pregunta qué representa realmente. ¿Un negocio u organización de cualquier tipo? Empieza por la cuenta. ¿Una persona que trabaja con esa organización? Contacto. ¿Algo que un cliente posee o ha comprado? Activo. ¿Algo que intentas vender? Ahora la oportunidad entra en la conversación.

Por eso miramos primero a la nave nodriza, en el módulo 2. Esos modelos no encajan con todos los negocios, pero no deberíamos ignorarlos porque construir los nuestros nos parezca más limpio. Antes de Nuevo objeto personalizado, pregunta cómo modela Salesforce este concepto, qué se ha construido alrededor de ese modelo y a qué renunciarías al reemplazarlo.

La prueba del ajuste limpio

Mi prueba es una sola pregunta: ¿este concepto de negocio encaja limpiamente con el propósito previsto del objeto estándar? Si encaja, mi inclinación es hacia el objeto estándar.

Un distribuidor es una empresa con la que tenemos una relación, así que la cuenta encaja limpiamente. No me importa que los usuarios llamen a una empresa distribuidor, a otra proveedor, a otra socio minorista y a otra cliente. Son roles de negocio, y no necesitan cuatro objetos físicos. Nombres de negocio distintos no significan automáticamente estructuras de datos distintas. Un tipo, un tipo de registro o una relación pueden llevar la diferencia.

La prueba también funciona en la otra dirección. En el capítulo 1 te dejé una pregunta: el negocio de un cliente tiene muchos lugares de entrega. ¿Cada lugar debería ser una cuenta, o un objeto personalizado?

Una cuenta te da mucho. Obtienes los campos de dirección, y todo lo que ya espera una dirección de cuenta: informes, mapas, integraciones. Pero también obtienes la sobrecarga: muchísimos campos, uso compartido, jerarquía, propiedad, todo lo que cuelga de una cuenta, y casi nada de eso es relevante para una dirección aparte. Estarías cargando con un montón de cosas pesadas que no vas a usar, solo por una dirección alternativa.

Un objeto personalizado, hijo de la cuenta, puede ser ligero: solo los campos de dirección, un lugar al que entregamos, con su propio ciclo de vida que puedo controlar de forma independiente.

Así que es un equilibrio: el peso que asumes frente al valor que obtienes. Si lo único que necesito es una dirección con su propio ciclo de vida, ahí es donde voy a lo personalizado.

Lo mismo con los subproblemas de un caso. Si cada subproblema realmente es un caso, trabajado por un agente, con su propio estado y su propio nivel de servicio, anídalos con el caso principal (Parent Case) del módulo 2. Pero si es solo un punto de una lista de verificación que nadie trabaja como caso, un caso completo carga con mucho que nunca va a usar, y un simple hijo personalizado puede pesar menos. No porque lo personalizado sea más limpio. Porque el significado es distinto, o el peso no es el adecuado.

Los objetos estándar vienen con equipaje

Cuando eliges un objeto estándar, eliges más que sus campos. Eliges algo que los productos de Salesforce ya entienden: informes, automatización, relaciones incorporadas, funciones de producto, paquetes de AppExchange y lo que Salesforce construya después. Eso puede ser enormemente valioso.

Los objetos estándar también vienen con opiniones: comportamiento existente, relaciones, consideraciones de seguridad, a veces requisitos de licencia y funciones que no necesitas. Así que “usa siempre objetos estándar” no es mi regla. No tengo una regla de “siempre”. Tengo una inclinación: usa el objeto estándar cuando el significado encaja limpiamente y el comportamiento de la plataforma a su alrededor ayuda al diseño en lugar de pelearse con él. Si me paso cinco años haciendo que una oportunidad se comporte como algo que no es una oportunidad de venta, no he ganado nada por quedarme en lo estándar. Solo he hecho la concesión equivocada en la otra dirección.

El activo es un buen ejemplo

El activo es uno de los objetos estándar que la gente pasa por alto. La forma más sencilla en que puedo decirlo: es una cosa que el cliente tiene. Quizá nos la compró a nosotros, quizá no. Igual me importa el producto de un competidor que está en las instalaciones de mi cliente, porque le doy servicio, o intento reemplazarlo, o necesito entender su base instalada. Si creo Customer_Product__c sin mirar antes el activo, me salté una pregunta de arquitectura. El activo no gana automáticamente, pero merece ser evaluado.

Cuentas personales: ¿cuándo la persona es la cuenta?

En el módulo 2 conocimos las cuentas personales: una cuenta y un contacto en un solo registro, para clientes que son individuos. Ahora, la decisión.

Mi posición: para B2C, es difícil prescindir de ellas. Viene tanto de serie con las cuentas y los contactos que el costo y la sobrecarga valen la pena. Y sí hay un costo: más o menos el doble de almacenamiento que una cuenta de empresa, un interruptor que no puedes apagar, y algunas licencias externas no pueden usarlas. Partner Community no se puede usar con cuentas personales (Experience Cloud User Licenses (opens in a new tab), en inglés). Así que la pregunta no es “¿tenemos personas en nuestra base de datos?”. Toda organización tiene personas. Es “¿la persona es realmente la cuenta en este negocio?”. Que un contacto sea una persona no lo convierte en una cuenta personal. Lo decide la relación de negocio.

Click to enlarge

Ahora déjame complicarlo todo: las licencias

Hasta ahora: encuentra el concepto, busca el encaje estándar más limpio, ve a lo personalizado cuando el significado no encaja. Ahora la pregunta de seguimiento del arquitecto: ¿quién necesita usarlo? Puedes diseñar un modelo precioso y luego descubrir que la mitad de las personas que necesitan los datos no tienen licencia para los objetos que elegiste. Las licencias son parte del modelo de datos.

Tres licencias internas

Empieza por tu propia gente. Dentro de la empresa hay tres tipos de licencia que quiero que todo arquitecto conozca al dedillo, porque determinan lo que cada usuario puede ver y hacer, y por lo tanto con qué puede contar tu modelo de datos.

Sales Cloud (ahora Agentforce Sales). Estos usuarios tienen la licencia de usuario Salesforce completa: los objetos estándar de CRM y cualquier aplicación estándar o personalizada. Eso son prospectos, oportunidades y pronósticos además de cuentas y contactos, e incluso casos: un representante de ventas puede ver los casos abiertos de un cliente antes de una llamada. Crear y ejecutar campañas requiere una pieza más, la licencia de función Marketing User.

Service Cloud (ahora Agentforce Service). La misma licencia de usuario Salesforce, configurada para servicio. Los casos están en el centro, trabajados en la Service Console: la licencia de función Service Cloud User es la que abre la Salesforce Console for Service. Aquí es donde viven los acuerdos de nivel de servicio (SLA), mediante la gestión de derechos y los hitos, y donde entra Knowledge, que la mayoría de las ediciones compran como complemento.

Platform (Salesforce Platform). Para las personas que necesitan tus aplicaciones personalizadas, no el CRM. Obtienen cuentas, contactos, informes, tableros, documentos y todas las aplicaciones personalizadas de la organización. Lo que no obtienen: pronósticos, prospectos, campañas y oportunidades. Cuesta menos, que es justo por lo que tantas aplicaciones personalizadas grandes funcionan con ella, y justo por lo que puede tomar por sorpresa a tu modelo de datos.

	Sales Cloud	Service Cloud	Platform
Licencia de usuario	Salesforce	Salesforce	Salesforce Platform
Pensada para	Vender	Atender a los clientes	Aplicaciones personalizadas
Cuentas, contactos	Sí	Sí	Sí
Prospectos, oportunidades, pronósticos	Sí	Sí	No
Casos	Sí, para ver los casos de un cliente	En el centro, en la Service Console	No
Acuerdos de nivel de servicio	No	Sí, derechos e hitos	No
Objetos y aplicaciones personalizados	Sí	Sí	Sí

Lee la tabla como la lee un arquitecto. Si un grupo grande de usuarios está en Platform, cualquier diseño que ponga su trabajo en una oportunidad está roto antes de empezar. Si los ejecutivos necesitan cifras de SLA, la licencia que tienen decide si pueden verlas. Estos tres tipos determinan el comportamiento.

Click to enlarge

Cuando la licencia decide el objeto

La oportunidad es la víctima con la que más me he topado. Lo viste en la tabla: los usuarios de Platform no la tienen (Standard User Licenses (opens in a new tab), en inglés), y los usuarios de Customer Community tampoco pueden trabajar con ella. Así que el requisito parece una oportunidad, alguien dice “usemos la oportunidad”, y entonces pregunto quién necesita acceso. Si una población grande está en licencias de Platform o de Customer Community, la licencia ya no es un detalle de compras. Es una restricción de arquitectura, y normalmente empuja el diseño hacia un objeto personalizado.

También funciona hacia arriba. En clase pregunto: el director general quiere tableros bonitos; ¿licencia de Sales o de Service? Un usuario de Sales puede ver los objetos de ventas e incluso los casos, así que para tableros de ventas y recuentos de casos abiertos, Sales está bien. Pero en el momento en que el ejecutivo quiere KPI de SLA (cuánto falta para que un caso incumpla su nivel de servicio), esos datos están en los derechos y los hitos, y la gestión de derechos necesita Agentforce Service, antes Service Cloud (Supported Editions for Service Features (opens in a new tab), en inglés). Ahora estás mejorando las licencias de los ejecutivos. Escucha el requisito del negocio, y sabe qué licencia hay debajo de los datos que necesita.

El estadio

Pienso en las licencias como asientos en un estadio. Todos están viendo el mismo partido. Si compro los asientos caros del centro, veo a los dos equipos de cerca. Si estoy arriba en la esquina, en la grada, los asientos no tienen cojín y veo el partido con binoculares.

Esas son las licencias externas, para personas de fuera de la empresa: clientes y socios que inician sesión en un sitio de Experience Cloud. Hay tres que quiero que conozcas.

Customer Community: la grada. Pensada para grandes cantidades de usuarios externos que necesitan casos y conocimiento: un cliente que revisa su caso de soporte. Los asientos cuestan más o menos la mitad y pueden ir a una cantidad enorme de usuarios. ¿Qué pierdes allá arriba? Informes, tableros y la tabla de uso compartido: el uso compartido basado en funciones que tienen los niveles superiores. Sí funciona con cuentas personales.

Customer Community Plus: más o menos a mitad de camino. Salesforce la describe como la licencia para usuarios externos que necesitan informes, tableros y uso compartido estándar: un cliente que gestiona el acceso de otras personas, o que necesita ver sus cifras.

Partner Community: todavía más cerca, para negocio a negocio, con acceso a los datos de ventas. Los socios trabajan prospectos y oportunidades: registran acuerdos y ejecutan campañas contigo. Es el asiento externo que llega a los objetos de ventas. Un detalle: no se puede usar con cuentas personales (Experience Cloud User Licenses (opens in a new tab), en inglés).

Click to enlarge

El error es diseñar como si todos tuvieran la entrada cara, y descubrir en la implementación que la mayoría de tus usuarios no pueden entrar a la sección donde pusiste sus datos. Entonces tienes tres opciones: comprar otros asientos, mover la experiencia o rediseñar el modelo. Las tres son arquitectura.

Cómo pagan cambia el diseño

Hay otra pregunta que la gente olvida: ¿cómo van a iniciar sesión estos usuarios? Las licencias externas vienen de dos formas. Por miembro: pagas por usuario, lo que sirve para 500 socios que inician sesión todos los días. Por inicio de sesión: compras una cantidad de inicios de sesión al mes, lo que sirve para cinco millones de clientes que inician sesión unas pocas veces al año. Iniciar sesión más de una vez el mismo día sigue contando como un solo inicio de sesión (Experience Cloud User Licenses (opens in a new tab), en inglés).

Así que cuando alguien dice “vamos a construir un portal de clientes”, mi siguiente pregunta no es qué plantilla. Es: ¿quiénes son los clientes, cuántos son, con qué frecuencia vienen, qué datos necesitan y qué pueden hacer con ellos?

Cuando la licencia da forma al modelo

A veces la licencia no solo elige el objeto; dobla todo el modelo. Algunas licencias de plataforma limitan a los usuarios a una aplicación personalizada de hasta diez objetos personalizados (Lightning Platform – One App, por ejemplo; Standard User Licenses (opens in a new tab), en inglés).

En uno de mis primeros proyectos, para una gran empresa de servicios profesionales y construcción, tuvimos que construir algo parecido a LinkedIn para toda la plantilla: los puestos, habilidades, certificaciones, idiomas y proyectos de cada persona, para poder encontrar al constructor de puentes certificado en un país determinado. Sin límite, habría construido un objeto usuario-puesto, usuario-habilidad, usuario-certificación, usuario-idioma y usuario-proyecto, además de listas de referencia de certificaciones y proyectos. Con una licencia de diez objetos, y con la indicación de no gastarlos todos, eso no era posible. Así que se convirtió en un juego de adivinanzas: ¿con qué pocos objetos puedo construir esto? La respuesta fue dos. Un objeto de referencia, con un tipo de registro por cada clase de lista (puesto, habilidad, certificación, idioma, proyecto), y un objeto de atributo de usuario, con los tipos de registro correspondientes, apuntando a él.

No era el modelo óptimo. Era un dolor hacer informes con él, y lo habría preferido más limpio. Pero es lo que permitía la licencia. A estos los llamo objetos navaja suiza: guarda el patrón en el bolsillo y, cuando los límites no dejan espacio, rompe el cristal y recurre a la separación por tipos de registro. Solo sabe a qué renuncias. Permisos distintos por tipo de registro pueden obligarte a dividir el objeto de todos modos.

Las personas ya no son los únicos usuarios

Hay otra pregunta de licencias que se ha vuelto importante: ¿qué pasa con lo que no son personas? Las integraciones tienen identidades. Los agentes tienen identidades. Salesforce tiene ahora una licencia Salesforce Integration para integraciones entre sistemas: solo API, no para personas, con cinco incluidas en cada organización Enterprise, Unlimited y Performance Edition (Standard User Licenses (opens in a new tab), en inglés). Así que no preguntes solo qué usuarios necesitan acceso. Pregunta qué identidades necesitan acceso: una persona, un cliente, un socio, una integración, un agente. Y luego qué necesita ver y hacer cada una.

Más allá del examen: lo que cambia la IA. A medida que los agentes se convierten en otro consumidor y creador de datos, la elección de objetos y las licencias ya no tratan solo de las pantallas de las personas. Sabe con qué identidad se ejecuta el agente, a qué puede llegar esa identidad y si el modelo pone los datos que necesita detrás de un objeto o un permiso que no puede usar.

Steve Trucking: uno fácil y uno difícil

Steve Trucking trabaja con socios minoristas. ¿Qué es un socio minorista? Un negocio. Fácil: cuenta. No creo Retail_Partner__c porque alguien usó la palabra “socio”.

Ahora el destinatario, la persona que recibe el refrigerador. ¿Contacto? ¿Cuenta personal? ¿Otra cosa? Un millón de destinatarios nuevos al año, que son clientes de los socios minoristas, no nuestros. Es exactamente el tipo de pregunta en la que no quiero saltar a un objeto antes de entender la relación, el acceso y la escala. Lo decidiremos en el punto de control de la Parte 1.

Lo que decide aquí un arquitecto

• Si un concepto de negocio encaja limpiamente con el propósito previsto de un objeto estándar, o si su significado o su peso son distintos.
• Si distintas etiquetas del negocio son entidades distintas o solo roles distintos de la misma.
• Si cada persona, usuario externo, integración y agente que necesita los datos puede llegar al objeto elegido con las licencias previstas.
• Cómo la población y el patrón de inicio de sesión (por miembro o por inicio de sesión) dan forma a la licencia y al modelo.
• Cuándo un límite de licencia justifica un modelo menos que óptimo, y lo que esa concesión cuesta en informes y permisos.

La idea no es que los objetos estándar sean buenos y los personalizados malos. Es que la elección tiene consecuencias, y a veces no la decide el sustantivo en absoluto, sino las personas, y las máquinas, que necesitan usarlo.

Explora

• Ayuda de Salesforce, Standard User Licenses (opens in a new tab) (en inglés), consultado el 2026-10-02 y de nuevo el 2026-10-12: los usuarios de Platform no tienen derecho a pronósticos, prospectos, campañas ni oportunidades; una aplicación personalizada de hasta 10 objetos personalizados; cinco licencias Salesforce Integration en cada organización Enterprise Edition.
• Ayuda de Salesforce, Experience Cloud User Licenses (opens in a new tab) (en inglés), consultado el 2026-10-02 y de nuevo el 2026-10-12: Partner Community no se puede usar con cuentas personales; Customer Community Plus para informes, tableros y uso compartido estándar; varios inicios de sesión en un día cuentan como uno.
• Ayuda de Salesforce, Supported Editions for Service Features (opens in a new tab) (en inglés), consultado el 2026-10-02 y de nuevo el 2026-10-12: acuerdos de nivel de servicio (gestión de derechos) con Agentforce Service; Knowledge con costo adicional en la mayoría de las ediciones.
• Ayuda de Salesforce, Available Feature Licenses (opens in a new tab) (en inglés), consultado el 2026-10-12: Service Cloud User, “Access the Salesforce Console for Service”; Marketing User para crear y gestionar campañas.