Si hay un tema que genera confusión en Power Platform, es el licenciamiento. Microsoft actualiza los planes y condiciones periódicamente, los nombres cambian, las inclusiones varían, y la información online a menudo está desactualizada. Lo que voy a explicar aquí es la lógica del modelo — no precios concretos, porque esos cambian. Lo que no cambia es la estructura de decisión.
Los dos ejes: tipo de plan y tipo de conector
El licenciamiento de Power Apps se mueve en dos ejes. El primero es el tipo de plan: per user (un usuario puede usar todas las apps que necesite) y per app (un usuario puede usar una app concreta). El segundo eje es el tipo de conectores que usa la app: estándar (SharePoint, Office 365, Teams, OneDrive) o premium (Dataverse, HTTP, conectores custom, SAP, Oracle, entre otros).
Si tu app solo usa conectores estándar, los derechos incluidos con las licencias de Microsoft 365 pueden ser suficientes para escenarios básicos. En cuanto tu app usa un conector premium — y Dataverse es premium — necesitas un plan de Power Apps dedicado.
Los derechos incluidos con Microsoft 365
Las licencias de Microsoft 365 (E3, E5, Business Premium, etc.) incluyen derechos de uso de Power Apps y Power Automate, pero con limitaciones importantes. Puedes ejecutar apps que usen conectores estándar y puedes ejecutar flujos de nube con conectores estándar. Pero no puedes usar conectores premium, no puedes usar Dataverse como data source (salvo Dataverse for Teams, que tiene su propio modelo), y las capacidades son más limitadas.
Esto es relevante porque muchas empresas asumen que "como ya tenemos M365, Power Platform es gratis". Es parcialmente cierto para casos sencillos, pero en cuanto necesitas Dataverse, conectores premium, o funcionalidades avanzadas, necesitas licencias adicionales.
Dataverse y el impacto en el licenciamiento
Dataverse es probablemente la decisión que más impacto tiene en el licenciamiento. Usar Dataverse como backend de tu app significa que todos los usuarios de esa app necesitan un plan premium de Power Apps (per user o per app). Esto cambia la ecuación económica del proyecto.
La alternativa — usar SharePoint Lists para evitar el coste de licencia — es tentadora pero tiene implicaciones técnicas serias que explico en el artículo de Dataverse vs SharePoint. Mi recomendación: calcula el coste de licenciamiento de Dataverse desde el principio y preséntalo como parte del proyecto. Una decisión técnica forzada por desconocimiento del licenciamiento es una receta para problemas.
El error más común: no considerar el licenciamiento al diseñar la arquitectura
Esto pasa más de lo que debería: un equipo diseña una solución con Dataverse, conectores premium, y flujos avanzados, y cuando llega el momento de calcular el coste de licencias, el proyecto se para o se rediseña a la fuerza para evitar costes que nadie había previsto.
El licenciamiento debería ser una de las primeras conversaciones en cualquier proyecto de Power Platform — no la última. No porque el coste sea prohibitivo (en general, es razonable comparado con desarrollo custom), sino porque afecta directamente a las decisiones de arquitectura.
Multiplexing: el concepto que muchos desconocen
Hay un concepto en el licenciamiento de Microsoft que muchas empresas ignoran y que puede tener consecuencias serias: el multiplexing. Lo trato en detalle en un artículo específico, pero la idea es esta: no puedes usar un intermediario (una web, un servicio, una cuenta genérica) para que usuarios sin licencia accedan a funcionalidades de Power Platform. Cada usuario humano que se beneficia de la plataforma necesita su propia licencia.
Mi recomendación: entiende el modelo antes de elegir la arquitectura
No pretendo que cada empresa se convierta en experta en licenciamiento de Microsoft — es un tema que cambia y tiene matices. Pero sí recomiendo que antes de empezar cualquier proyecto, alguien revise qué licencias tienen, qué necesitarán según la arquitectura propuesta, y cuánto costará. Es una conversación de una hora que puede ahorrar meses de problemas. Y siempre recomiendo consultar la documentación oficial de Microsoft actualizada, porque los detalles específicos cambian con frecuencia.