“Ejecutar cada día a las ocho” parece una regla completa. En una automatización empresarial todavía faltan varias decisiones: ¿las ocho de qué zona?, ¿qué ocurre en un festivo?, ¿se procesa el trabajo acumulado tras una caída?, ¿y cómo se comporta el cambio de hora?
Un temporizador técnico solo inicia el flujo. El calendario operativo determina si ese inicio corresponde a una jornada válida y qué periodo de negocio debe procesar. Separar ambos conceptos evita que una expresión cron termine representando reglas que nadie puede auditar.
Define primero el contrato temporal
Antes de configurar el disparador, documenta estas entradas:
| Decisión | Ejemplo verificable |
|---|---|
| Zona horaria | Europe/Madrid, no “hora española” |
| Hora local objetivo | 08:00 |
| Días laborables | lunes a viernes según calendario ES-MAD |
| Festivos y cierres | tabla versionada con fecha, ámbito y motivo |
| Periodo procesado | jornada operativa anterior cerrada |
| Tolerancia | comenzar hasta 30 minutos tarde sin escalar |
| Recuperación | procesar una vez cada periodo pendiente |
La zona debe identificarse con una regla que conozca los cambios estacionales. Guardar un desfase fijo como UTC+1 falla cuando comienza el horario de verano. La documentación de recurrencia de Azure Logic Apps indica que seleccionar una zona horaria permite respetar esos cambios; también advierte que los disparadores basados únicamente en intervalo pueden desplazarse respecto a la hora local.
El festivo es un dato, no una condición dispersa
Codificar listas de fechas dentro de varios flujos hace difícil saber qué calendario utiliza cada proceso. Conviene mantener una fuente única con, al menos:
- fecha local;
- ámbito geográfico o sociedad;
- tipo de día: laborable, festivo, cierre especial o media jornada;
- versión y responsable de la modificación;
- instante desde el que la regla es válida.
El flujo consulta esa fuente al comenzar. Si el día no es procesable, registra la decisión y termina sin ejecutar efectos. Si varias sedes comparten automatización, el identificador del calendario debe formar parte de la configuración del proceso, no deducirse del servidor donde corre.
Ejemplo: una conciliación diaria
Supongamos una conciliación prevista a las 08:00 para movimientos del día laborable anterior.
- El disparador se configura a las 08:00 en
Europe/Madrid. - El flujo calcula la fecha local y consulta el calendario
ES-MAD. - Si es lunes después de un viernes laborable, selecciona el periodo del viernes; no resta simplemente 24 horas.
- Crea una clave idempotente como
conciliacion:2026-04-02. - Si esa clave ya está completada, no repite los efectos.
- Si faltan periodos por una indisponibilidad, los recupera en orden y con un límite explícito.
Esta clave separa el momento de ejecución del periodo de negocio. Un reinicio a las 09:10 puede terminar el mismo periodo sin duplicarlo. La idempotencia en pipelines aplica la misma idea a cargas de datos.
Casos que deben probarse
No basta con probar un martes ordinario. Incluye fechas concretas en pruebas automatizadas:
- víspera y día posterior al cambio de hora;
- lunes tras un festivo local;
- cierre mensual que cae en fin de semana;
- ejecución omitida por una caída;
- doble disparo del mismo periodo;
- cambio de calendario después de haber generado trabajo.
Microsoft permite elegir zona y hora de inicio en los flujos programados de Power Automate. Esa configuración resuelve parte del problema, pero no define los festivos, el cierre contable ni la recuperación. Esas son reglas de negocio y necesitan propietario.
Evidencias operativas mínimas
Cada ejecución debería registrar el instante UTC, la hora local calculada, la versión del calendario, el periodo elegido, la clave idempotente y el resultado. Una alerta útil distingue “no ejecutado porque era festivo” de “no ejecutado por error”.
Un calendario bien diseñado convierte “cada día a las ocho” en un contrato comprobable. También hace que un flujo RPA desatendido pueda recuperarse sin depender de que una persona interprete fechas y excepciones sobre la marcha.