Tiempo de espera de 30 días en aprobaciones de Power Automate: el patrón de relevo como solución

Un flujo de aprobación en Power Automate espera pacientemente mientras la persona que aprueba no responde, pero esa paciencia no es ilimitada. Si una aprobación se prolonga por una ausencia larga, una baja parental o una decisión de inversión que no está prevista hasta el próximo trimestre, la ejecución del flujo subyacente puede simplemente interrumpirse antes de que llegue siquiera una respuesta. Para los equipos que dependen de un único flujo continuo, esto supone un punto ciego incómodo: la solicitud sigue viéndose normal en la bandeja de entrada de la persona que aprueba, mientras que en segundo plano el proceso ya está muerto.

Este artículo explica por qué Power Automate finaliza las aprobaciones tras aproximadamente 30 días, qué ocurre en la práctica un poco antes, y cómo puede usarse el llamado patrón de relevo con dos flujos independientes para gestionar de forma limpia aprobaciones de duración indeterminada. Situación en julio de 2026.

Por qué Power Automate interrumpe las aprobaciones a los 30 días

La causa no está en la propia función de aprobación, sino en un límite de duración general para los flujos en la nube. Según los límites para flujos automatizados, programados e instantáneos se aplica una duración máxima de 30 días a cada ejecución individual del flujo, calculada desde el momento en que se inicia la ejecución. La documentación lo expresa con claridad: la duración también abarca los procesos con pasos pendientes, como las aprobaciones, y transcurridos 30 días se produce un tiempo de espera agotado para los pasos pendientes.

Esto afecta sobre todo a la acción Iniciar y esperar una aprobación, porque bloquea la ejecución del flujo hasta que llega una respuesta. Precisamente ese bloqueo se convierte en su perdición en cuanto el tiempo de espera alcanza el límite de 30 días. En ese momento, el flujo técnicamente ya no tiene forma de seguir ejecutándose, independientemente de si la persona que aprueba pasó por alto la solicitud o simplemente aún no ha tenido tiempo de atenderla.

Lo que ocurre en la práctica ya a los 28 días

En la descripción general de los problemas conocidos con las aprobaciones, Microsoft señala una particularidad más relevante en la práctica que los 30 días documentados: un proceso de aprobación puede, según indican, esperar 28 días, y si el tiempo de espera supera esos 28 días, el flujo falla. Es importante tener en cuenta que este error solo afecta a la propia ejecución del flujo. La aprobación sigue siendo visible en el centro de aprobaciones aunque ya ningún flujo esté esperando por ella.

Esto da lugar a entradas huérfanas a las que la persona que aprueba en teoría todavía puede responder, sin que esa respuesta llegue a ninguna parte. La persona solicitante o una administración del entorno debe eliminar manualmente esas aprobaciones huérfanas del centro de acciones. Quien envíe con regularidad aprobaciones de duración incierta debería incorporar este paso de limpieza de forma fija en el mantenimiento de su proceso, en lugar de confiar en que las entradas antiguas desaparezcan por sí solas.

El patrón de relevo: dos flujos en lugar de una ejecución larga

La solución recomendada por Microsoft para aprobaciones con una duración potencialmente larga es dividir el proceso en dos flujos independientes. Según la guía Crear y probar un flujo de trabajo de aprobación con Power Automate la norma es: si un flujo se ejecuta durante más de 30 días, las aprobaciones deben almacenarse en Microsoft Dataverse. Esto permite crear flujos que reaccionan a las respuestas incluso después de que la ejecución del flujo original haya caducado hace tiempo.

En concreto, para ello se usa la acción Crear una aprobación (v2) en lugar de la acción bloqueante Iniciar y esperar una aprobación:

• El flujo A solo envía: crea la solicitud de aprobación mediante Crear una aprobación (v2), escribe el identificador de aprobación junto con el contexto del proceso en una tabla de Dataverse u otro sistema de origen y a continuación finaliza de inmediato. Aquí no corre ningún reloj de 30 días, porque el flujo no espera.
• El flujo B se encarga de la lógica: un segundo flujo, independiente, reacciona a la respuesta, por ejemplo mediante un desencadenador de Dataverse ante cambios de estado o mediante la acción Esperar una aprobación, vinculada al identificador de aprobación almacenado previamente. Solo ejecuta la lógica de negocio real cuando efectivamente se toma una decisión, ya sea a los tres días o a los tres meses.

Esta transferencia de un flujo emisor a un flujo en espera es el verdadero patrón de relevo: en lugar de un único corredor que tiene que resistir todo el trayecto solo, un segundo flujo recoge el testigo y no está sujeto a ningún límite de duración del primero.

Una trampa al separar la creación y la espera

Los problemas conocidos mencionan un efecto que muchos pasan por alto al construir el patrón de relevo por primera vez: si la persona que aprueba responde muy rápido, antes incluso de que el flujo llegue a la acción de espera, el flujo puede quedarse bloqueado en la fase de espera. Por eso Microsoft recomienda llamar a las acciones Crear y Esperar lo más cerca posible una de otra dentro del flujo, o bien comprobar el estado de la aprobación en Dataverse antes incluso de iniciar la acción de espera. Para un patrón de relevo limpio merece la pena revisar precisamente este orden antes de poner el flujo en producción.

Caso especial del kit de aprobaciones: reinicio automático tras el tiempo de espera agotado

Quien utilice, en lugar de flujos propios, el kit de aprobaciones prediseñado, es decir, la aplicación de gestión de aprobaciones empresariales, ya obtiene incorporada una parte de esta protección. Según la referencia del estado de aprobación existe allí el estado Pendiente (Tiempo de espera agotado): significa que la persona que aprueba no respondió dentro de los primeros 30 días y que la ejecución del flujo en la nube de Power Automate que gestiona esta solicitud se reinicia automáticamente. Tras el reinicio, el estado vuelve a Pendiente, y la solicitud sigue siendo válida.

Se trata de una automatización cómoda, pero que solo se aplica dentro del kit de aprobaciones con su conexión a Dataverse, y no automáticamente a cualquier flujo construido por cuenta propia. Quien opere su propio flujo de aprobación sin este kit debe reconstruir el mecanismo de reinicio por sí mismo mediante el patrón de dos flujos descrito anteriormente.

Consejos prácticos para aprobaciones de larga duración robustas

• Planifica el patrón de relevo desde el principio en cuanto una aprobación pueda quedar abierta de forma realista durante más de tres o cuatro semanas, en lugar de reaccionar solo cuando el primer flujo ya haya fallado.
• Almacena el estado y el identificador de aprobación fuera del flujo, por ejemplo en Dataverse o en una lista de SharePoint, para que un segundo flujo pueda retomarlo en cualquier momento.
• Incorpora un recordatorio que se envíe de nuevo a la persona que aprueba tras unos 20 días, para que la decisión se tome dentro de una ventana de tiempo realmente utilizable.
• Limpia con regularidad las aprobaciones huérfanas del centro de acciones, para que las solicitudes antiguas no se respondan accidentalmente sin que ningún flujo siga reaccionando.

Quien no quiera construir este patrón por su cuenta, o necesite proteger varios procesos de aprobación a la vez, puede recurrir al acompañamiento de un proveedor especializado como NordFlux. De este modo mantienes el control de tu proceso mientras la protección técnica frente al límite de 30 días funciona de forma limpia en segundo plano.

Preguntas frecuentes

¿A partir de cuándo exactamente se interrumpe una aprobación de Power Automate?

Lo documentado oficialmente es una duración máxima de 30 días por ejecución de flujo, pero en la práctica, según Microsoft, el flujo puede fallar ya a los 28 días si el tiempo de espera supera ese valor. Para la planificación conviene, por precaución, contar con el valor más bajo.

¿Qué ocurre con la aprobación que queda en el centro de acciones?

Sigue siendo visible y a primera vista parece normal, aunque ya ningún flujo esté esperando una respuesta. Una reacción de la persona que aprueba entonces no llega a ninguna parte, por lo que esas entradas huérfanas deben eliminarse manualmente del centro de aprobaciones.

¿Es suficiente el patrón de relevo para tiempos de espera ilimitados?

Sí, porque el segundo flujo en espera solo se ejecuta durante el tiempo que permite una única acción de espera, y puede volver a activarse cuando sea necesario, siempre que la información de aprobación permanezca almacenada de forma centralizada en Dataverse u otro sistema de origen. Así no se elimina el límite de 30 días de una ejecución individual, sino que se vuelve irrelevante para el proceso global.

¿El reinicio automático tras el tiempo de espera agotado se aplica también a los flujos construidos por cuenta propia?

No, el reinicio automático con el estado Pendiente (Tiempo de espera agotado) es una función del kit de aprobaciones prediseñado, con su propia estructura de Dataverse. En un flujo de aprobación construido de forma individual, tienes que reproducir tú mismo este mecanismo mediante el patrón de dos flujos.

¿Cómo elijo entre el patrón de dos flujos y el kit de aprobaciones prediseñado?

Para procesos de aprobación individuales y específicos con lógica propia, el patrón de dos flujos construido por cuenta propia suele ser la solución más adecuada y ligera. Si, en cambio, hay que gestionar de forma uniforme varios procesos de aprobación similares en la empresa, merece la pena considerar el kit de aprobaciones, porque ya incorpora la gestión de tiempos de espera agotados y la lógica de estados.