🟢 Introducción
Al crear flujos en Power Automate, tarde o temprano te encontrarás con errores: fallos en conectores, datos faltantes, expresiones inválidas, respuestas inesperadas de APIs, etc.
Un buen manejo de errores no solo evita que un flujo se detenga, sino que también permite:
- Registrar lo ocurrido
- Informar al usuario de manera clara
- Intentar alternativas
- Continuar la ejecución sin fallar todo el proceso
En este post aprenderás cómo usar las herramientas de Power Automate para implementar Try–Catch, rutas alternativas y patrones de resiliencia.
🧠 Qué es / para qué sirve
El error handling es el conjunto de técnicas que permiten a un flujo:
- Capturar errores en pasos individuales
- Definir rutas condicionadas según éxito o fallo
- Evitar detenciones inesperadas
- Reintentar acciones críticas
- Notificar adecuadamente a administradores o usuarios
- Guardar logs de diagnóstico
Power Automate no tiene un bloque «Try-Catch» tradicional, pero sí ofrece mecanismos equivalentes como:
- Configuración «Run After»
- Condiciones para evaluar errores
- Acciones de Scope
- Propiedades internas como
outputs(),status(),isError(), etc. - Automatización de reintentos (retry policies)
🧩 Sintaxis / Elementos clave
✔️ 1. Run After
Permite ejecutar un paso solo cuando el anterior:
- Succeed
- Fail
- Skip
- Timeout
Esto crea flujo tipo Try → Catch → Finally.
✔️ 2. Propiedad status() en expresiones
equals(status('MiAcción'), 'Failed')✔️ 3. Obtener mensaje de error
body('MiAcción')['error']['message']✔️ 4. Retry Policy
Permite reintentar acciones automáticamente:
- None
- Default
- Fixed interval
- Exponential backoff
Se configura en los Settings de la acción.
💻 Ejemplos con código
🔹 Ejemplo 1 — Implementar Try-Catch con Run After
Supón que tienes una acción de Dataverse que podría fallar (crear un registro).
TRY:
- Acción: Add a new row (Dataverse)
CATCH:
- Agrega una acción Compose → Run After → has failed
- Mensaje personalizado:
{
"Error": "No se pudo crear el registro.",
"Detalle": body('Add_a_new_row')?['error']?['message']
}FINALLY:
- Un email notificando que el flujo terminó, sin importar éxito o fallo.
🔹 Ejemplo 2 — Reintentos automáticos (Retry Policy)
Para conectores que fallan temporalmente:
Settings → Retry Policy → Exponential
Configuración recomendada:
- retries: 4
- minimumInterval: 5 seconds
- maximumInterval: 45 seconds
Ayuda a evitar fallos por tiempo o saturación del servicio.
🔹 Ejemplo 3 — Validar si un valor viene vacío para evitar errores
Antes de acceder a una propiedad:
if(empty(items('Apply_to_each')?['Cliente']), 'Desconocido', items('Apply_to_each')?['Cliente'])Esto evita errores de “property doesn’t exist”.
🔹 Ejemplo 4 — Guardar errores en Dataverse o SharePoint
Puedes registrar el error para auditoría:
{
"Fecha": utcNow(),
"Flujo": "Proceso de Facturación",
"Acción": "Consultar API",
"Mensaje": body('Consultar_API')?['error']?['message']
}🧱 Buenas prácticas
✅ Envuelve procesos críticos en Scopes llamados “Try”, “Catch”, “Finally”.
✅ Siempre documenta qué acciones pueden fallar.
✅ Usa Compose para estandarizar mensajes de error.
✅ Implementa reintentos para conectores propensos a fallar (HTTP, SQL, SharePoint).
✅ Notifica de forma clara a los usuarios — nada de mensajes técnicos sin explicación.
✅ Registra errores en un log centralizado (Dataverse, SharePoint, SQL).
⚠️ Errores comunes
🚫 Usar Run After sin renombrar acciones — difícil de depurar.
🚫 No capturar el error interno del conector y solo mostrar “Bad Gateway”.
🚫 Suponer que una API siempre devolverá campos con el mismo nombre.
🚫 Poner bucles Apply to Each sin condiciones de protección.
🚫 Activar Retry Policy indiscriminadamente — cuidado con flujos que dependen de APIs limitadas.
🔄 Variantes o alternativas
- Scope + Configuración avanzada Run After → Patrón Try–Catch–Finally
- Terminar flujo con “Terminate” en casos críticos
- Condition previa para validar datos antes de procesarlos
- Uso de Parse JSON para evitar errores por propiedades inexistentes
- Retry adaptable según el tipo de conector
Deja un comentario