Lógica de Negocio y Automatización

Flow Builder es LA herramienta de automatización principal de Salesforce. Workflow Rules y Process Builder son legacy y no deben usarse para nuevos desarrollos.

Los 6 tipos de Flow:

1. Screen Flow:
- Presenta una interfaz visual (pantallas) al usuario para recopilar datos o guiar un proceso.
- Se lanza desde: botones, Quick Actions, Lightning Pages, utilidades, Experience Cloud pages.
- Soporta: inputs/outputs, navegación entre pantallas, validación en pantalla.
- Caso de uso: formularios de onboarding, wizards de creación de registros, asistentes guiados.

2. Record-Triggered Flow (Before Save):
- Se ejecuta ANTES de que el registro se guarde en la base de datos.
- NO consume operaciones DML al actualizar campos del mismo registro triggering (el más eficiente).
- Solo puede modificar el registro que activó el flow.
- NO puede: crear/actualizar otros registros, enviar emails, llamar a Apex, usar elementos de interacción.
- Caso de uso: auto-rellenar campos, normalizar datos antes de guardar.

3. Record-Triggered Flow (After Save):
- Se ejecuta DESPUÉS de que el registro se guarda en la base de datos.
- SÍ puede: crear/actualizar/eliminar otros registros, enviar emails, llamar a subflows.
- Consume operaciones DML para cada operación de base de datos.
- Caso de uso: crear registros relacionados, enviar notificaciones, actualizar registros padre.

4. Record-Triggered Flow (Async After Save):
- Variante asíncrona del After-Save. Se ejecuta en una transacción separada.
- Resuelve el error MIXED_DML_OPERATION (cuando necesitas modificar setup objects y non-setup objects).
- No bloquea al usuario — se ejecuta en segundo plano.
- Caso de uso: actualizar User records junto con registros de negocio.

5. Schedule-Triggered Flow:
- Se ejecuta a una hora y frecuencia programada (diaria, semanal).
- Consulta registros que cumplen criterios y ejecuta acciones sobre ellos.
- Caso de uso: enviar recordatorios semanales, actualizar estados de contratos vencidos, limpieza de datos.

6. Platform Event-Triggered Flow:
- Se activa cuando se publica un Platform Event.
- Para integraciones asíncronas y comunicación event-driven.
- Caso de uso: recibir eventos de sistemas externos, procesar actualizaciones en tiempo real.

Otros tipos:
- Autolaunched Flow (No Trigger): Se invoca programáticamente desde Apex, otros flows, o como subflows. No tiene trigger automático ni pantallas.

Tabla resumen de capacidades:

Capacidad	Screen	Before Save	After Save	Scheduled
Pantallas de usuario	✅	❌	❌	❌
Actualizar mismo registro	✅	✅ (0 DML)	✅	N/A
Crear/Actualizar otros registros	✅	❌	✅	✅
Enviar emails	✅	❌	✅	✅
Llamar a Apex	✅	❌	✅	✅
Ejecución	Manual	Automática	Automática	Programada

Flow Builder usa elementos visuales que se conectan para crear la lógica del proceso.

Elementos de Lógica:
- Decision: Bifurcación condicional (similar a IF/ELSE). Evalúa condiciones y dirige el flujo por diferentes caminos. Cada outcome tiene criterios (All conditions met / Any condition met / Custom formula).
- Loop: Itera sobre una colección de registros. Procesa un elemento a la vez. NUNCA poner DML/SOQL dentro de un Loop (causa errores de límites).
- Assignment: Asigna valores a variables. Operadores: Equals, Add, Subtract. Crítico para: añadir registros a colecciones, modificar valores de variables.
- Wait: Pausa el flujo hasta que se cumpla una condición temporal o un Platform Event. Solo disponible en Autolaunched Flows.

Elementos de Datos:
- Get Records: Consulta registros de la base de datos (equivalente a SOQL). Configurable por objeto, criterios de filtro, campos a recuperar y ordenación.
- Create Records: Inserta nuevos registros en la base de datos.
- Update Records: Actualiza registros existentes. Puede actualizar: el registro que disparó el flow, registros obtenidos con Get Records, o registros filtrados por criterios.
- Delete Records: Elimina registros de la base de datos.

Elementos de Pantalla (solo Screen Flows):
- Screen: Pantalla interactiva con componentes de formulario.
- Componentes disponibles: Text Input, Number Input, Date Input, Picklist, Radio Buttons, Checkboxes, Display Text, File Upload, Lookup, Data Table, Section, Toggle.
- Las pantallas pueden tener validaciones personalizadas que impiden avanzar si no se cumplen.

Elementos de Acción:
- Action (Invocable Action): Ejecuta acciones predefinidas: enviar email, enviar notificación personalizada, post en Chatter, invocar Apex, llamar a subflow.
- Subflow: Llama a otro Flow como un módulo reutilizable. Permite pasar variables de entrada y recibir variables de salida.

Variables en Flow:
- Variables simples: Text, Number, Currency, Boolean, Date, DateTime, Picklist.
- Record Variables: Almacenan un registro completo de un objeto.
- Collection Variables: Almacenan múltiples registros (colecciones/listas). Esenciales para el patrón de bulkificación.
- Constants: Valores que no cambian durante la ejecución.
- Formulas: Calculan valores dinámicos dentro del flow.
- Choice / Collection Choice Set: Para componentes de selección en pantallas.

Recursos del Flow (disponibles en todo el flow):
- $Record: El registro que activó un Record-Triggered Flow.
- $Record__Prior: Los valores ANTERIORES del registro activador (solo After-Save).
- $Api: Información de la sesión API.
- $Flow: Metadata del flow en ejecución.
- $GlobalConstant.EmptyString: String vacío (útil para comparaciones).
- $User: Información del usuario que ejecuta el flow.
- $Profile: Información del perfil del usuario.

Las Reglas de Validación evalúan una fórmula booleana. Si la fórmula retorna TRUE, el guardado se BLOQUEA y se muestra un mensaje de error.

Concepto fundamental: La fórmula describe la condición de ERROR, no la condición válida. Si quieres que un campo sea obligatorio cuando Stage es 'Closed Won', la fórmula debe evaluar a TRUE cuando el campo está vacío Y Stage es 'Closed Won'.

Funciones de fórmula más preguntadas en el examen:

Función	Descripción	Ejemplo
ISBLANK(campo)	TRUE si vacío	ISBLANK(Email)
ISPICKVAL(pick, 'val')	Compara picklist	ISPICKVAL(Stage, 'Closed Won')
PRIORVALUE(campo)	Valor anterior	PRIORVALUE(Status__c)
ISCHANGED(campo)	TRUE si cambió	ISCHANGED(OwnerId)
ISNEW()	TRUE si es creación	ISNEW()
CONTAINS(txt, 'sub')	Contiene subcadena	CONTAINS(Name, 'Test')
REGEX(txt, 'pattern')	Expresión regular	REGEX(Phone, '[0-9]{10}')
LEN(texto)	Longitud del texto	LEN(Description) > 500
NOT(condición)	Niega condición	NOT(ISBLANK(Email))
$Profile.Name	Nombre del perfil	$Profile.Name != 'System Admin'
$User.Id	ID del usuario actual	Para excepciones de usuario

Ejemplos prácticos (tipo examen):

*Ejemplo 1: Bloquear cierre de Opportunity sin Description:*

AND(
  ISCHANGED(StageName),
  ISPICKVAL(StageName, 'Closed Won'),
  ISBLANK(Description)
)

*Ejemplo 2: Solo Admin puede cambiar el propietario:*

AND(
  ISCHANGED(OwnerId),
  $Profile.Name != 'System Administrator'
)

*Ejemplo 3: El teléfono debe tener exactamente 10 dígitos:*

AND(
  NOT(ISBLANK(Phone)),
  NOT(REGEX(Phone, '[0-9]{10}'))
)

Ubicación del mensaje de error:
- Top of Page: El error aparece en la parte superior de la página.
- Field Level: El error aparece junto al campo especificado. Más fácil para el usuario identificar el problema.

Reglas importantes:
- PRIORVALUE(), ISCHANGED() solo funcionan en updates, NO en creación.
- ISNEW() solo funciona en creación.
- Las validaciones se ejecutan ANTES de los Before-Save Flows.
- Un objeto puede tener múltiples reglas de validación activas.
- Las reglas de validación aplican en TODOS los canales: UI, API, Data Loader, Flow.

Los Approval Processes automatizan la aprobación de registros mediante pasos configurables. Son una de las áreas más preguntadas del examen PAB.

Componentes de un Approval Process:

1. Entry Criteria: Condiciones que el registro debe cumplir para entrar al proceso (ej: Amount > 10,000).
2. Approver(s): Quién aprueba en cada paso. Opciones:
- Manager: El manager del usuario que envía (definido en la jerarquía de roles del User record).
- Queue: Una cola de aprobación.
- Specific User: Un usuario específico.
- Related User: Un usuario en un campo del registro (ej: el campo 'Manager__c').
3. Steps: Uno o más pasos de aprobación secuenciales. Cada paso puede tener diferentes aprobadores y criterios.
4. Actions:
- Initial Submission Actions: Se ejecutan cuando el registro se envía para aprobación (ej: bloquear edición, cambiar campo Status a 'Pending').
- Approval Actions: Se ejecutan cuando se aprueba (ej: cambiar Status a 'Approved', enviar email).
- Rejection Actions: Se ejecutan cuando se rechaza (ej: cambiar Status a 'Rejected', notificar al solicitante).
- Recall Actions: Se ejecutan cuando se retira la solicitud.
- Final Approval Actions / Final Rejection Actions: Se ejecutan al final de TODOS los pasos.

Record Lock:
Por defecto, cuando un registro entra en un Approval Process, se bloquea para edición (Record Lock). Solo el aprobador actual y los administradores pueden editarlo. Esto se puede configurar.

Cómo iniciar un Approval Process:
- Manual: El usuario hace clic en 'Submit for Approval' en el registro.
- Automático: Un Flow puede invocar un 'Submit for Approval' action.
- Apex: Código puede enviar registros para aprobación programáticamente.

Tipos de routing de aprobación:
- Unanimous: TODOS los aprobadores asignados deben aprobar.
- First Response: Basta con que el PRIMERO que responda apruebe o rechace.

Parallel Approvals (Aprobaciones Paralelas):
En un mismo paso, se pueden asignar múltiples aprobadores que revisan simultáneamente. Con routing 'Unanimous', todos deben aprobar. Con 'First Response', el primero que responda determina el resultado.

Ejemplo práctico:
Descuento en Opportunity:
- Entry Criteria: Discount__c > 20%
- Step 1: Aprobación del Manager directo.
- Step 2: Si Discount > 40%, aprobación del VP de Ventas.
- Initial Actions: Lock record, Status = 'Pending Approval'.
- Final Approval: Status = 'Approved', enviar email de confirmación.
- Final Rejection: Status = 'Rejected', notificar al vendedor.

Limitaciones importantes:
- Un objeto puede tener múltiples Approval Processes, pero un registro solo puede estar en uno a la vez.
- Los Approval Processes NO se pueden crear dentro de Flow Builder — se configuran en Setup.
- Los registros bloqueados por un Approval Process SOLO pueden ser editados por el aprobador actual o administradores (a menos que se desactive el lock).

Entender el Order of Execution es fundamental para diagnosticar problemas y diseñar soluciones correctas. Este es el orden en que Salesforce procesa un registro cuando se guarda:

Orden simplificado para el examen PAB:

1. System Validation Rules: Validaciones del sistema (campos requeridos, formato, unicidad).
2. Before Triggers (Apex): Triggers que se ejecutan antes de guardar.
3. Custom Validation Rules: Las reglas de validación que has creado.
4. Duplicate Rules: Verificación de duplicados.
5. Before-Save Record-Triggered Flows: Flows de tipo Before Save.
6. Record saved to database (pero no committed todavía).
7. After Triggers (Apex): Triggers que se ejecutan después de guardar.
8. Assignment Rules: Reglas de asignación (Lead/Case).
9. Auto-Response Rules: Respuestas automáticas.
10. After-Save Record-Triggered Flows: Flows de tipo After Save.
11. Entitlement Rules
12. Roll-Up Summary Fields: Se recalculan en el objeto padre.
13. Cross-Object Workflow/Flow updates: Actualizaciones en objetos relacionados.
14. Criteria-Based Sharing Rules: Evaluación de reglas de compartición.
15. DML committed to database: Los cambios se confirman definitivamente.
16. Post-Commit Logic: Envío de emails, llamadas futuras.

Puntos clave para el examen:

Pregunta	Respuesta
¿Qué se ejecuta primero: Validation Rules o Before-Save Flow?	Validation Rules (paso 3) antes de Before-Save Flow (paso 5)
¿Qué se ejecuta primero: Before Trigger o Validation Rule?	Before Trigger (paso 2) antes de Validation Rule (paso 3)
¿Cuándo se ejecuta After-Save Flow?	Después de que el registro se guarda en DB (paso 10)
¿Cuándo se recalculan los Roll-Up Summary?	Después de los After-Save Flows (paso 12)
¿Cuándo se envían los emails realmente?	En Post-Commit (paso 16), después de confirmarse todo

Implicación práctica: Si un Before-Save Flow depende de un valor que cambia en una Validation Rule o Before Trigger, ese cambio ya habrá ocurrido. Pero si un After-Save Flow actualiza un campo, las Validation Rules NO se re-ejecutan para esa actualización.

Las mejores prácticas de Flow son preguntadas constantemente en el examen. Memorizarlas es obligatorio.

1. NUNCA DML/SOQL dentro de un Loop:
La regla más importante. Si pones un Get Records, Create, Update o Delete dentro de un Loop, cada iteración consumirá una operación SOQL o DML. Con 200 registros, esto causa errores inmediatamente.

Patrón INCORRECTO ❌:

Loop (colección de Accounts)
  └── Get Records (buscar Contacts de cada Account)  ← SOQL dentro del loop
  └── Update Records (actualizar cada Contact)        ← DML dentro del loop

Patrón CORRECTO ✅ (Bulkificación):

Get Records (todos los Contacts relacionados) ← SOQL fuera del loop
Loop (colección de Contacts)
  └── Assignment (modificar y añadir a colección)
Update Records (colección completa) ← DML fuera del loop

2. Un solo Record-Triggered Flow por objeto:
Salesforce recomienda consolidar toda la lógica automática de un objeto en UN solo Record-Triggered Flow. Dentro del flow, usar elementos Decision para dirigir la lógica según los criterios.

Beneficios:
- Evita conflictos de orden de ejecución entre múltiples flows.
- Más fácil de mantener y debuggear.
- Mejor rendimiento.

3. Usar Before-Save siempre que sea posible:
Para actualizar campos del registro que disparó el flow, usar Before-Save (0 DML). Solo usar After-Save cuando necesites afectar OTROS registros.

4. Implementar Guard Clauses:
Al inicio del flow, verificar condiciones y usar el elemento Decision para salir temprano si no se cumplen los criterios. Evita ejecuciones innecesarias.

5. Usar Entry Conditions:
Configurar condiciones de entrada en el Record-Triggered Flow para que solo se active cuando es necesario. Ejemplo: solo ejecutar cuando Status__c es 'Closed'.

6. Evitar recursión infinita:
Si un After-Save Flow actualiza el mismo registro, puede re-dispararse. Usar la opción de configuración del flow: "A record update that satisfies the condition requirements" vs "Every time a record is updated" vs "Only if the record that triggered the flow is updated to meet the condition requirements".

7. Testing:
- Usar Debug en Flow Builder para probar con registros específicos.
- Probar con datos masivos (Data Loader) para validar que los límites no se excedan.
- Los flows se ejecutan en el contexto del usuario — considerar permisos.

8. Documentación:
- Nombrar flows descriptivamente: Account - Before Save - Auto-populate Fields.
- Usar Description en cada elemento del flow para explicar su propósito.
- Nombrar variables con prefijos: var_, col_, rec_ para claridad.

9. Manejo de errores:
- En Screen Flows, usar Fault Connectors para capturar errores y mostrar mensajes amigables.
- Configurar Fault Path en elementos de datos para manejar errores de DML graciosamente.

10. Subflows para reutilización:
Extraer lógica común en Autolaunched Flows que se invocan como Subflows. Esto promueve reutilización y reduce duplicación.