Try-Catch con «Configure run after» en Power Automate

Un fallo en medio de un flujo es molesto; un fallo que nadie nota es peligroso. Power Automate no tiene un Try-Catch integrado como un lenguaje de programación clásico, pero combinando los scopes con el ajuste Configure run after puedes construir tú mismo exactamente este patrón. El resultado es un flujo que, ante un error, no se interrumpe sin más, sino que reacciona de forma controlada, lo registra y, en caso de duda, te avisa.

En este artículo te mostramos paso a paso cómo construir los scopes Try, Catch y Finally, cómo configurar correctamente sus condiciones de ejecución posterior y cómo llegar al mensaje de error real cuando algo falla. La base de todo esto la aporta la documentación oficial de Microsoft, en concreto la guía sobre el manejo robusto de errores y la descripción general de los scopes en los flujos en la nube.

Por qué Power Automate no tiene un Try-Catch clásico

En los lenguajes de programación capturas una excepción con un bloque Try-Catch: el código se ejecuta en la parte Try y un error salta automáticamente a la parte Catch. Power Automate funciona de otra manera: cada acción tiene una condición de ejecución posterior, que por defecto está establecida en «se ha realizado correctamente». Si una acción anterior falla, la siguiente acción simplemente se omite y todo el flujo se interrumpe, salvo que configures algo distinto.

Aquí es exactamente donde entra el patrón Try-Catch: agrupas tu lógica real en un scope, añades un segundo scope para el manejo de errores y configuras su condición de ejecución posterior para que solo se ejecute si falla el primer scope. Así obtienes, estructuralmente, el mismo comportamiento que un Try-Catch, solo que configurado a través de la interfaz en lugar de mediante código.

La estructura: scopes Try, Catch y Finally

Para un patrón completo de manejo de errores, creas tres scopes consecutivos:

• Try: Un scope con tu lógica de negocio real, es decir, las acciones que deben ejecutarse en condiciones normales.
• Catch: Un segundo scope justo debajo, que se ejecuta únicamente cuando algo sale mal en el scope Try. Aquí registras el error o envías una notificación.
• Finally: Un tercer scope que siempre se ejecuta, independientemente del resultado, ya sea que el scope Try haya tenido éxito o no. Útil para tareas de limpieza como cerrar una conexión o establecer un campo de estado.

Cada scope lo añades a través de Agregar una acción y buscando «Scope», descrito en detalle en la guía Crear y usar scopes. Asegúrate de nombrar los scopes de forma clara; «Try», «Catch» y «Finally» se entienden de un vistazo y hacen que el flujo sea legible también para los compañeros que lo hereden más adelante.

Paso a paso: configurar Configure run after

Así configuras la condición de ejecución posterior para el scope Catch:

• Abre el scope Catch en el diseñador y selecciona el menú «...» en la parte superior derecha.
• Selecciona Configure run after (en alemán: «Ausführen nach konfigurieren»).
• En la lista aparece el scope anterior, es decir «Try», con cuatro casillas: se ha realizado correctamente, ha fallado, se omite y se ha superado el tiempo de espera.
• Quita la marca de «se ha realizado correctamente» y marca en su lugar «ha fallado», «se omite» y «se ha superado el tiempo de espera».
• Confirma con Listo.

Con esto, el scope Catch solo se ejecuta cuando el scope Try no se completa correctamente. Para el scope Finally, procedes de la misma manera, pero marcas las cuatro casillas, incluida «se ha realizado correctamente». Así, este scope se ejecuta siempre, independientemente de cómo termine el scope Try. Importante: al menos una casilla debe permanecer siempre activa; la condición no se puede guardar completamente vacía.

Leer el error en el scope Catch

Un scope Catch que solo sabe que algo salió mal, pero no qué, apenas te ayuda a solucionar el problema. Para llegar al mensaje de error concreto, utilizas en el scope Catch la acción Filtrar matriz en combinación con la función de expresión `result()`, que devuelve el estado y la salida de las acciones anteriores. A partir de esta respuesta filtrada, extraes el código y el texto del error y los colocas, por ejemplo, en una acción Crear tabla HTML, que envías por correo electrónico o guardas en una lista de registro de errores en SharePoint o Dataverse.

Además, la función `workflow()` proporciona metadatos sobre la ejecución actual del flujo, como el ID del entorno y del flujo. Combinada con la acción Componer construyes a partir de ahí un enlace directo a la ejecución fallida, que incluyes en la notificación. Así, no solo llega a la bandeja de entrada la información «se ha producido un error», sino directamente el camino hasta donde puedes solucionarlo.

Errores comunes

• Profundidad de anidamiento: Power Automate permite un máximo de ocho niveles anidados de scopes, condiciones, switches y bucles. Si anidas patrones Try-Catch unos dentro de otros, ten en cuenta este límite, de lo contrario el flujo ya no se podrá guardar.
• Estado agregado en lugar de acción individual: Si un scope falla, el diseñador informa inicialmente solo el estado «Con errores» para todo el scope. Solo ves qué acción individual fue realmente responsable cuando despliegas el scope en el historial de ejecución.
• Los desencadenadores y las acciones de respuesta no van dentro de un scope. Deben permanecer fuera para que el flujo se inicie y responda correctamente.
• Demasiados scopes: No todas las acciones individuales necesitan su propio scope. Utiliza el patrón Try-Catch específicamente donde realmente aporte valor, por ejemplo en operaciones de escritura críticas o llamadas a sistemas externos; de lo contrario, el flujo se vuelve innecesariamente confuso.

Si quieres integrar este patrón de forma fiable en un flujo de producción más grande, o no estás seguro de dónde en tu proceso es realmente necesario un scope Catch, la consultoría de Power Automate de NordFlux puede ayudarte con ello. Mantienes el control total sobre tu flujo y tus datos; nosotros solo ayudamos con una implementación limpia.

Preguntas frecuentes

¿Configure run after es lo mismo que un Try-Catch en un lenguaje de programación?

Técnicamente no, funcionalmente sí. Power Automate no tiene un concepto de excepción integrado que haga que una acción salte automáticamente a una ruta de error. Pero a través de la condición de ejecución posterior de un scope logras el mismo comportamiento: el scope Catch solo se ejecuta cuando falla el scope Try, igual que un bloque catch ante una excepción.

¿Tengo que establecer una condición de ejecución posterior propia para cada acción individual?

No. Si agrupas tus acciones en un scope Try, basta con un único ajuste de Configure run after para todo el scope, en lugar de proteger cada acción individualmente. Esta es precisamente una de las ventajas prácticas de los scopes frente a muchas condiciones de ejecución posterior individuales a nivel de acción.

¿Qué ocurre si dejo marcada accidentalmente la casilla «se ha realizado correctamente» en el scope Catch?

En ese caso, el scope Catch también se ejecuta cuando el scope Try tuvo éxito, lo cual contradice el propósito de una ruta de error. Para un scope Catch genuino, quita siempre la marca de «se ha realizado correctamente» y activa únicamente «ha fallado», «se omite» y «se ha superado el tiempo de espera».

¿Puedo usar también una política de reintentos además de Configure run after?

Sí, ambas se complementan bien. Una política de reintentos en la configuración de la acción intenta primero volver a ejecutar automáticamente una acción que ha fallado temporalmente, idealmente con intervalos que crecen exponencialmente. Solo si la acción sigue fallando después de todos los reintentos entra en juego tu scope Catch a través de la condición de ejecución posterior.

¿Cómo averiguo qué acción dentro de un scope fallido fue el problema real?

Abre la ejecución del flujo afectada en el historial de ejecución y despliega allí el scope que falló. Dado que un scope solo informa un único estado agregado hacia el exterior, verás el mensaje de error concreto junto con la marca roja únicamente a nivel de la acción individual dentro del scope.