Diseña un flujo que evite bucles infinitos: errores que debes evitar

Un bucle infinito en un flujo de Power Automate hace que el flujo se ejecute repetidamente sin detenerse. Esto puede consumir tus límites de solicitudes de API, ralentizar tu entorno y desencadenar acciones no deseadas. La causa más común es un desencadenador que se vuelve a activar debido a una acción que el propio flujo realiza. Este artículo explica los errores típicos que crean bucles infinitos y cómo diseñar flujos que se detengan cuando deberían.

Por qué ocurren los bucles infinitos en Power Automate

Un bucle infinito ocurre cuando un desencadenador de flujo se activa por una acción que el mismo flujo realiza. Por ejemplo, un flujo que se desencadena con un nuevo elemento en una lista de SharePoint y luego actualiza ese mismo elemento, hace que la actualización active el desencadenador nuevamente. Este ciclo se repite hasta que el flujo alcanza un límite de servicio o lo detienes manualmente. La causa raíz es la falta de una condición de protección que distinga entre una acción del usuario y una acción del flujo.

Power Automate no detecta ni bloquea automáticamente los desencadenadores autorreferenciados. La plataforma asume que el diseñador del flujo ha implementado la lógica adecuada para evitar la reactivación. Sin esa lógica, cualquier actualización en la misma fuente de datos que el desencadenador supervisa reiniciará el flujo. Esto es por diseño, pero te responsabiliza de agregar los controles correctos.

Pasos para diseñar un flujo que evite bucles infinitos

Utiliza los siguientes métodos para prevenir bucles infinitos. Aplica al menos una de estas técnicas a cada flujo que actualice la misma fuente de datos que monitorea.

Método 1: Agregar una condición de desencadenador que excluya la cuenta del flujo

1. Abrir la configuración del desencadenador
   En Power Automate, selecciona el paso del desencadenador. Haz clic en el menú de puntos suspensivos y elige Configuración.
2. Agregar una condición de desencadenador
   En la sección Condiciones del desencadenador, agrega una expresión que verifique el campo Modificado por. Usa la expresión: @not(equals(triggerOutputs()?[‘body/Editor/Claim’], ‘i:0#.f|membership|flowaccount@domain.com’)). Reemplaza la dirección de correo electrónico con la cuenta de servicio real que ejecuta el flujo.
3. Guardar y probar
   Guarda el flujo. Crea un nuevo elemento manualmente para verificar que el flujo se ejecute. Luego actualiza ese elemento usando la cuenta del flujo para confirmar que el flujo no se vuelva a activar.

Método 2: Usar una columna de seguimiento de cambios

1. Agregar una columna Sí/No a la lista
   En SharePoint, agrega una columna llamada FlowProcessed con el tipo Sí/No. Establece el valor predeterminado en No.
2. Modificar la condición del desencadenador
   En el desencadenador del flujo, agrega una condición que verifique si FlowProcessed es igual a false. Usa la expresión: @equals(triggerOutputs()?[‘body/FlowProcessed’], false).
3. Actualizar la columna después del procesamiento
   Al final del flujo, agrega una acción para actualizar el elemento actual. Establece la columna FlowProcessed en Sí. Esto evita que el flujo se active nuevamente en el mismo elemento.

Método 3: Limitar la frecuencia de ejecución

1. Abrir la configuración del desencadenador
   Selecciona el paso del desencadenador y haz clic en Configuración.
2. Establecer un número máximo de ejecuciones
   En la sección Condiciones del desencadenador, agrega una expresión que limite el número de ejecuciones. Por ejemplo, usa: @lessOrEquals(triggerOutputs()?[‘headers/x-ms-workflow-run-id’], 1). Esto permite solo una ejecución por elemento.
3. Probar con múltiples actualizaciones
   Actualiza el mismo elemento varias veces. El flujo debería ejecutarse solo una vez.

Errores comunes que crean bucles infinitos

Actualizar el mismo elemento sin una protección

El error más frecuente es agregar una acción Actualizar elemento sin ninguna condición que impida que el desencadenador se active nuevamente. Si el flujo actualiza la misma lista o biblioteca que lo inició, la actualización desencadena una nueva ejecución. Siempre agrega una condición, una columna de seguimiento de cambios o una condición de desencadenador antes de la acción de actualización.

Usar un desencadenador de recurrencia que actualiza los mismos datos

Un flujo programado que se ejecuta cada minuto y actualiza una lista de SharePoint puede crear un bucle de retroalimentación si la acción de actualización modifica un campo que el propio flujo verifica. En su lugar, diseña el flujo para que solo actualice los elementos que no han sido procesados. Usa una consulta de filtro en la acción Obtener elementos para seleccionar solo los elementos donde la columna de estado no sea Completado.

Ignorar el campo Modificado por

Cuando actualizas un elemento en SharePoint, el campo Modificado por cambia a la cuenta que realizó la actualización. Si el flujo usa una cuenta de servicio, esa cuenta se convierte en el Modificado por. Una condición de desencadenador que verifica la cuenta del flujo es una forma confiable de detener la reactivación. Muchos diseñadores olvidan incluir esta verificación.

No usar una condición de terminación en bucles Do Until

Dentro de un flujo, una acción Do Until puede repetirse indefinidamente si nunca se cumple la condición de salida. Por ejemplo, un bucle que espera que una columna cambie a Aprobado se ejecutará para siempre si la columna nunca cambia. Establece un número máximo de iteraciones en la configuración de Do Until. El valor predeterminado es 60, pero puedes reducirlo a 10 o 20 según tu escenario.

Tipo de desencadenador vs flujo programado: diferencias clave para la prevención de bucles

Elemento	Desencadenador automático (por ejemplo, Cuando se crea un elemento)	Desencadenador programado (por ejemplo, Recurrencia)
Riesgo de bucle	Alto — el desencadenador se activa con cada cambio, incluidos los cambios realizados por el flujo	Medio — el desencadenador se activa según una programación, pero las actualizaciones aún pueden causar reactivaciones si el flujo se ejecuta nuevamente
Método de protección principal	Condición de desencadenador o columna de seguimiento de cambios	Consulta de filtro en Obtener elementos para excluir elementos ya procesados
Control de límite de ejecución	Condiciones de desencadenador y número máximo de ejecuciones	Intervalo de recurrencia y límite de iteraciones de Do Until
Ideal para	Procesamiento en tiempo real de datos nuevos o modificados	Procesamiento por lotes en una programación fija

Ahora puedes diseñar flujos que se detengan correctamente agregando condiciones de desencadenador, columnas de seguimiento de cambios o límites de frecuencia de ejecución. Comienza revisando tus flujos existentes para detectar cualquier acción de actualización que apunte a la misma fuente de datos que el desencadenador. Aplica al menos un método de protección a cada flujo. Para flujos complejos, combina una condición de desencadenador con una columna de seguimiento de cambios para una doble protección.