🔥

Automatización: Flows, Aprobaciones y Orden de Ejecución

Lógica de automatización, disparadores de flujo y mejores prácticas (el núcleo del examen).

⏱️ Tiempo estimado de lectura: 40 minutos

Tipos de Flow: Escenarios de Examen

Identificar el tipo correcto es la primera pregunta del examen.

1. Screen Flow: Requiere UI. (Ej: Guion de llamadas, Encuesta).
2. Record-Triggered Flow: Automático al crear/editar/borrar. (Ej: Actualizar campo, Enviar email).
3. Schedule-Triggered Flow: Batch/Lotes. (Ej: Diario a las 8 AM, buscar tareas vencidas).
4. Autolaunched (No Trigger): Procesos de fondo invocados por Apex/Botones.
5. Platform Event-Triggered: Integraciones externas (IoT, ERP).

Puntos Clave

  • Screen Flows nunca se disparan solos; necesitan un humano o una acción
  • Record-Triggered es el reemplazo directo de Workflow Rules y Process Builder
  • Delete Trigger solo funciona en 'Before Delete'

Optimización Crítica: Before-Save vs After-Save

Entender esto es la clave del rendimiento.

Fast Field Updates (Before Save):
- Se ejecuta ANTES de guardar en la base de datos.
- Uso: Actualizar campos en el *mismo* registro que disparó el flow.
- Ventaja: 10 veces más rápido. No provoca recursividad.

Actions and Related Records (After Save):
- Se ejecuta DESPUÉS de guardar.
- Uso: Crear/Actualizar *otros* registros (hijos, padres), enviar emails, o acciones complejas.
- Regla: Si necesitas el ID del registro (ej: para crear un hijo), DEBES usar After Save.

Puntos Clave

  • ¿Necesitas enviar un email? -> After Save
  • ¿Actualizar campo en el mismo registro? -> Before Save
  • ISCHANGED() y PRIORVALUE() son esenciales para detectar cambios específicos
  • Usa 'Entry Criteria' para que el Flow no se ejecute innecesariamente

Anatomía del Flow: Variables y Recursos

Los Flows usan Recursos para manejar datos.

- Variable: Contenedor de datos (Texto, Número).
- *Available for Input:* Recibe datos externos (ej: recordId).
- Record Variable: Almacena un registro completo.
- Collection Variable: Almacena una LISTA de registros (vital para Bucles).
- Formula: Calcula valores dinámicamente.

Variable Mágica: Para pasar el ID del registro actual a un Screen Flow, la variable DEBE llamarse recordId (exacto) y ser Input.

Puntos Clave

  • $Record: Variable global con los datos del registro que disparó el Flow
  • $Record__Prior: Contiene los datos ANTES del cambio
  • $User: Información del usuario que ejecuta el Flow

Lógica de Bucles y 'Bulkification' (El Error #1)

Salesforce tiene límites estrictos (Governor Limits).

Pecado Capital: NUNCA pongas elementos de Datos (Get, Create, Update, Delete) DENTRO de un Loop. Si lo haces, el Flow fallará al procesar muchos registros.

El Patrón Seguro:
1. Loop: Itera sobre la lista.
2. Assignment: Modifica el registro en memoria y añádelo a una nueva colección.
3. Cerrar Loop.
4. Update Records: Ejecuta la actualización UNA VEZ fuera del bucle usando la colección.

Puntos Clave

  • Límite DML: Máximo 150 llamadas a base de datos por transacción
  • Elemento 'Assignment' es el único seguro dentro de un Loop
  • Bulkification significa diseñar el Flow para manejar 1 o 1000 registros sin romper los límites

Depuración, Errores y Contexto de Seguridad

Debug on Canvas: Permite probar el Flow simulando ser otro usuario. Vital para comprobar si los permisos afectan la ejecución.

Contexto de Ejecución:
- User Context: El flow respeta los permisos del usuario. Si no puede editar un campo, falla.
- System Context: El flow ignora los permisos (Modo Dios). Los Record-Triggered Flows siempre corren así.

Fault Paths: Si un elemento falla (ej: error de validación), debes conectar una 'Fault Path' (línea roja) a una pantalla de error o email para evitar que el usuario vea un mensaje técnico incomprensible.

Puntos Clave

  • Rollback Mode: Ejecuta el test sin guardar cambios en la base de datos
  • Los Flows fallidos envían un email al administrador con los detalles técnicos
  • Screen Flows corren por defecto en User Context (según quién lo usa)

Distribución: ¿Cómo ven los usuarios los Screen Flows?

Crear un Screen Flow no lo hace visible automáticamente.

Métodos de Distribución:
1. Lightning Pages: Componente 'Flow' en App Builder.
2. Quick Actions: Botón personalizado (Ideal para Móvil).
3. Utility Bar: Barra inferior fija.
4. Experience Cloud: Portales externos.

Nota: Los usuarios necesitan el permiso 'Run Flows' en su perfil.

Puntos Clave

  • Puedes controlar la visibilidad del componente Flow en la página con filtros (ej: Ocultar si Estado = Cerrado)
  • Los Flows activos no se pueden editar, debes guardar una nueva versión

Procesos de Aprobación y Migración

Approval Processes: Únicos por el Record Locking (bloqueo de registro).
- Pasos: Entrada -> Bloqueo -> Aprobación (Unanimidad vs Primero) -> Acciones.
- Delegated Approver: Un usuario puede designar a un sustituto temporal.

Migración: La herramienta 'Migrate to Flow' convierte Workflow Rules y Process Builder a Flow. No puede migrar todo (ej: mensajes salientes SOAP).

Puntos Clave

  • Un Flow puede 'enviar' un registro a aprobar (Action: Submit for Approval)
  • Approval History es una lista relacionada obligatoria
  • Initial Submission Actions ocurren al pulsar 'Enviar'

Orden de Ejecución: La Jerarquía Definitiva

Memoriza este orden para el examen:
1. Validation Rules: El primer filtro.
2. Before-Save Flows: Optimización rápida.
3. Duplicate Rules: ¿Existe ya?
4. Save to DB: Se escribe (no commit).
5. After-Save Flows: Automatización pesada.
6. Assignment Rules: Asignar dueño.
7. Auto-Response Rules.
8. Workflow Rules / Process Builder.
9. Escalation Rules.
10. Roll-up Summary: Cálculos en el padre.
11. Commit: Guardado final.

Puntos Clave

  • Si un Flow actualiza un campo, las Reglas de Validación corren OTRA VEZ
  • Before-Save Flows evitan el ciclo de re-validación porque ocurren antes del guardado
  • Assignment Rules van DESPUÉS de los Flows (El Flow ve al dueño original)