Introducción

En el primer artículo hablábamos de flujos que envejecen bien: flujos que se entienden, que no dan miedo al abrirlos y que no se rompen cada vez que alguien los toca. Hablábamos de nombres claros, de no abusar de Apply to each, de pensar antes de arrastrar acciones. En definitiva, de sobrevivir al caos inicial.

Esta segunda etapa aparece cuando ese caos inicial ya está más o menos bajo control… pero el volumen de trabajo sigue aumentando. Es el momento en que Power Automate deja de ser un flujo improvisado un día cualquiera y empieza a convertirse en un componente real del sistema: algo que ejecuta procesos críticos, maneja datos relevantes y que, dentro de seis meses, alguien tendrá que mantener (posiblemente tú mismo).

Aquí no vamos a repetir lo básico. Vamos a hablar de criterio, de decisiones de diseño y de pensar el flujo como algo que va a vivir en producción.

Diseña el flujo como si fuera código (aunque no lo sea)

Power Automate es low‑code, pero eso no significa que puedas dejar de pensar como desarrollador. Un flujo que envejece bien tiene una estructura reconocible: sabes dónde empieza, qué transforma, dónde decide y cómo termina. Cuando abres el diseñador, tu cerebro debería poder “leer” el flujo sin ejecutarlo mentalmente paso a paso.

Por ejemplo, imagina un flujo que se dispara al crear una solicitud en Dataverse. Un diseño sano sería: primero validar los datos de entrada, después enriquecer la información (buscar responsable, equipo, prioridad), luego tomar decisiones y, por último, ejecutar acciones externas como notificaciones o integraciones. Todo eso se puede reflejar visualmente usando Scope como bloques funcionales, no solo como contenedores de errores.

Si no eres capaz de explicar qué hace tu flujo en tres frases —sin abrir Power Automate— el problema no es quien lo lee. El problema es el flujo.

La configuración es dato, no lógica

Uno de los motivos por los que los flujos envejecen mal es porque mezclan lógica con decisiones de negocio. Correos escritos a mano en condiciones, GUIDs pegados en un Switch, valores que hoy son válidos pero mañana cambian.

Imagina un flujo que, según el tipo de incidencia, envía una notificación a un equipo distinto. La mala solución es un Switch con tres casos y tres direcciones de correo. La buena solución es una tabla de Dataverse llamada, por ejemplo, Configuración de notificaciones, donde cada tipo de incidencia tiene asociado su destinatario.

El flujo deja de “decidir” y pasa a consultar. Y eso cambia todo: menos versiones, menos miedo a tocar el flujo y más control desde negocio sin necesidad de abrir Power Automate.

El trigger también se diseña (no se acepta por defecto)

Muchos flujos empiezan mal desde el primer segundo. Se acepta el trigger tal cual viene y se confía en que “ya filtraremos luego”. El resultado son ejecuciones innecesarias, consumo de cuotas y flujos que se disparan cuando no deberían.

Si tu flujo se dispara al modificar un registro de Dataverse, pregúntate: ¿Todas las modificaciones importan? ¿O solo cuando cambia el estado a “Aprobado”? Usar Trigger Conditions para filtrar desde el inicio no es una optimización prematura; es una buena práctica básica para flujos que van a vivir mucho tiempo.

Cada ejecución que evitas es deuda técnica que no se genera.

Variables con intención (y con ciclo de vida)

En Power Automate todas las variables parecen iguales, pero no lo son. Hay variables que controlan el flujo, otras que acumulan datos y otras que representan un resultado final. Mezclarlas o reutilizarlas “porque ya existe una” es una receta perfecta para la confusión.

Por ejemplo, una variable llamada varResultado que primero guarda un booleano, luego un texto y más tarde un JSON es cómoda hoy… y un infierno mañana. En cambio, variables como varTieneErrores, varTotalImporte o varRespuestaAPI cuentan una historia por sí solas.

Inicializar las variables cerca de donde se usan y darles un nombre con intención es una inversión mínima que se amortiza cada vez que vuelves a abrir el flujo.