Fundamentos de la Plataforma Salesforce

Salesforce es una plataforma cloud-based (basada en la nube) que opera bajo un modelo multitenant (multiinquilino). Esto significa que todas las organizaciones (clientes) comparten la misma infraestructura física — servidores, base de datos y código base — pero cada organización tiene sus datos y configuraciones completamente aislados.

¿Por qué es importante el modelo multitenant?
- Actualizaciones automáticas: Salesforce lanza 3 actualizaciones al año (Winter, Spring, Summer) que se aplican a todas las orgs simultáneamente sin intervención del cliente.
- Sin gestión de infraestructura: No hay servidores que mantener, actualizar ni escalar.
- Economía de escala: Al compartir recursos, el costo por usuario se reduce.

Arquitectura Metadata-Driven (Orientada a metadatos):
Salesforce separa los datos de los metadatos. Los metadatos definen la estructura y el comportamiento de la plataforma: objetos, campos, flujos, page layouts, perfiles, etc. Cuando un administrador crea un campo personalizado, está creando un metadato — no está modificando la estructura de la base de datos directamente.

Esta arquitectura permite que cada org tenga una configuración completamente diferente sin modificar el código base compartido.

Governor Limits (Límites de Gobernador):
Para garantizar que ningún inquilino monopolice los recursos compartidos, Salesforce impone límites estrictos:

Recurso	Límite
Campos personalizados por objeto	800
Relaciones por objeto (Lookup + MD)	40 (25 Lookup + 2 MD)
Reglas de validación por objeto	500
Objetos personalizados por org	2,000 (Enterprise Edition)
Caracteres compilados en fórmula	5,000
Record-Triggered Flows por objeto	Sin límite fijo, pero se recomienda 1
Consultas SOQL por transacción (sync)	100
Registros DML por transacción	10,000

Concepto clave para el examen: Si una pregunta describe un escenario donde un proceso falla sin explicación aparente, consider si se está violando un Governor Limit.

Los objetos en Salesforce son equivalentes a tablas en una base de datos relacional. Cada objeto contiene campos (columnas) y registros (filas).

Objetos Estándar (Standard Objects):
Vienen incluidos con Salesforce y tienen funcionalidad predefinida:

Objeto	Función principal	Relación clave
Account	Empresas, organizaciones	Padre de Contact, Opportunity, Case
Contact	Personas asociadas a cuentas	Hijo de Account
Opportunity	Negocios/ventas potenciales	Tiene etapas (Stage) y valores monetarios
Lead	Prospectos sin calificar	Se convierte en Account + Contact + Opportunity
Case	Problemas/solicitudes de soporte	Tiene estado, prioridad, origen
Campaign	Marketing y campañas	Relacionado con Leads y Contacts
Task / Event	Actividades	Polimórficos (WhatId, WhoId)
Product / Pricebook	Catálogo y precios	Products se asocian a Opportunities via OpportunityLineItem

No se pueden eliminar pero sí personalizar añadiendo campos, modificando page layouts y creando reglas de validación.

Objetos Personalizados (Custom Objects):
Creados para necesidades específicas del negocio. Se identifican por el sufijo __c (ejemplo: Proyecto__c, Factura__c).

Para que un custom object sea visible necesitas:
1. Crear una Custom Tab (pestaña) para el objeto.
2. Configurar el Page Layout con los campos deseados.
3. Asignar permisos CRUD en el Perfil o Permission Set del usuario.
4. Incluir la Tab en la Lightning App correspondiente.

External Objects (Objetos Externos):
Se identifican por el sufijo __x. Conectan con datos almacenados fuera de Salesforce (SAP, bases de datos externas) sin importar los datos. Usan Salesforce Connect (OData o Cross-Org adapter). Los datos se consultan en tiempo real.

Big Objects:
Diseñados para almacenar volúmenes masivos de datos (miles de millones de registros) como datos históricos o de auditoría. Sufijo __b. Tienen funcionalidad limitada (no soportan triggers, flows ni reportes estándar).

Comparación de sufijos (pregunta frecuente de examen):

Sufijo	Tipo	Ejemplo
(ninguno)	Objeto estándar	Account, Contact
__c	Objeto/campo personalizado	Factura__c, Monto__c
__r	Referencia a relación	Account__r.Name
__x	Objeto externo	SAP_Order__x
__b	Big Object	Audit_Log__b
__mdt	Custom Metadata Type	Config_Setting__mdt
__e	Platform Event	Order_Placed__e

Una de las preguntas más importantes del examen PAB es saber cuándo usar una solución declarativa (sin código) vs programática (con código).

Herramientas Declarativas (Point-and-Click):
- Flow Builder (automatización)
- Validation Rules (reglas de validación)
- Formula Fields (campos de fórmula)
- Process Builder (legacy, no usar para nuevos desarrollos)
- Workflow Rules (legacy)
- Approval Processes (procesos de aprobación)
- Lightning App Builder (diseño de interfaces)
- Schema Builder (modelado visual de datos)
- Report Builder (reportes y dashboards)
- Page Layouts, Record Types, Quick Actions

Herramientas Programáticas (requieren código):
- Apex: Lenguaje de programación similar a Java para lógica de servidor compleja.
- Visualforce: Páginas web personalizadas (legacy, reemplazado por LWC).
- Lightning Web Components (LWC): Componentes de interfaz modernos basados en estándares web.
- SOQL/SOSL: Lenguajes de consulta para datos.
- Apex Triggers: Lógica que se ejecuta antes/después de operaciones de base de datos.

Regla de Salesforce para el examen: SIEMPRE preferir la solución declarativa a menos que sea técnicamente imposible. Salesforce promueve el principio "clicks, not code".

¿Cuándo SÍ necesitas código (Apex/LWC)?
- Lógica que requiere más de 100 consultas SOQL en una transacción.
- Integraciones complejas con web services externos (REST/SOAP callouts).
- Interfaces de usuario altamente personalizadas que no se pueden crear con componentes estándar.
- Procesamiento masivo de datos (Batch Apex).
- Lógica en tiempo real con requisitos de rendimiento extremos.
- Funcionalidad que no existe en las herramientas declarativas.

¿Cuándo basta con Flow + herramientas declarativas?
- Crear o actualizar registros basándose en criterios.
- Enviar emails basados en cambios de registro.
- Crear formularios dinámicos para usuarios (Screen Flows).
- Automatizar aprobaciones.
- Programar tareas recurrentes (Schedule-Triggered Flows).
- La mayoría de la lógica de negocio estándar.

Una Lightning App es un contenedor que agrupa objetos, tabs, componentes de utilidad y branding para un caso de uso específico del negocio.

Tipos de Lightning Apps:

Tipo	Descripción	Ejemplo
Standard Navigation App	Navegación por pestañas horizontal	Custom Sales App
Console App	Workspace con múltiples registros abiertos en sub-pestañas	Service Console
Connected App	Integra aplicaciones externas vía OAuth 2.0	Integración con app externa

Diferencias clave Standard vs Console:
- Standard: Cada registro abre en una pestaña principal. Simple e intuitiva.
- Console: Permite abrir múltiples registros simultáneamente en sub-tabs sin perder contexto. Ideal para agentes de soporte que trabajan con varios casos a la vez. Incluye funcionalidades como Split View y Pinned Tabs.

Componentes de una Lightning App:
1. Navigation Items: Tabs de objetos estándar, personalizados, o elementos como listas, dashboards o páginas web.
2. Utility Bar: Barra fija en la parte inferior de la pantalla con widgets siempre accesibles (Notes, History, Recent Items, Macros, Softphone). Los elementos de Utility Bar persisten al navegar entre pestañas.
3. Branding: Logo personalizado, colores de marca.
4. App Assignment: Las apps se asignan a perfiles específicos. Un usuario solo ve las apps asignadas a su perfil.

App Manager (Setup > App Manager):
- Crear, editar y eliminar Lightning Apps.
- Configurar Navigation Items y Utility Items.
- Asignar apps a perfiles.
- Establecer el app como visible, default, o ambas para cada perfil.
- Crear Connected Apps para integraciones OAuth.

Custom Tabs:
Las pestañas (tabs) son la puerta de entrada a los objetos en Salesforce:
- Object Tabs: Apuntan a un objeto estándar o personalizado.
- Web Tabs: Enlazan a una URL externa.
- Lightning Component Tabs: Muestran un componente Lightning personalizado.
- Lightning Page Tabs: Muestran una Lightning Page creada en App Builder.
- Visualforce Tabs: Muestran una página Visualforce (legacy).

AppExchange es el marketplace de Salesforce donde se instalan aplicaciones (apps), componentes Lightning y soluciones de terceros. Es como la "app store" de Salesforce.

Tipos de listado en AppExchange:
- Apps (Managed Packages): Soluciones completas empaquetadas (ej: DocuSign, Conga).
- Lightning Components: Componentes individuales reutilizables en App Builder.
- Flow Templates: Plantillas de automatización preconstruidas.
- Bolt Solutions: Plantillas de comunidades/portales.
- Consulting Partners: Servicios de consultoría (no software).

Importante para el examen: Las soluciones de AppExchange pasan por un Security Review obligatorio por parte de Salesforce antes de ser publicadas.

Ediciones de Salesforce:

Edición	Custom Objects	Storage	Sandbox	Para quién
Essentials	5	Limitado	No	Pequeñas empresas
Professional	50	10 GB	Developer	PYMES
Enterprise	200	10 GB + 20MB/usr	Dev + Dev Pro + Partial	Empresas medianas-grandes
Unlimited	2,000	10 GB + 120MB/usr	Todos los tipos	Grandes empresas
Developer Edition	400	5 MB	No (es un sandbox en sí)	Desarrollo y testing

Para el examen: Enterprise Edition es la referencia estándar. La mayoría de preguntas asumen Enterprise.

Tipos de Entorno (Environments):
- Production: Entorno en vivo con datos reales de negocio. Solo hay UNO.
- Sandbox: Copia del entorno de producción para desarrollo y testing. Se pueden tener múltiples.
- Developer Edition: Org gratuita para aprender y desarrollar (NO es un sandbox).
- Scratch Org: Entorno temporal para desarrollo (Salesforce DX). Se autodestruye tras un período configurado.
- Trailhead Playground: Org gratuita para practicar en Trailhead.

Concepto importante: Production y Sandbox están conectados (misma org), lo que permite usar Change Sets para migrar configuraciones. Developer Edition y Scratch Orgs son orgs independientes.