Power Automate: leer el historial de ejecuciones y encontrar errores

Un flujo no se ejecuta como se esperaba, pero rara vez está claro a primera vista por qué. Power Automate registra cada ejecución en el historial de ejecuciones, incluyendo la hora de inicio, la duración, el estado y, en caso de error, el paso exacto en el que falló. Si sabes dónde encontrar esta información y cómo leerla, normalmente encontrarás la causa en pocos minutos en lugar de tras un largo proceso de prueba y error.

Este artículo te muestra dónde abrir el historial de ejecuciones en Power Automate, cómo leer paso a paso una ejecución fallida y qué códigos de error y errores de expresión aparecen con más frecuencia en la práctica. Así mantienes el control de tus flujos, incluso cuando algo sale mal.

Dónde encontrar el historial de ejecuciones

Inicia sesión en make.powerautomate.com y selecciona Mis flujos a la izquierda. En la fila del flujo afectado, abre el flujo directamente o utiliza el menú de tres puntos para abrir la página Detalles. Allí encontrarás la sección Historial de ejecuciones (también llamada Historial de ejecuciones de 28 días en interfaces más antiguas), que enumera cada ejecución en su propia fila con la hora de inicio, la duración y el estado. Una marca verde significa éxito, un signo de exclamación rojo significa un error.

Es importante saber que, de forma predeterminada, Power Automate solo almacena los datos de ejecución durante 28 días. Si tu flujo se ejecuta con poca frecuencia o necesitas que el historial siga siendo rastreable durante más tiempo, vale la pena revisar los detalles al respecto, porque de lo contrario las ejecuciones más antiguas simplemente dejan de ser localizables. Microsoft describe los detalles, incluida la posibilidad de conservar el historial de ejecuciones más tiempo a través de Dataverse, en el artículo Falta el historial de ejecuciones o desencadenadores de un flujo.

Leer una ejecución fallida paso a paso

Haz clic en la fecha de inicio de la ejecución fallida en la lista para acceder a la vista detallada. Allí aparece el flujo completo como una cadena de acciones, y al menos un paso está marcado con un signo de exclamación rojo. Ese es el punto de error real; todas las acciones anteriores se ejecutaron correctamente.

• Haz clic en el paso marcado para expandirlo.
• En el panel derecho, bajo Detalles verás el código de estado y el mensaje de error concreto del conector.
• Revisa también las pestañas Entradas y Salidas de los pasos anteriores, porque a menudo la causa real no está en el paso fallido en sí, sino en un valor incorrecto o vacío transmitido desde más arriba.
• Si el error se produce dentro de un bloque Scope, es posible que varias acciones posteriores aparezcan marcadas como "omitidas". Esto es normal, porque un Scope fallido cancela todas las acciones dependientes anidadas en su interior.

Para quienes prefieren un enfoque estructurado en lugar de hacer clic libremente, Microsoft ha publicado una especie de árbol de decisión: dependiendo de si el flujo no se guarda en absoluto, no se desencadena, una acción falla o simplemente entrega un resultado incorrecto, el artículo Solución de problemas de errores de flujo en la nube lleva a la sección correspondiente con pasos de comprobación concretos.

Los códigos de error más importantes de un vistazo

La mayoría de los errores en una acción fallida se pueden clasificar aproximadamente según el código de estado, antes incluso de leer el mensaje de error en detalle.

| Código | Significado | Primera comprobación |

| --- | --- | --- |

| 401 | Error de autenticación | Vuelve a autenticar la conexión en Conexiones |

| 403 | Acceso denegado | Comprueba los permisos sobre el recurso de destino y luego aclara las políticas de DLP con el administrador |

| 404 | Recurso no encontrado | La lista de SharePoint, el archivo, el buzón o el endpoint fue renombrado, movido o eliminado |

| 429 | Demasiadas solicitudes (límite de tasa) | Añade un retraso o activa el reintento con backoff en la configuración de la acción |

| 500 / 502 | Error del servidor en el servicio de destino | Normalmente temporal, reintenta la ejecución mediante Reenviar |

Los códigos del rango 400 casi siempre indican un problema con tu propia configuración, mientras que los códigos del rango 500 suelen indicar un problema temporal del servicio invocado y a menudo se resuelven simplemente reintentando la ejecución.

Reconocer y clasificar errores de expresión

En el historial de ejecuciones aparecen con especial frecuencia dos mensajes de error: "Invalid template" o "Unable to process template language expressions", así como "ExpressionEvaluationFailed". Ambos significan que una expresión es sintácticamente incorrecta o que, en tiempo de ejecución, hace referencia a un valor que no existe en absoluto. Las causas típicas de esto son:

• Una referencia a contenido dinámico de un paso que no se ejecutó en absoluto porque no se cumplió una condición.
• Un tipo de dato incorrecto, por ejemplo una cadena de texto donde se espera un número.
• Un valor vacío o nulo que se sigue procesando sin protección. Una función `coalesce()` o una comprobación previa `if(empty(...))` evita este problema.

Si en su lugar el historial informa "ActionFailed. An action failed. No dependent actions succeeded.", normalmente el verdadero desencadenante es un bloque Scope superior. En lugar de examinar individualmente cada una de las acciones posteriores marcadas como fallidas, vale la pena buscar específicamente la primera acción fallida dentro del Scope, porque ahí está la causa real.

Cuando el flujo se completa pero el resultado es incorrecto

No todos los errores se muestran como un signo de exclamación rojo. A veces el flujo se completa totalmente en verde, pero al final aparece el resultado incorrecto, por ejemplo un correo de aprobación no enviado o un campo mal rellenado. En este caso, la búsqueda clásica de errores rojos no ayuda; en su lugar, debes revisar cada acción individualmente y comparar las entradas con las salidas.

• En las condiciones, comprueba los valores que realmente se están comparando. Los errores comunes incluyen espacios iniciales, diferencias entre mayúsculas y minúsculas ("Aprobado" frente a "aprobado") o un valor numérico que llega como cadena de texto.
• En un bucle Para cada valor, vale la pena revisar la entrada que recorre el bucle. Si el array contiene más o menos elementos de los esperados, el problema suele estar ya en el paso de recuperación previo.
• Si el flujo actualiza un registro y lo vuelve a leer inmediatamente después, puede ser necesario un breve retraso de unos segundos entre la escritura y la lectura para que no se devuelvan datos obsoletos.
• Para depurar de forma específica, ayuda insertar acciones Compose en puntos clave del flujo. Estas muestran exactamente el valor que quieres comprobar y pueden consultarse después en el historial de ejecuciones, sin modificar el flujo real.

Microsoft describe con detalle estos y otros escenarios, incluidos ejemplos concretos de errores de autenticación y de la solución de problemas asistida por Copilot en el nuevo diseñador, en el artículo Solución de problemas de un flujo en la nube.

Cuándo vale la pena consultar la comunidad

No todos los mensajes de error son inequívocos, especialmente con combinaciones inusuales de conector y fuente de datos. En estos casos, suele ser más rápido copiar el texto exacto del error y buscarlo en los foros de la comunidad de Power Automate en powerusers.microsoft.com, en lugar de probar tú mismo todas las causas posibles. A menudo, otra persona ya ha publicado exactamente el mismo mensaje de error y ha encontrado una solución que funciona.

Quien revisa regularmente el historial de ejecuciones desarrolla rápidamente un instinto para saber qué errores son inofensivos y cuáles son estructurales. Quien prefiera confiar en una mirada externa experimentada, o quiera que un flujo se configure de forma robusta desde el principio, encontrará en la consultoría de Power Automate de NordFlux un único interlocutor con precio fijo en lugar de partes de horas.

Preguntas frecuentes

¿Cuánto tiempo permanece visible una ejecución fallida en el historial de ejecuciones?

28 días de forma predeterminada. Después, la ejecución desaparece del historial de ejecuciones normal, aunque el flujo en sí siga existiendo. Quien necesite una trazabilidad más larga puede conservar el historial de ejecuciones mediante la conexión a Dataverse o documentar manualmente los detalles del error antes de que se eliminen.

¿Por qué varios pasos después del error real aparecen marcados como omitidos?

Esto ocurre normalmente cuando el error se produce dentro de un bloque Scope. Si una acción dentro de él falla, todas las acciones dependientes posteriores del mismo bloque se cancelan automáticamente y se muestran como omitidas. La causa real casi siempre está en la primera acción fallida dentro del Scope.

¿Qué significa un código de error 429 en el historial de ejecuciones?

Un código 429 indica que el servicio invocado ha recibido demasiadas solicitudes en muy poco tiempo y por eso rechaza la solicitud. La solución habitual es añadir un breve retraso antes del paso afectado o activar una lógica de reintento con backoff en la configuración de la acción.

El flujo se completa en verde, pero no ocurre nada visible. ¿A qué se debe?

En ese caso, normalmente no se trata de un error técnico, sino de un problema de lógica, por ejemplo una condición que se evalúa de forma distinta a la esperada, o un bucle que se encuentra con un array vacío. Aquí ayuda abrir cada acción del historial individualmente y comparar las entradas y salidas reales con lo esperado.

¿Tengo que reiniciar todo el flujo por cada ejecución fallida?

No. En la vista detallada de una ejecución fallida está disponible la opción Reenviar. Repite la ejecución con los mismos datos de entrada una vez que hayas solucionado la causa subyacente, por ejemplo volviendo a autenticar una conexión o corrigiendo una acción defectuosa.