Un flujo que solo contempla el «camino feliz» es un flujo que un día va a fallar delante de todo el mundo. Power Automate no tiene try/catch en el sentido literal de un lenguaje de programación, pero con «run after» y los Scope se puede construir algo muy parecido, y es de las primeras cosas que aprendí a hacer bien cuando empecé a llevar flujos a producción.
Qué es «Configure run after»
Cada acción de un flujo tiene, en su menú de configuración, una opción llamada Configure run after. Por defecto, cualquier acción se ejecuta solo si la acción anterior ha tenido éxito (has succeeded). Pero se puede marcar para que también se ejecute si la acción anterior ha fallado (has failed), se ha omitido (is skipped) o ha superado el tiempo de espera (has timed out), combinando varias de estas condiciones a la vez.
Esto es lo que permite construir ramas de manejo de error: una acción de «avisar por correo del fallo» que se configura para ejecutarse únicamente cuando la acción anterior ha fallado, en paralelo a la rama normal que sigue cuando todo va bien. Sin tocar esta opción, el diseñador solo dibuja el camino feliz: en cuanto un paso falla, el flujo entero se detiene y queda marcado como fallido, sin que nadie se entere hasta que revisa el historial de ejecuciones manualmente.
Lo interesante es que estas cuatro condiciones no son excluyentes entre sí: una misma acción puede configurarse para ejecutarse si la anterior «ha fallado o ha superado el tiempo de espera», por ejemplo, cubriendo dos escenarios de fallo distintos con una sola rama de recuperación.
Los Scope: agrupar para controlar mejor
Configurar el «run after» acción por acción funciona, pero se vuelve incómodo en flujos con muchos pasos. Ahí es donde entran las acciones Scope: permiten agrupar un conjunto de acciones relacionadas bajo un único bloque, y aplicar el «Configure run after» a nivel de todo el bloque, no acción por acción. Si cualquier acción dentro de un Scope falla, el propio Scope se marca como fallido, y un segundo Scope configurado para ejecutarse «has failed» respecto al primero puede encargarse de la recuperación.
El patrón Try/Catch/Finally con Scopes
Combinando ambos conceptos se puede reproducir el patrón clásico de manejo de errores:
Contiene la lógica normal del flujo: las llamadas a conectores, las validaciones, las escrituras en el sistema destino. Es el «camino feliz».
Configurado con «run after: has failed / has timed out» respecto al Scope Try. Aquí se registra el error, se notifica al equipo responsable o se intenta una acción alternativa.
Configurado para ejecutarse siempre, haya fallado o no el Try (combinando «has succeeded», «has failed», «is skipped» y «has timed out»). Ideal para tareas de limpieza o cierre que deben ocurrir sí o sí.
Este patrón separa con claridad qué pasa cuando todo va bien, qué pasa cuando algo falla, y qué debe pasar pase lo que pase, exactamente igual que un try/catch/finally en cualquier lenguaje de programación.
Un flujo sin ningún Scope de «catch» no es un flujo sin errores: es un flujo donde los errores simplemente no se ven hasta que alguien pregunta por qué el proceso se quedó a medias.
Un matiz importante: el orden de creación de los Scopes en el diseñador determina las opciones de «run after» disponibles, porque solo se puede configurar una acción para depender de acciones que ya existen por encima de ella. Por eso conviene crear primero el Scope Try, después el Catch apuntando a él, y por último el Finally apuntando a ambos.
Cinco consejos para el manejo de errores
- Envuelve la lógica de negocio principal en un Scope desde el primer diseño del flujo, no como un parche posterior.
- En el Scope de «catch», registra siempre el mensaje de error real del conector, no solo un aviso genérico.
- Usa un Scope «finally» para notificaciones o limpiezas que deben ejecutarse siempre, independientemente del resultado.
- No abuses de «run after: is skipped» salvo que entiendas bien por qué una acción concreta podría quedar omitida.
- Nombra los Scopes con claridad (Try_ValidarFactura, Catch_ValidarFactura) para que el manejo de errores se entienda de un vistazo en el diseñador.
¿Y qué pasa si el paso que falla dentro de ese Scope es precisamente el que espera la decisión de un aprobador?
Leer el artículo sobre flujos de aprobación