Modelado de Datos y Gestión

Las relaciones son el corazón del modelado de datos en Salesforce y representan el área más preguntada del examen en el dominio de Data Modeling.

Tabla comparativa completa:

Característica	Master-Detail (MD)	Lookup
Campo padre obligatorio	✅ Sí, siempre	❌ No, puede estar vacío
Eliminación en cascada	✅ Automática (se borran los hijos)	❌ No (se crean registros huérfanos)
Roll-Up Summary Fields	✅ Disponible nativamente	❌ No nativo (usar Flow o Apex)
OWD del registro hijo	Heredado del padre	Independiente del padre
Máximo por objeto	2	40
Reparenting (cambiar padre)	Configurable (desactivado por defecto)	✅ Siempre posible
Ownership del hijo	Controlado por el padre	Propio e independiente
Campo requerido	Siempre requerido	Configurable
En Standard Objects como hijo	❌ No se puede crear	✅ Sí

Relación Hierarchical (Jerárquica):
Tipo especial de Lookup que existe SOLO en el objeto User. Permite crear jerarquías de reporte (Manager → Employee). Se usa para definir la cadena de reportes y para Sharing Rules basadas en jerarquía.

Self-Relationship (Auto-relación):
Una Lookup relationship donde un objeto se relaciona consigo mismo. Ejemplo: Account padre → Account hija (Account Hierarchy). Útil para modelar estructuras corporativas.

Conversión entre tipos:
- Lookup → Master-Detail: Posible SOLO si todos los registros hijos ya tienen un valor en el campo padre (no hay valores nulos).
- Master-Detail → Lookup: Posible en cualquier momento.

Regla de oro para el examen:
- ¿Necesitas Roll-Up Summary o eliminación en cascada? → Master-Detail
- ¿El campo padre es opcional o necesitas OWD independiente? → Lookup
- ¿El hijo es un Standard Object (Account, Contact, etc.)? → Lookup (MD no permite standard objects como hijos)

Salesforce no soporta relaciones muchos-a-muchos directas. La solución es crear un Junction Object (objeto de unión) con dos relaciones Master-Detail.

Ejemplo práctico: Estudiante ↔ Curso
1. Crear objeto personalizado Inscripción__c (Junction Object).
2. Master-Detail #1: Inscripción__c → Estudiante__c (padre primario).
3. Master-Detail #2: Inscripción__c → Curso__c (padre secundario).

Comportamiento del Junction Object:
- El primer Master-Detail creado es el padre primario y controla:
- El OWD (Organization-Wide Default) del Junction Object.
- El look-and-feel del tab del Junction Object.
- El primer Lookup en las operaciones via Data Loader.
- Ambos padres pueden mostrar Related Lists del Junction Object.
- Ambos padres pueden tener Roll-Up Summary Fields que calculen datos del Junction.
- Se pueden añadir campos adicionales al Junction Object para almacenar datos de la relación (ej: Calificación__c, Fecha_Inscripción__c, Estado__c).

Otros ejemplos comunes de Junction Objects (preguntados en el examen):
- OpportunityLineItem (Estándar): Junction entre Opportunity y Product2.
- CampaignMember (Estándar): Junction entre Campaign y Lead/Contact.
- Asignación_Proyecto__c (Custom): Junction entre Empleado__c y Proyecto__c.

Reglas importantes:
- Un Junction Object necesita exactamente 2 relaciones Master-Detail.
- Un objeto puede ser padre en múltiples Junction Objects.
- No se puede crear más de 2 Master-Detail en el mismo objeto.
- Los Related Lists en ambos padres muestran automáticamente campos del Junction Object.

El conocimiento profundo de los tipos de campo es esencial para el examen.

Campos de Fórmula (Formula Fields):
- Campos de solo lectura que calculan un valor basado en otros campos.
- Soportan cross-object formulas: acceder a campos del padre (ej: Account.Industry).
- Pueden cruzar hasta 10 niveles de relaciones.
- Límite: 5,000 caracteres compilados (no caracteres visibles, sino compilados).
- Tipos de retorno: Texto, Número, Fecha, DateTime, Checkbox, Porcentaje, Moneda.
- NO se pueden usar en: criteria de Record-Triggered Flows (antes de guardar), ni como campo de ordenación en reportes.

Funciones de fórmula más preguntadas:
- ISBLANK(campo) / ISNULL(campo): Verifica si un campo está vacío. Usar ISBLANK (ISNULL es legacy).
- ISPICKVAL(picklist, 'valor'): Compara picklists. NO usar = para picklists.
- TEXT(picklist): Convierte picklist a texto para poder usar operadores de texto.
- PRIORVALUE(campo): Valor anterior al cambio (solo en updates).
- ISCHANGED(campo): TRUE si el campo cambió (solo en updates).
- ISNEW(): TRUE si el registro se está creando (no actualizando).
- CASE(campo, 'val1', resultado1, 'val2', resultado2, default): Switch/equivalencia.
- IF(condición, valorSi, valorNo): Condicional básico.
- HYPERLINK(url, label): Crea un enlace clicable.
- IMAGE(url, alt): Muestra una imagen.
- NOW() vs TODAY(): NOW = DateTime actual, TODAY = solo fecha.
- DATEVALUE(dateTime): Extrae la parte de fecha de un DateTime.
- YEAR(), MONTH(), DAY(): Extraen partes de una fecha.

Roll-Up Summary Fields:
- Calculan valores agregados en el objeto padre basados en registros hijos en una relación Master-Detail.
- Operaciones disponibles: COUNT, SUM, MIN, MAX.
- Se pueden aplicar criterios de filtro (ej: solo contar oportunidades 'Closed Won').
- NO disponibles en relaciones Lookup (usar Flow para simular).
- Solo se crean en el objeto padre, nunca en el hijo.

Picklists:
- Standard Picklist: Lista de valores simple.
- Multi-Select Picklist: Permite seleccionar múltiples valores (separados por punto y coma). Tiene limitaciones: no se puede usar en criteria de reportes fácilmente, no soporta ISPICKVAL.
- Global Value Set: Conjunto de valores reutilizable que se comparte entre múltiples picklists en diferentes objetos. Cambiar un valor en el Global Set lo cambia en todos los campos que lo usan.
- Dependent Picklist: Una picklist que muestra diferentes valores según la selección de otra picklist (controlling field). La controlling field puede ser un picklist estándar o un checkbox.

Otros campos importantes:
- Auto-Number: Genera número secuencial automáticamente (ej: CASE-{0000}). Es de solo lectura.
- External ID: Campo indexado para identificar registros en integraciones. Permite operaciones Upsert. Máximo 7 External IDs por objeto. Campos Text, Number o Email pueden ser External ID.
- Encrypted Field (Classic): Campo de texto cifrado. Solo usuarios con permiso 'View Encrypted Data' pueden ver el valor.
- Geolocation: Almacena coordenadas de latitud y longitud.

Los Record Types permiten ofrecer diferentes procesos de negocio, valores de picklist y page layouts para distintos tipos de registros dentro del mismo objeto.

¿Cuándo usar Record Types?
- Cuando diferentes grupos de usuarios necesitan ver diferentes campos o layouts para el mismo objeto.
- Cuando un objeto tiene múltiples propósitos (ej: 'Account' puede ser Cliente, Proveedor o Partner).
- Cuando necesitas diferentes valores de picklist según el contexto.

Record Types controlan:
1. Page Layouts: Diferentes diseños de página por Record Type + Perfil.
2. Picklist Values: Cada Record Type puede mostrar un subconjunto diferente de valores de picklist.
3. Business Processes: Para Opportunity (Sales Process), Lead (Lead Process), Case (Support Process).

Business Processes (Procesos de Negocio):
Son subconjuntos de las etapas estándar de ciertos objetos:

Objeto	Proceso	Campo controlado
Opportunity	Sales Process	Stage (StageName)
Lead	Lead Process	Lead Status
Case	Support Process	Case Status
Solution	Solution Process	Solution Status

Ejemplo: Puedes tener un Sales Process 'Enterprise Sales' con etapas detalladas (Prospecting → Qualification → Proposal → Negotiation → Closed Won/Lost) y otro 'Quick Sales' con solo 3 etapas (New → In Progress → Closed).

Asignación de Record Types:
- Los Record Types se asignan a Perfiles (y Permission Sets con el permiso correcto).
- Un perfil puede tener un Record Type por defecto por objeto.
- Si un perfil solo tiene acceso a un Record Type, NO se muestra el selector de Record Type al crear un registro.
- Si un perfil tiene acceso a múltiples Record Types, aparece un selector al crear.

Page Layout Assignment:
La asignación de Page Layouts es una matriz de Record Type × Perfil. Cada combinación puede tener un layout diferente.

Ejemplo:

Perfil Ventas	Perfil Soporte	Perfil Admin
RT: Cliente	Layout Ventas-Cliente	Layout Soporte-Cliente	Layout Admin
RT: Proveedor	Layout Ventas-Proveedor	Layout Soporte-Proveedor	Layout Admin

Schema Builder:
Herramienta visual que muestra objetos, campos y relaciones como un diagrama de entidad-relación interactivo.

Lo que PUEDE hacer Schema Builder:
- Visualizar relaciones entre objetos (Standard y Custom).
- Crear nuevos objetos personalizados directamente en el diagrama.
- Crear nuevos campos directamente arrastrando el tipo de campo al objeto.
- Ver el tipo de dato, nombre API y etiqueta de cada campo.
- Filtrar qué objetos se muestran en el diagrama.

Lo que NO PUEDE hacer Schema Builder (pregunta frecuente):
- ❌ Crear reglas de validación.
- ❌ Crear flows ni automatizaciones.
- ❌ Crear page layouts.
- ❌ Crear triggers ni código.
- ❌ Importar o exportar datos.
- ❌ Crear Record Types.

Herramientas de Importación de Datos:

Característica	Data Import Wizard	Data Loader
Límite de registros	50,000	Millones
Interfaz	Web (dentro de Setup)	Aplicación de escritorio / CLI
Objetos soportados	Accounts, Contacts, Leads, Solutions, Custom Objects	Todos los objetos
Deduplicación	✅ Integrada (por Salesforce ID, Name, Email)	❌ Manual
Operaciones	Insert, Update, Upsert	Insert, Update, Upsert, Delete, Hard Delete, Export, Export All
Programable	❌ No	✅ Sí (línea de comandos)
Importar Accounts+Contacts juntos	✅ Sí	❌ Por separado
External ID para matching	✅ Sí	✅ Sí

¿Cuándo usar cada herramienta?
- Data Import Wizard: Importaciones simples de menos de 50,000 registros, especialmente Accounts, Contacts o Leads. Perfecto para usuarios no técnicos.
- Data Loader: Importaciones masivas, operaciones programadas, borrado de datos, o cuando necesitas trabajar con objetos que DIW no soporta.

Operación Upsert (Update + Insert):
Combina actualización e inserción en una sola operación. Usa un External ID o el Salesforce ID para hacer matching:
- Si encuentra un registro existente con ese ID → Update.
- Si no encuentra → Insert (crea nuevo registro).

Data Export:
- Data Export Service: Herramienta nativa de Salesforce para exportar todos los datos de la org en archivos CSV. Disponible semanalmente (Professional) o mensualmente. Se accede desde Setup.
- Data Loader Export: Permite exportar registros de un objeto específico con filtros SOQL.
- Reports: También pueden exportar datos como CSV.

Mantener datos limpios es crítico en Salesforce. El examen pregunta sobre las herramientas nativas de calidad de datos.

Duplicate Rules (Reglas de Duplicados):
Controlan lo que sucede cuando un usuario intenta crear o editar un registro que es un duplicado.

Acciones configurables:
- Alert: Muestra una advertencia al usuario pero permite guardar.
- Block: Impide que el registro se guarde si es un duplicado.
- Se pueden configurar diferentes acciones para creación vs actualización.

Matching Rules (Reglas de Coincidencia):
Definen los criterios para identificar posibles duplicados. Una Matching Rule especifica qué campos comparar y con qué lógica.

Tipos de coincidencia:
- Exact: Los valores deben ser idénticos.
- Fuzzy: Permite coincidencias aproximadas (ej: 'Jon' vs 'John', 'Acme Inc' vs 'Acme Inc.').

Salesforce incluye Standard Matching Rules preconfiguradas para Account, Contact y Lead que usan fuzzy matching en campos como Name, Email, Street, City, Phone.

Relación entre Duplicate Rules y Matching Rules:
1. Se crea una Matching Rule que define los criterios de comparación.
2. Se crea una Duplicate Rule que referencia la Matching Rule y define la acción (Alert o Block).
3. Cuando un usuario guarda un registro, Salesforce ejecuta la Matching Rule → si detecta duplicados → aplica la acción de la Duplicate Rule.

Merge (Fusionar registros):
- Se pueden fusionar hasta 3 Accounts o 3 Contacts o 3 Leads a la vez.
- Al fusionar, se elige un registro maestro y los demás se eliminan.
- Los registros relacionados (Opportunities, Cases, etc.) se reasignan al registro maestro.
- Los campos del registro maestro se mantienen, pero se pueden elegir valores de los otros registros.

Otros conceptos de calidad de datos:
- Mass Transfer Records: Herramienta para cambiar el propietario de múltiples registros a la vez.
- Mass Delete Records: Eliminar registros en masa basándose en criterios de búsqueda.
- Recycle Bin: Los registros eliminados permanecen 15 días en la papelera y pueden restaurarse.

Ambos almacenan configuraciones personalizadas, pero tienen diferencias cruciales para el examen.

Custom Settings:
- Almacenan datos de configuración a nivel de organización, perfil o usuario.
- Dos tipos:
- List Custom Settings: Conjunto de datos reutilizable (como una tabla de configuración). Se accede con métodos getAll(), getInstance(name).
- Hierarchy Custom Settings: Tienen jerarquía Org → Profile → User. El valor más específico gana. Se accede con getInstance() que automáticamente respeta la jerarquía.
- Son datos (no metadatos), así que NO se migran con Change Sets automáticamente.
- Se pueden acceder en fórmulas con $Setup.NombreSetting__c.Campo__c.

Custom Metadata Types (CMT):
- Almacenan configuraciones como metadatos (no como datos).
- Sufijo __mdt en el nombre del tipo.
- Ventaja principal: Se despliegan con Change Sets y paquetes como cualquier metadato.
- Pueden usarse en:
- Fórmulas: $CustomMetadata.Tipo__mdt.Registro__mdt.Campo__c
- Validation Rules
- Flow Builder (Get Records)
- Apex code
- Son la opción recomendada por Salesforce para configuraciones deployable.

Comparación para el examen:

Característica	Custom Settings	Custom Metadata Types
Tipo de dato	Data (registros)	Metadata
Migrable con Change Sets	❌ No (solo estructura, no datos)	✅ Sí (estructura + registros)
Hierarchy support	✅ Sí (Hierarchy type)	❌ No
Acceso en fórmulas	✅ $Setup	✅ $CustomMetadata
SOQL para consultar	✅ Sí	✅ Sí (sin contar contra límites SOQL)
Recomendación Salesforce	Legacy (usar CMT)	✅ Preferido

Regla para el examen: Si una pregunta habla de configuraciones que necesitan deployarse entre entornos → Custom Metadata Types. Si necesitas valores diferentes por perfil/usuario → Hierarchy Custom Setting.