¿Cómo identificar y corregir un error de Salesforce Flow?

Un Flow con errores suele bloquear una acción sencilla: crear una oportunidad, guardar una cuenta, cerrar un caso. El usuario ve un mensaje poco claro y el administrador recibe un correo lleno de detalles técnicos. La buena noticia: en la gran mayoría de los casos, la causa se encuentra siguiendo siempre el mismo método.

Dónde aparecen los errores de Flow

Un error de Flow se manifiesta en dos lugares.

• En la pantalla del usuario. En un Flow activado por un registro, el guardado falla y aparece un mensaje. En un Flow de pantalla, el texto «An unhandled fault has occurred in this flow» (se ha producido un error no gestionado) sustituye a la pantalla.
• En el buzón del administrador. Salesforce envía un correo de error con el nombre del Flow, la versión, el elemento que ha fallado y los valores de las variables en el momento del error. Es el documento más útil para el diagnóstico.

El método de diagnóstico en 5 pasos

1. Leer el correo de error hasta el final

El principio del correo suele ser genérico. La parte útil está más abajo: la lista de elementos ejecutados y, sobre todo, el último, el que ha fallado, con el mensaje de error exacto. Anote tres cosas: el elemento que falla, el mensaje y el registro afectado.

2. Identificar el tipo de error

El mensaje de error casi siempre indica la familia del problema:

3. Reproducir el problema en un sandbox

Abra el Flow en Flow Builder y use el botón Depurar con el mismo registro, o con uno equivalente. La depuración muestra el camino seguido, elemento por elemento, y el valor de cada variable. En un Flow activado por un registro, indique si se trata de una creación o de una modificación, como en el caso real.

Si el Flow funciona en la depuración pero falla para el usuario, el problema suele venir del contexto de ejecución: permisos del usuario, tipo de registro o valor de un campo que no ha reproducido.

4. Mirar lo que se ejecuta alrededor del Flow

Un Flow nunca está solo. En el mismo objeto puede haber otros Flows, reglas de validación, reglas de flujo de trabajo antiguas o código Apex. El Explorador de desencadenadores de flujos (Flow Trigger Explorer) muestra todos los Flows que se activan en un objeto y su orden. Dos Flows que modifican el mismo campo en distinto orden dan resultados sorprendentes.

5. Corregir la causa, no el síntoma

Esquivar el error (desactivar la regla de validación, dar más permisos a todo el mundo) lo hace desaparecer, pero a menudo crea otro problema. Pregúntese por qué existe la regla, o por qué el usuario no tiene acceso, antes de cambiar nada.

Los errores más frecuentes y su corrección

Una regla de validación bloquea el Flow

Es el caso más habitual. Una regla añadida hace poco rechaza un cambio que el Flow hacía sin problema. Hay dos opciones: adaptar la regla para que tenga en cuenta el caso (con el negocio) o hacer que el Flow rellene el campo esperado. Ejemplo: una regla exige un «Sector» en la cuenta y el Flow crea cuentas sin sector. El Flow debe rellenar el sector, o la regla debe excluir las cuentas creadas automáticamente.

Una variable vacía

Un elemento «Get Records» no encuentra nada y un elemento posterior usa el resultado como si existiera. Añada una Decisión justo después de la búsqueda: «el resultado no está vacío». El camino «vacío» debe hacer algo previsto: nada, un aviso o un mensaje claro.

Consultas o escrituras dentro de un bucle

Poner un «Get Records» o un «Update Records» dentro de un bucle hace saltar los límites en cuanto el Flow procesa muchos registros, por ejemplo durante una importación. La corrección: reunir los registros en una variable de colección durante el bucle y hacer una sola escritura después.

El tipo equivocado de Flow activado por registro

Para modificar un campo del mismo registro, un Flow «antes de guardar» (actualizaciones rápidas de campos) es más rápido y evita escrituras adicionales. Para crear registros relacionados o enviar correos, hace falta un Flow «después de guardar». Mezclar los dos crea bucles y errores.

Ejemplo completo: una oportunidad que ya no se crea

Situación ficticia: desde el lunes, el equipo comercial ya no puede crear oportunidades en algunas cuentas. El administrador recibe un correo de error en cada intento.

1. Lectura del correo. El elemento que falla es «Actualización de la cuenta» y el mensaje es FIELD_CUSTOM_VALIDATION_EXCEPTION: una regla de validación rechaza el cambio. El Flow no ha cambiado desde hace meses.
2. Búsqueda de la causa. En el Gestor de objetos, en el objeto Cuenta, una regla de validación creada el viernes exige el campo «Sector» en cuanto una cuenta pasa al tipo «Cliente». Y el Flow pasa la cuenta a «Cliente» al crear su primera oportunidad, sin rellenar el sector.
3. Reproducción. En un sandbox, la depuración del Flow con una cuenta sin sector falla exactamente en el mismo elemento. La causa queda confirmada.
4. Corrección, decidida con el negocio. La regla tiene su razón de ser: el sector se usa en los informes de la dirección, así que se mantiene. El Flow ya no cambia el tipo de una cuenta sin sector: crea una tarea «Completar el sector» para el propietario de la cuenta. Una ruta de error en el elemento de actualización avisa al administrador en lugar de bloquear al comercial.
5. Comprobación. Tres pruebas antes de activar: una cuenta con sector, una cuenta sin sector y una importación de 50 oportunidades. Después, activación de la nueva versión y control de los correos de error durante los días siguientes.

Buenas prácticas para evitar los próximos errores

• Una ruta de error en cada escritura. En Flow Builder, cada elemento que escribe puede tener una ruta de «Error». Úsela para registrar el problema y avisar al administrador, sin bloquear al usuario cuando sea aceptable.
• Criterios de entrada precisos. Un Flow activado por un registro solo debe ejecutarse cuando hace falta, por ejemplo «cuando cambia la fase».
• Un Flow por objeto y por momento, cuando sea posible. Menos Flows significa menos conflictos de orden.
• Descripciones. Cada Flow, cada versión y cada elemento importante debe decir qué hace y por qué.
• Ningún cambio directo en producción. Pruebe en un sandbox y después despliegue.

Probar antes de activar

Antes de activar una nueva versión, pruebe como mínimo:

1. el caso que fallaba;
2. el caso normal, que ya funcionaba;
3. un caso límite: campo vacío, usuario con pocos permisos, varios registros a la vez (importación).

En los Flows activados por un registro, Flow Builder permite guardar pruebas de Flow reutilizables. Evitan repetir las mismas comprobaciones en cada cambio.

Cuándo recurrir a un experto

Usted mismo puede corregir una regla de validación o una variable vacía. Recurra a un experto cuando:

• varias automatizaciones del mismo objeto se contradicen;
• el error tiene que ver con los límites de la plataforma o con una importación masiva;
• interviene código Apex en la cadena;
• no tiene un sandbox, o no tiene tiempo para probar sin riesgo.

En estos casos, una hora de diagnóstico suele ahorrar varios días de pruebas en producción. Si los errores se repiten cada mes, el mantenimiento de Salesforce incluye la revisión de las automatizaciones. Vea también nuestro servicio de automatización de Salesforce: diagnóstico, corrección y pruebas, con presupuesto antes de cualquier trabajo, o consulte los precios.

Referencias oficiales

Documentación de Salesforce para profundizar:

• Troubleshooting Flow Run Time Errors (ayuda de Salesforce) (nueva pestaña)
• Select Flow and Process Error Email Recipients (ayuda de Salesforce) (nueva pestaña)
• Default Flow Error Handling (ayuda de Salesforce) (nueva pestaña)
• Handle Flow Errors Effectively (Trailhead) (nueva pestaña)

Preguntas frecuentes