Cuándo salir de Power Automate y llevar lógica a Azure Functions para ganar seguridad, trazabilidad, rendimiento y mantenimiento.
Power Automate es excelente para aprobaciones, notificaciones y orquestación simple. Pero cuando la lógica de negocio exige transformación compleja, autenticación OAuth, seguridad de secretos o volumen, Azure Functions suele ser la capa pro-code más limpia dentro de una solución Microsoft 365.
El caso de uso más común en mi experiencia: un web part de SPFx necesita consultar datos que residen en un sistema externo (ERP, CRM, base de datos legada). En lugar de llamar directamente desde el cliente (que expondría credenciales o tokens), el patrón correcto es: SPFx → Azure Function (con Managed Identity o Key Vault) → sistema externo → transformación → respuesta tipada. La Function actúa como API gateway y capa de transformación.
La decisión entre Functions y Power Automate se reduce a cuatro factores. (1) Latencia: Functions en plan Consumption en warm mode responde en <200ms; Power Automate añade 2-5 segundos de overhead por ejecución. (2) Complejidad de lógica: si hay bucles anidados, transformaciones JSON complejas o necesidad de paquetes npm, Functions gana por goleada. (3) Autenticación: Functions soporta Managed Identity, OAuth2 con client credentials y certificados; Power Automate depende de conectores premium que no siempre cubren APIs propietarias. (4) Operaciones: Functions se despliega con CI/CD estándar (GitHub Actions, Azure DevOps); Power Automate requiere soluciones ALM específicas de Power Platform.
Un antipatrón que veo con frecuencia: crear una Function que simplemente envuelve una llamada HTTP a Microsoft Graph. Para eso ya existe el MSGraphClient en SPFx, que maneja el token automáticamente. La Function debe añadir valor: agregar datos de múltiples fuentes, aplicar reglas de negocio que no deben residir en el cliente, o cachear resultados en Redis/Azure Storage para reducir llamadas a sistemas lentos.
Para el deployment, recomiendo usar el modelo Functions v4 programming model en TypeScript con triggers HTTP. El tipado con Zod para validación de entrada y la inyección de dependencias mediante el middleware de Functions proporcionan una experiencia de desarrollo muy cercana a una API tradicional. El cold start en plan Consumption (que puede añadir 2-5 segundos en frío) se mitiga con el plan Premium en producción o configurando un timer trigger que mantenga la Function warm con una llamada de health check.
La combinación sana en un proyecto Microsoft 365 suele ser: SharePoint o Teams como interfaz, SPFx cuando hace falta UI integrada, Azure Functions como capa de negocio serverless, Power Automate para aprobaciones y notificaciones, y Copilot/IA solo cuando aporta asistencia real. Cada herramienta en su lugar; esa es la arquitectura, no la lista de tecnologías.