Arquitectura de datos 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)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp. — Imagen generada con IA

Guía de estudio del capítulo 3 del curso Data Architect. Lee primero los diez módulos; esta página te ayuda a comprobar lo que te quedó.

Sobre esta guía de estudio. Está construida solo con el contenido de este curso y con la lista de objetivos publicada en la guía del examen de Salesforce. Nunca se basa en preguntas reales del examen, y no pretende saber qué hay en el examen. Si ya hiciste el examen, por favor no me envíes preguntas: el acuerdo de certificación prohíbe compartirlas, y memorizar respuestas es, de todos modos, la forma equivocada de convertirse en arquitecto.

Este es el capítulo en el que el modelo se encuentra con la plataforma, y carga con buena parte del examen. Alimenta las dos secciones más grandes, Data Modeling and Database Design y Salesforce Data Management, cada una una cuarta parte del examen. Los números de la plataforma cambian: la lista de verificación da los que citan los módulos, con la fecha en que se comprobaron. Aprende para qué sirve cada límite, y comprueba el número actual antes de confiar en él.

Para el examen

Márcalos a medida que avanzas. Cada uno enlaza con el lugar donde se enseña.

DM-1: diseñar el modelo de datos en la plataforma

DM-2: un modelo que respeta el uso compartido y escala

Sé que un hijo de principal-detalle no tiene propietario ni tabla de uso compartido propios: el acceso sigue al principal. (La propiedad viene incluida en el paquete)
Conozco el sesgo padre-hijo: la recomendación de Salesforce es no superar unos 10.000 hijos por padre. (La pregunta de los 10.000 hijos)
Conozco el sesgo de propiedad (un usuario dueño de más de 10.000 registros de un objeto) y la recomendación: repartir la propiedad, o mantener a ese usuario fuera de la jerarquía de funciones o solo en la cima, y fuera de los grupos públicos que usan las reglas de uso compartido. (La propiedad puede convertirse en un problema de escala)
Conozco la tabla de uso compartido: el objeto de uso compartido de un objeto personalizado es Object__Share; un objeto de detalle no tiene ninguno, su acceso viene del principal; y un cambio de propietario elimina los usos compartidos manuales, pero conserva el uso compartido con Apex que tiene su propio motivo. (La tabla de uso compartido)
Puedo decidir quién es dueño de los registros que crean las integraciones y los agentes, según si la propiedad determina el uso compartido. (¿Quién es dueño de los registros que crean los sistemas?)

DM-4: objetos grandes frente a objetos estándar y personalizados

Conozco los tres hogares de los datos: en el núcleo (sObjects, con trabajo diario), referenciados (otro sistema es la fuente de la verdad: los objetos externos de Salesforce Connect, __x, o llamadas personalizadas) y archivados (en el núcleo en objetos grandes, __b, o fuera del núcleo en un almacén de datos). (En el núcleo y fuera del núcleo)
Sé que los objetos externos hacen una llamada externa cada vez que se tocan, así que importan la latencia y la disponibilidad del sistema de origen. (Referenciados)
Conozco los objetos grandes: volúmenes enormes, consultados por su índice con coincidencia exacta o por rango, sin interfaz ni informes estándar, solo permisos de objeto y de campo, sin automatización. (Archivados)
Sé que la mayoría de los registros cuentan como unos 2 KB de almacenamiento de datos sin importar los campos, y que los archivos se miden aparte, en el almacenamiento de archivos. (Dos columnas o doscientas, Archivos y adjuntos)

SDM-1: las licencias y los objetos que la gente puede usar

Conozco las tres licencias internas, Sales Cloud, Service Cloud y Platform, y lo que puede usar cada una. (Tres licencias internas)
Sé que las licencias son parte del modelo de datos: los usuarios de Salesforce Platform no tienen candidatos, campañas, oportunidades ni pronósticos, y los usuarios de Customer Community no pueden usar la oportunidad. (Ahora déjame complicarlo todo: las licencias)
Conozco los niveles de licencias externas: Customer Community, Customer Community Plus (informes, tableros, uso compartido estándar), Partner Community (objetos de ventas); y que Partner Community no se puede usar con cuentas personales. (El estadio)
Conozco las licencias por miembro y por inicio de sesión, y a qué población le conviene cada una. (Cómo pagan cambia el diseño)
Sé que algunas licencias de plataforma limitan a los usuarios a una aplicación de hasta diez objetos personalizados, y el patrón de tipos de registro para trabajar dentro de ese límite. (Cuando la licencia da forma al modelo)
Sé que la licencia Salesforce Integration es para usuarios de sistema a sistema, solo API. (Las personas ya no son los únicos usuarios)
Sé que los informes de SLA necesitan derechos e hitos, que necesitan licencias de Service. (Ahora déjame complicarlo todo: las licencias)

SDM-2: mantener los datos consistentes

Puedo poner una regla en el peldaño correcto de la escalera de la consistencia: tipo de campo y vocabulario, obligatorio y único, reglas de validación, reglas de duplicados, automatización. (Mantener los datos consistentes)
Sé que una lista de selección restringida rechaza los valores que no están en la lista, incluso a través de la API, y que un conjunto de valores global comparte una lista entre campos (hasta 1.000 valores). (Peldaño uno)
Sé que un requisito en el formato de página solo protege esa pantalla, no los datos, y que las reglas de validación se ejecutan en cada guardado. (La validación en la interfaz no es validación de datos, Peldaño tres)
Puedo delimitar una regla de validación con ISNEW() e ISCHANGED(), un permiso personalizado o una fecha de salida a producción, sabiendo qué guardados (incluidos los que no controlo, como un cambio de propietario masivo o un resumen acumulativo) sigue comprobando cada opción. (El problema de los registros antiguos)
Conozco las reglas de coincidencia y las reglas de duplicados, los límites que cita el módulo (cinco reglas de duplicados activas por objeto, tres reglas de coincidencia en cada una), y que no resuelven la identidad entre sistemas. (Peldaño cuatro: reglas de duplicados)
Sé que las reglas de duplicados no comparan registros guardados en el mismo momento, que los guardados por API y por importación se bloquean sin ninguna alerta, y que un guardado y todo lo que desencadena se revierten como una sola transacción. (Peldaño cuatro, Todo o nada)
Sé que Workflow Rules y Process Builder ya no tienen soporte; la automatización significa Flow o Apex. (Peldaño cinco: automatización)

Más allá del examen

El examen es el piso, no el techo. Estos son los hábitos de este capítulo que necesita un arquitecto, los pregunte o no el examen.

La plataforma tiene una forma. Diseña para la plataforma en la que estás, no para una base de datos genérica.
Mira a la nave nodriza. Mira cómo modela Salesforce un concepto antes de inventar uno.
Cada objeto es un compromiso: almacenamiento, límites, un modelo de uso compartido, licencias y dependencias.
Pregunta dónde viven los datos antes de elegir un objeto: en el núcleo, referenciados o archivados.
Lee cualquier nombre de API y sabrás quién lo creó, y qué puedes cambiar.
Si no estás archivando hoy, ¿vas a archivar alguna vez?
Haz un prototipo de los objetos grandes antes de proponerlos.
Nombres de negocio distintos no significan automáticamente objetos distintos.
Pregunta qué identidades necesitan los datos: personas, clientes, socios, integraciones y agentes.
Cada campo lleva una descripción, y clasificación donde importa.
Describe primero el comportamiento de la relación; la configuración lo implementa. No deformes el modelo para conseguir una función.
La pregunta de la eliminación: ¿qué debería pasarles a los hijos si alguien elimina al padre?
Elige qué vínculo corta la cadena: haz la búsqueda donde el hijo de verdad tiene vida propia.
La propiedad viene de la principal, el acceso de las dos: gana la más restrictiva.
Separa inactivo de desaparecido, y haz de la retención una regla de negocio.
Lleva la regla tan abajo como le corresponda de verdad, y dale al historial legítimo una excepción en lugar de reescribirlo.
El diagrama no es la arquitectura. Sé capaz de rastrear cada estructura hasta una razón de negocio.

Palabras que conviene conocer

Término	En una línea
Basado en metadatos	Los objetos y campos son definiciones que la plataforma lee en tiempo de ejecución, no tablas físicas nuevas
Multiinquilino	Muchas organizaciones comparten la infraestructura, cada una aislada, como departamentos en un edificio
Límites del gobernador	Límites que impiden que un inquilino monopolice los recursos compartidos
Objeto externo	Datos que se muestran en Salesforce mediante Salesforce Connect, y que se traen de su origen cada vez que se tocan
Objeto grande	Almacenamiento para datos muy voluminosos y poco usados, consultados por su índice
Cuenta personal	Una persona representada como una cuenta, para modelos de empresa a consumidor
Ajuste limpio	Un concepto de negocio que coincide con el propósito previsto de un objeto estándar
ID externo	Un campo que guarda el identificador de otro sistema, usado para upserts y emparejamientos
Upsert	Actualizar el registro si existe, crearlo si no
Búsqueda	Una relación en la que el hijo conserva su propio propietario y su propia vida
Principal-detalle	Una relación en la que el hijo pertenece al padre: propietario y uso compartido heredados, eliminación en cascada, resúmenes acumulativos
Objeto de unión lógico	La idea de modelado: un objeto que une a otros dos en una relación de muchos a muchos y lleva sus propios atributos, se construya como se construya
Salesforce Junction Object	Lo que Salesforce quiere decir con “junction object”: un objeto personalizado con dos relaciones principal-detalle
Principal primaria y secundaria	La principal-detalle creada primero de un Salesforce Junction Object (propietario, aspecto, división) y la segunda (alcance de los informes; pasa a ser la primaria si se elimina la primera)
Relación jerárquica	Una búsqueda especial solo en el objeto Usuario, como Gerente (Manager), que no puede volver al mismo usuario
Prefijo de espacio de nombres	El prefijo del proveedor en los objetos y campos de un paquete gestionado, como `abc__Inspection__c`
Tabla de uso compartido	El objeto de uso compartido (`AccountShare`, `Truck__Share`) que guarda la mayor parte del uso compartido de un registro, una fila por usuario o grupo, con su motivo
Resumen acumulativo	Un campo en el principal que cuenta, suma o encuentra el mínimo o el máximo de sus detalles
Sesgo de datos	Demasiados registros bajo un padre o un propietario, lo que provoca bloqueos y recálculos largos del uso compartido
Por miembro / por inicio de sesión	Pagar por cada usuario externo, o por cada inicio de sesión al mes
Escalera de la consistencia	Las capas que hacen cumplir las reglas de los datos, desde el tipo de campo hasta la automatización
Lista de selección restringida	Una lista de selección que rechaza cualquier valor que no esté en su lista, venga de donde venga
Clasificación de datos	Metadatos del campo sobre el dueño, el uso, la confidencialidad y la categoría de cumplimiento

Ponte a prueba

Escenarios cortos al estilo del curso. Decide tu respuesta antes de abrirla.

1. Los usuarios necesitan ver los detalles de pedidos que son propiedad del ERP y que este actualiza todo el día. No los editan en Salesforce. ¿Copiarlos o no?

Referéncialos: los objetos externos mediante Salesforce Connect mantienen el ERP como fuente de la verdad sin ninguna copia que sincronizar. Acepta que cada visualización hace una llamada externa, así que importan la latencia y la disponibilidad del ERP, y que sirve mejor para la lectura que para mucha edición o muchos informes. Vuelve a leer Referenciados.

2. El negocio quiere llevar el seguimiento de distribuidores, proveedores y socios minoristas. ¿Tres objetos personalizados?

No. Todos son empresas, así que la cuenta encaja limpiamente; los distintos nombres son roles, que lleva un tipo, un tipo de registro o una relación. Vuelve a leer La prueba del ajuste limpio.

3. Un diseño usa la oportunidad, pero la mayoría de quienes necesitan los datos tienen licencias Salesforce Platform o Customer Community. ¿Y ahora?

Esas licencias no pueden usar la oportunidad, así que la licencia es una restricción de arquitectura: comprar otras licencias, mover la experiencia o rediseñar, normalmente hacia un objeto personalizado. Vuelve a leer Ahora déjame complicarlo todo: las licencias.

4. El ERP envía actualizaciones nocturnas de las cuentas. ¿Cómo debería encontrar la integración el registro correcto sin consultar los ID de Salesforce?

Guarda el número de cliente del ERP en un campo de ID externo y haz upsert sobre él: actualiza si lo encuentra, crea si no. Los registros hijos también pueden apuntar a su padre por su ID externo. Vuelve a leer ID externos.

5. Un artículo de entrega no puede existir sin su entrega, nunca se mueve y no necesita propietario propio. Una entrega existe antes de tener ruta y puede pasar a otra ruta. ¿Qué relación para cada uno?

Artículo de entrega a Entrega: principal-detalle (pertenece al padre de por vida, hereda el acceso, se elimina en cascada). Entrega a Ruta: una búsqueda (vida propia, opcional al principio, se puede mover, y eliminar una ruta nunca debe eliminar entregas). Vuelve a leer Empieza por la relación de negocio.

6. Una integración crea 3.300 entregas al día, todas propiedad del usuario de integración, que tiene una función en mitad de la jerarquía. ¿Cuál es el riesgo y cuál la solución?

Sesgo de propiedad: pasados los 10.000 registros, mover a ese usuario o cambiar sus grupos provoca recálculos largos del uso compartido. Reparte la propiedad si importa para el acceso; si no, mantén al usuario de integración fuera de la jerarquía de funciones, o solo en una función en la cima, y fuera de los grupos que usan las reglas de uso compartido. Vuelve a leer La propiedad puede convertirse en un problema de escala.

7. Agregas una regla de validación y 20.000 registros antiguos la incumplen. Un usuario edita un número de teléfono en uno de ellos y el guardado falla. ¿Qué debería haber hecho la regla?

Decir cuándo hacerse cumplir, no solo qué tiene que ser cierto: delimitarla con ISNEW() o ISCHANGED() en los campos relevantes, y darles a los registros anteriores a la regla una excepción deliberada en lugar de reescribir su historial. Vuelve a leer El problema de los registros antiguos.

8. El negocio quiere cada foto de entrega "en Salesforce": de cuatro a cinco millones al año, creciendo un 30 %. ¿Qué propones?

Separar el acceso del almacenamiento. Guarda los archivos en un almacenamiento construido para ese volumen, fuera de la organización principal, y conserva en Salesforce una referencia, un recuento o un registro de índice para que los usuarios puedan encontrarlos y verlos. Vuelve a leer Fotos.

9. Una asignación de equipo (Crew Assignment) tiene relaciones principal-detalle con Equipo (creada primero) y con Camión. Un despachador puede ver el equipo, pero no el camión. ¿Puede ver la asignación de equipo?

No. Equipo es la principal, así que le da a la asignación su propietario y su aspecto, pero el acceso necesita a los dos padres: el despachador necesita acceso al equipo y al camión, con el nivel que pide la configuración de uso compartido (Sharing Setting) de cada campo principal-detalle. Gana el más restrictivo. Vuelve a leer Dos padres de ancho.

10. Un socio reenvía un archivo de manifiesto, y el mismo cliente aparece dos veces en él. Tienes una regla de duplicados en la cuenta configurada para bloquear. ¿Estás a salvo?

No solo con la regla de duplicados. Los registros guardados en el mismo momento no se comparan entre sí, solo con los registros que ya están en Salesforce, así que las dos filas pueden pasar. Lleva la unicidad hasta el campo: un ID externo único, que la plataforma comprueba en cada guardado, así que solo uno gana. Vuelve a leer Peldaño cuatro: reglas de duplicados y Todo o nada.

Explora

Guía del examen Salesforce Certified Platform Data Architect (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-09-25): la lista oficial de objetivos y sus pesos. Revisa siempre la versión actual antes de reservar el examen.
La sección Explora de cada módulo enumera la documentación de Salesforce detrás de sus datos de la plataforma, con la fecha en que se comprobó.