Simula llamadas síncronas en Power Apps + Power Automate sin errores por timeout

Uno de los grandes retos al trabajar con Power Apps y Power Automate es gestionar procesos que duran más de dos minutos.

Por diseño, cuando una aplicación llama a un flujo y este no responde dentro de ese tiempo, Power Apps lanza un error de timeout. El flujo puede seguir ejecutándose en segundo plano, pero para el usuario la experiencia ya está rota: la app se detiene, muestra un error y no hay ninguna manera visual de saber si el proceso terminó o no.

🇬🇧Read in english

Este escenario es más común de lo que parece. Algunos ejemplos reales:

Sincronizar grandes volúmenes de datos desde una base de datos SQL.
Integrarse con APIs externas lentas.
Generar documentos o informes complejos.
Realizar cálculos de negocio intensivos o migraciones internas.

En todos estos casos, el flujo de Power Automate puede tardar entre 3 y 10 minutos (o incluso más).
Si intentamos ejecutar ese proceso directamente desde Power Apps y esperamos la respuesta, la app fallará en el minuto 2… aunque todo haya salido bien por detrás.

El problema: el timeout rompe la experiencia del usuario

Cuando un proceso falla por timeout, no es solo un error técnico:

El usuario piensa que algo ha salido mal, aunque no sea cierto.
No hay retroalimentación clara ni forma de saber si el flujo terminó.
El botón de acción puede quedar activo, permitiendo lanzar varias ejecuciones en paralelo, con riesgo de datos duplicados o inconsistencias.
No hay forma de “esperar” en Power Apps sin bloquear la interfaz.

Esto genera una fricción innecesaria en escenarios empresariales reales, donde la robustez y la previsibilidad de las acciones son clave.

Síncrono vs Asíncrono: por qué este límite importa en Power Apps

Antes de entrar en la solución, vale la pena aclarar un concepto fundamental: la diferencia entre ejecución síncrona y asíncrona, y cómo Power Apps maneja internamente las llamadas a Power Automate.

Proceso síncrono:

Un proceso síncrono es aquel en el que:

La aplicación inicia una acción (por ejemplo, llamar a un flujo).
Luego espera la respuesta antes de continuar con el resto de la ejecución.
Si la respuesta se retrasa, la aplicación queda bloqueada esperando.

Un ejemplo muy simple: cuando haces clic en un botón de “Guardar” y la pantalla no te deja hacer nada hasta que termine el guardado.

En Power Apps, cuando ejecutas algo como:

Set(varResult, 'MyFlow'.Run())

La app espera la respuesta del flujo.

Si el flujo devuelve un resultado antes del límite, la app continúa normalmente.
Si no… se agota el tiempo de espera y aparece un error.

Proceso asíncrono

En cambio, un proceso asíncrono es diferente:

La aplicación inicia la acción.
No espera bloqueada a que termine.
Puede seguir ejecutando otras cosas mientras la acción ocurre en segundo plano.
El resultado se recupera más adelante, cuando está disponible.

Ejemplo cotidiano: cuando subes un archivo a un servidor y puedes seguir usando la web mientras se completa la subida.

Power Apps no tiene un mecanismo nativo de espera asíncrona (no existe un await como en lenguajes de programación tradicionales).
Por eso, si necesitas manejar procesos largos, tienes dos opciones:

Aceptar que la app dará error si tarda más de 2 minutos.
O bien diseñar tú mismo un patrón asíncrono controlado, que es justamente lo que haremos en este artículo.

La idea: simular un comportamiento síncrono, sin bloquear la app

Para resolverlo, utilizamos un patrón muy sencillo pero potente:

El flujo responde inmediatamente a Power Apps, sin ejecutar la lógica pesada dentro de la misma llamada.
El flujo lanza el proceso en segundo plano (por ejemplo, una sincronización SQL) y marca un flag en base de datos para indicar que está corriendo.
La aplicación deshabilita el botón y muestra un estado de “Sincronizando…”, simulando una espera.
Un Timer en Power Apps consulta cada X segundos si el proceso ya terminó (polling).
Cuando el flag cambia, la app muestra un mensaje de éxito y vuelve a habilitar la interfaz.

De esta forma, no estamos bloqueando la app ni esperando de verdad… pero para el usuario la experiencia es exactamente igual que si la llamada fuese síncrona.

Un ejemplo real: sincronización de datos con SQL

Imagina que tienes una app donde los usuarios lanzan una sincronización de datos con una base SQL.
El proceso completo dura entre 3 y 5 minutos. Si lo lanzas directamente desde Power Apps, fallará.

Con este patrón:

Al pulsar “Sincronizar”, la app llama al flujo → el flujo responde inmediatamente.
La app desactiva el botón y muestra un estado visual de “Sincronizando…”.
Cada 10 segundos, la app consulta en SQL si el flag IsSyncing sigue activo.
Cuando el flujo termina, actualiza el flag a 0.
La app lo detecta, notifica al usuario y vuelve a habilitar la interfaz.

Para el usuario final, parece que la app ha estado esperando el resultado, pero sin bloqueos, sin errores y con feedback visual.

Lo interesante de este enfoque es que el botón puede bloquearse incluso si

Ahora sí, comencemos:

Paso 1: Crear la tabla del flag en Dataverse

Lo primero que necesitamos es un lugar donde tanto Power Automate como Power Apps puedan leer y escribir el estado del proceso.

Crea una tabla en Dataverse llamada Synchronization_Flag (o como prefieras), con estos campos:

Nombre del campo	Tipo de datos	Descripción
Name	Texto	Nombre o identificador del proceso. Ej: “Sincronización SQL”
IsSyncing	Sí/No (booleano)	Indica si el proceso está en curso (`true`) o ha terminado (`false`).
LastSyncDate	Fecha y hora	(Opcional) Guarda cuándo fue la última sincronización exitosa.

Puedes mantener un único registro (si solo hay un proceso de sincronización) o varios, si vas a tener distintos tipos de procesos. En mi caso voy a hacerlo así.

Paso 2: Crear un flujo de prueba en Power Automate

Ahora construiremos un flujo que simule un proceso largo (3 minutos, por ejemplo) y que actualice el flag antes y después de ejecutarse.

Este será el flujo completo, posteriormente lo explicaremos paso a paso:

Veamos ahora el desarrollo del flujo paso a paso:

2.1. Crear el flujo dentro de la solución con el desencadenador PowerApps (V2)

2.2. Responder a la aplicación inmediatamente: Esta acción responde de inmediato a PowerApps para evitar el timeout. El flujo seguirá ejecutandose en segundo plano

2.3. Obtener el flag en Dataverse: Traemos solo el primer registro del flag con sus dos columnas: el ID y el estado (IsSyncing).

Acción SyncFlagId:

outputs('List_rows_-_Get_SyncFlag_ID')?['body/value']?[0]?['eu_synchronization_flagid']

Acción SyncStatus:

outputs('List_rows_-_Get_SyncFlag_ID')?['body/value']?[0]?['eu_issyncing']

2.4. Comprobar si no está sincronizando:

Lado izquierdo de la igualdad

outputs('SyncStatus')

Lado derecho de la igualdad

false

2.5. Si no está sincronizando: Seteamos el Flag a “Syncing”

Row ID

{outputs('SyncFlagId')

IsSyncing: Yes

2.6. Delay de 3 minutos: Esto simula la acción que quieres realizar dentro de la app que tarda demasiado tiempo como para que sea de manera síncrona real

2.7. Seteamos el Flag a “Not Syncing”: De esta manera, la app podrá consultar si todavía está el proceso en curso

Paso 3: Configurar la aplicación en Power Apps

Con el flujo de Power Automate listo y el flag de sincronización en Dataverse, ahora toca construir la parte visual de Power Apps.

El objetivo:

Que el usuario pulse “Sincronizar”
Que el botón quede bloqueado mientras el proceso se ejecuta
Y que la aplicación detecte automáticamente cuándo termina el flujo.

En tu pantalla, crea la siguiente jerarquía de controles:

Este diseño agrupa toda la lógica visual de sincronización dentro de Container2, que contiene el botón y el spinner.

3.1 Configuración de visibilidad

Para crear el efecto de “botón bloqueado”:

Spinner1, Propiedad Visible:

_VarSyncing_

ButtonCanvas1, Propiedad Visible:

!_VarSyncing_

De este modo, mientras el proceso esté ejecutandose (_VarSyncing_ = true), el botón desaparecerá y se mostrará el spinner animado.

Cuando termine, el spinner se ocultará y el botón volverá a ser visible.

El resultado visual es un estado de espera fluido, sin necesidad de bloquear la aplicación completa.

3.2 Acción del botón “Sincronizar”

En la propiedad OnSelect del botón (ButtonCanvas1), escribe el siguiente código:

Refresh(Synchronization_Flags);
If(
    First(Synchronization_Flags).IsSyncing ,  
    
    // If it is syncing
    Set(_VarSyncing_, true);
    Set(_VarStartTimer_, true),
    
    // If it is NOT syncing
    Set(_VarSyncing_, true);
    Set(_VarStartTimer_, true);
    Flow_Sync_Test.Run()
)

Lo que hace esta fórmula:

Refresca la tabla Synchronization_Flags desde Dataverse.
Comprueba si el flag IsSyncing está activo.
Si ya está sincronizando, solo activa las variables locales para mantener el spinner.
Si no está sincronizando, lanza el flujo (Flow_SyncTest.Run()) y activa el spinner igualmente.

Resultado: El usuario ve que el botón se bloquea instantáneamente al hacer clic, mientras el flujo arranca y responde a la app.

3.3 Timer de comprobación (polling)

Ahora necesitamos que Power Apps “escuche” cada cierto tiempo si el proceso ya ha terminado. Para ello, selecciona el control Timer1 y configura sus propiedades:

Duration:

AutoPause:

false

Repeat:

true

Start:

_VarStartTimer_

OnTimerEnd:

Refresh(Synchronization_Flags);
If(
    !First(Synchronization_Flags).IsSyncing,
        // If it is NOT syncing
        Set(_VarStartTimer_, false);
        Set(_VarSyncing_, false)
)

De este modo, cada 10 segundos la app:

Actualiza la tabla Synchronization_Flag desde Dataverse
Comprueba el campo IsSyncing
Si detecta que ha pasado a false, detiene el Timer y oculta el spinner

Resultado

Cuando el usuario pulsa “Sincronizar”:

Se lanza el flujo Flow_Sync_Test.
_VarSyncing_ pasa a true, mostrando el spinner.
_VarStartTimer_ inicia el Timer de comprobación.

Mientras tanto, el flujo ejecuta su proceso largo (simulado con Delay).
Una vez termina, cambia el flag IsSyncing a false en Dataverse.
Power Apps detecta el cambio, detiene el Timer y muestra el botón nuevamente.

Todo sin bloqueos, sin errores por timeout y con una experiencia fluida para el usuario.

Conclusión

El límite de dos minutos entre Power Apps y Power Automate puede parecer, a primera vista, una barrera difícil de superar. Sin embargo, como has visto, no se trata de un problema técnico insalvable, sino de una cuestión de diseño de arquitectura.

En lugar de intentar extender el tiempo de espera o “forzar” un comportamiento síncrono, la clave está en simular la sincronía de manera controlada, separando la ejecución del proceso (flujo) de la experiencia del usuario (aplicación).

Con una tabla de control en Dataverse, un pequeño bucle de comprobación mediante un Timer y un flujo que actualiza el estado, conseguimos una experiencia completamente fluida:

La app responde inmediatamente, sin errores de timeout.
El usuario percibe que el sistema está “esperando” el resultado.
La interfaz permanece bloqueada y sincronizada con el estado real del proceso.

Este patrón no solo resuelve el caso de sincronización con SQL:
también puede aplicarse a cargas de datos masivas, integraciones lentas o procesos complejos de negocio que requieran varios minutos.

En definitiva, se trata de aprovechar las capacidades de Power Platform de forma inteligente: dejando que Power Automate haga el trabajo pesado y que Power Apps gestione la comunicación y la experiencia visual.

Un ejemplo perfecto de cómo mezclar asíncronía y control de estado para lograr una aplicación robusta, usable y profesional.

🚀Power Tower