La Respuesta Corta
Un buen modelo de datos en Salesforce no es el más hermoso teóricamente, sino aquel que sostiene simultáneamente tres elementos: el proceso de negocio, el modelo de permisos y los informes requeridos. La mayoría de los modelos fallidos se construyen únicamente en torno al primero.
La diferencia entre una decisión de modelo y otras decisiones en un proyecto radica en el costo del cambio. Cambiar un Flow toma un día; cambiar el tipo de relación entre objetos después de dos años de datos, automatizaciones e integraciones es un proyecto en sí mismo. Por lo tanto, la inversión en la fase de planificación rinde frutos aquí más que en cualquier otro lugar.
La Primera Regla: Comenzar con los Objetos Estándar
Account, Contact, Lead, Opportunity, Case y Product traen consigo capacidades que no se obtienen de forma gratuita con un objeto personalizado: procesos de venta, Forecasting, Entitlements, Omni-Channel, aplicación móvil e integración incorporada con otros productos de la plataforma.
Una organización que crea Customer__c en lugar de Account inicialmente obtiene un modelo que parece más limpio, y luego descubre que cada capacidad predefinida requiere una construcción independiente. La regla: solo se desvía del estándar cuando existe una razón que se puede escribir en una frase.
¿Cuándo se Requiere un Objeto Personalizado?
| Situación | ¿Objeto Personalizado? | Justificación |
|---|---|---|
| Contrato/Suscripción con ciclo de vida propio | Sí | Estados, renovación, propiedad e informes separados |
| Activo instalado en un cliente | Sí (o Asset estándar) | Entidad independiente con historial de servicio |
| "Cliente potencial" adicional | No | Es un Lead o una Account con un Record Type |
| Departamento en la organización | No | Dato sobre un usuario, no una entidad |
| Líneas de precios complejas | Depende | Evaluar Quote Line o CPQ antes de construir |
Normalización vs. Desnormalización: La Decisión que Afecta los Informes
En las bases de datos clásicas, la normalización es una virtud. En Salesforce, esta se negocia por la comodidad de los informes: cada nivel adicional de relación dificulta la construcción de un informe sin una herramienta externa, porque los informes estándar están limitados en la profundidad de las relaciones.
El compromiso aceptado es la normalización donde los datos cambian y se duplican, y una desnormalización controlada de campos de consulta comunes hacia el objeto desde el cual se informa, siempre que la duplicación se gestione automáticamente y no manualmente. Un campo duplicado que se actualiza mediante entrada manual se convierte en una falsedad en cuestión de meses.
Los Permisos son Parte del Modelo, no una Etapa Posterior
La pregunta "¿quién ve qué?" debe hacerse al diseñar los objetos. Un modelo en el que un dato sensible reside en el mismo objeto que un dato operativo obliga posteriormente a soluciones indirectas, como un objeto sombra, campos cifrados o una apertura de visibilidad demasiado amplia.
La prueba práctica: por cada nuevo objeto, se escribe una línea: quién es el propietario, quién lee, quién modifica y qué sucede en la jerarquía. Si la respuesta requiere más de cuatro líneas, la estructura probablemente mezcla dos entidades.
Puede encontrar una expansión sobre las fuentes de información y la autoridad de actualización en Source of Truth en la organización, y sobre la gestión de entidades principales en Master Data Management.
Escenario: Empresa de Software que Construyó un Modelo en Torno a los Departamentos
Una empresa SaaS de tamaño medio construyó un modelo con cuatro objetos personalizados, uno para cada equipo de ventas, porque cada equipo tenía un proceso diferente. Un año y medio después se produjo una fusión de equipos, y entonces se requirieron: consolidación de informes, automatizaciones paralelas en cuatro lugares y una migración interna de 60 mil registros entre objetos.
La reconstrucción se basó en una única Opportunity con Record Types para los diferentes procesos. Se mantuvo la misma distinción de negocio (diferentes rutas de venta, diferentes campos, diferentes Page Layouts), pero a nivel de configuración y no a nivel de estructura. El próximo cambio organizativo requerirá un cambio de Record Type, no una migración.
La regla que surgió de esto: la estructura representa entidades; la configuración representa la organización. Lo que se espera que cambie cada dos años no debería vivir en la estructura.
Rendimiento y Volumen: Lo que Realmente Importa
Los problemas de rendimiento en un modelo de datos provienen principalmente de tres lugares: Data Skew (un único padre con decenas de miles de hijos, por ejemplo, la Account "clientes individuales"), fórmulas anidadas que calculan en tiempo real a través de relaciones, y el compartir basado en Apex Sharing creado a gran escala. Los tres pueden identificarse en la fase de planificación si se pregunta cuántos registros se esperan bajo cada padre.
Riesgos Comunes y Acciones Preventivas
| Riesgo | Cómo se Manifiesta en la Práctica | Acción Preventiva |
|---|---|---|
| Objeto Personalizado Innecesario | Capacidades predefinidas se construyen manualmente de nuevo | Revisar el Objeto Estándar antes de cada nuevo objeto |
| Master-Detail Demasiado Temprano | Eliminaciones en cascada y una estructura inmutable | Comenzar con Lookup si no se necesita un Roll-Up |
| Modelo que Refleja la Organización | Cada cambio organizativo se convierte en una migración | Record Types en lugar de objetos |
| Data Skew | Bloqueos y lentitud en actualizaciones masivas | Distribución de padres, verificación de volumen en la planificación |
| Permisos como Consideración Tardia | Soluciones indirectas y visibilidad demasiado amplia | Matriz de acceso para cada objeto durante la planificación |
Cómo Medir el Éxito
| Área | Qué se Mide | Frecuencia de Evaluación |
|---|---|---|
| Uso de Campos | Tasa de completitud por cada campo | Trimestral |
| Informes | Porcentaje de informes que requieren consolidación manual | Trimestral |
| Estabilidad de la Estructura | Número de cambios estructurales por semestre | Semestral |
| Rendimiento | Tiempos de actualización masiva y bloqueos | Mensual |
La planificación del modelo de datos como parte de una arquitectura integral se lleva a cabo dentro del marco del servicio de integraciones y datos.
Checklist Antes de Congelar el Modelo
- ☐ Por cada objeto personalizado existe una justificación en una frase.
- ☐ Se ha revisado un Objeto Estándar alternativo para cada entidad.
- ☐ El tipo de relación se ha elegido explícitamente con una justificación para Master-Detail.
- ☐ Se ha estimado el volumen esperado para cada padre (verificación de Skew).
- ☐ Matriz de acceso: propietario, lector, modificador, jerarquía.
- ☐ Se ha verificado que cada informe central se pueda construir en el modelo.
- ☐ Los campos duplicados se actualizan solo automáticamente.
- ☐ Los cambios organizativos esperados se manejan en la configuración.
- ☐ Existe un ERD actualizado y documentado.
- ☐ Se ha determinado quién aprueba los cambios estructurales futuros.
Fuentes Profesionales
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data