Qué es Power Apps
Microsoft Power Apps es una plataforma de desarrollo de aplicaciones empresariales con herramientas visuales, fórmulas y conexiones a datos. Permite construir aplicaciones de lienzo y basadas en modelos, dentro del ecosistema Power Platform. El desarrollo puede combinar configuración de bajo código con extensiones profesionales.
Una aplicación útil organiza una interacción: qué necesita hacer la persona, qué información ve, qué puede modificar y cómo sabe que ha terminado. La pantalla es solo una parte. También se necesitan datos coherentes, reglas, permisos y una forma de atender errores o cambios posteriores.
Documentación de referencia: What is Power Apps?.
Origen y evolución del producto
Microsoft presentó PowerApps el 30 de noviembre de 2015 con el propósito de facilitar aplicaciones empresariales y conexiones a servicios. La disponibilidad general llegó el 1 de noviembre de 2016, junto con Microsoft Flow. La propuesta fue ampliándose desde construcción visual hacia gestión de datos, procesos y desarrollo asistido.
En marzo de 2021 Microsoft presentó Power Fx como lenguaje de fórmulas de bajo código basado en Excel. En mayo de 2022 anunció Power Pages para creación de sitios; los antiguos Power Apps Portals deben entenderse dentro de esa evolución, no como una tercera modalidad actual equivalente a lienzo y modelos.
Los cambios de nombre y catálogo explican diferencias entre manuales. Antes de reutilizar una solución, identificar el tipo de aplicación, el servicio de datos y la fecha de la documentación. Un nombre similar no demuestra que dos productos tengan los mismos permisos o condiciones de licencia.
Documentación de referencia: Introducing Microsoft PowerApps, November 2015 · General availability of PowerApps and Flow, November 2016 · Introducing Microsoft Power Fx, March 2021 · Power Platform at Build 2022: Power Pages.
Aplicaciones de lienzo y basadas en modelos
Las aplicaciones de lienzo permiten controlar pantallas y propiedades de los elementos mediante Power Fx y conectores. Las basadas en modelos organizan la experiencia a partir de tablas, relaciones, formularios y vistas en Dataverse. Su mayor consistencia procede de una estructura compartida, mientras que el lienzo ofrece más control visual.
Para elegir, observar qué domina el problema. Una interacción breve y muy específica puede requerir una pantalla diseñada a medida. Un proceso con muchos registros relacionados puede beneficiarse de navegación y formularios basados en el modelo. El criterio debería incluir mantenimiento y facilidad de uso.
Ambos enfoques necesitan una definición de datos y permisos. Un prototipo visual no debería decidir de forma accidental quién puede consultar o cambiar información. Probar con los roles reales antes de ampliar el uso.
Documentación de referencia: Model-driven app overview and canvas comparison.
Dataverse y diseño de los datos
Dataverse almacena información en tablas, filas y columnas, con tablas estándar y personalizadas y controles de acceso por roles. Es una base de datos y gestión compartida por aplicaciones de Power Platform. La evolución de su catálogo incluye Dataverse for Teams, anunciado como disponible en noviembre de 2020.
Un modelo sencillo para solicitudes de materiales puede separar centros, materiales y solicitudes. Cada conjunto necesita identificadores estables. Relacionarlos evita repetir nombres y permite retirar un material sin borrar las solicitudes históricas que lo referenciaban.
Definir qué significa cada estado y quién puede cambiarlo. «Preparado», «aprobado» y «entregado» describen hechos distintos. Si todos se reducen a un único indicador, la aplicación pierde capacidad para explicar qué trabajo queda pendiente y qué evidencia respalda el resultado.
Documentación de referencia: What is Microsoft Dataverse? · Dataverse for Teams, November 2020.
Fórmulas y reglas comprensibles
Power Fx expresa lógica mediante fórmulas y se inspira en la familiaridad de Excel. La similitud facilita el aprendizaje, pero una aplicación debe gestionar interacción, estado y datos compartidos. Conocer hojas de cálculo ayuda; no elimina la necesidad de probar el comportamiento completo.
Una regla de cantidad debería distinguir valor vacío, cero, negativo y superior al límite acordado. Un mensaje comprensible explica cómo corregir el dato. Ocultar el error o sustituirlo por un valor por defecto puede hacer que una solicitud parezca válida sin serlo.
Separar reglas de presentación y reglas del proceso. Cambiar el color de un estado puede mejorar lectura, pero el permiso para aprobar debe aplicarse donde se controla el dato. Documentar ejemplos de entradas admitidas y rechazadas facilita comprobar cambios y transferir el mantenimiento.
Documentación de referencia: Introducing Microsoft Power Fx, March 2021.
Compartir la aplicación y proteger las fuentes
Compartir una aplicación de lienzo no concede automáticamente todos los permisos sobre sus fuentes. Microsoft indica que deben revisarse tablas de Dataverse y otros recursos, como archivos de Excel conectados. La aplicación y los datos tienen controles que deben funcionar de forma coherente.
Probar al menos los perfiles de quien solicita, quien revisa y quien administra. La comprobación debería incluir lectura y modificación, tanto desde la pantalla como en los recursos accesibles por otros caminos. Una lista filtrada visualmente no demuestra aislamiento de información.
Antes de entregar, dejar claro quién añade o retira usuarios y qué ocurre cuando alguien cambia de puesto. Un acceso que fue adecuado en el piloto puede dejar de serlo al ampliar el alcance. Conservar un inventario de fuentes y roles facilita esa revisión.
Documentación de referencia: Share a canvas app and its data sources.
Consultas, delegación y resultados incompletos
La delegación permite que una consulta se procese en la fuente. Cuando una operación no es delegable, Power Apps puede trabajar solo con un subconjunto local. La documentación vigente indica 500 registros por defecto y un límite configurable hasta 10.000; aumentar ese valor no resuelve por sí solo el diseño de la consulta.
El riesgo práctico es una respuesta aparentemente correcta pero incompleta. Una búsqueda de solicitudes pendientes puede devolver cero si los registros relevantes quedaron fuera del conjunto recuperado. Ese resultado no debería interpretarse automáticamente como ausencia de trabajo.
Probar con datos suficientes para superar el límite configurado e incluir casos conocidos al final del conjunto. Comparar contra la fuente y revisar advertencias del editor. En un informe auxiliar de SST, la cobertura de registros forma parte de la calidad del dato, además de su formato.
Documentación de referencia: Understand delegation in canvas apps.
Uso móvil y trabajo sin conexión
Las aplicaciones de lienzo pueden funcionar sin conexión mediante Power Apps Mobile, con capacidades específicas para Dataverse o almacenamiento local limitado mediante funciones. La documentación excluye el funcionamiento offline de aplicaciones de lienzo en navegadores. No basta con abrir la misma pantalla en un teléfono para disponer de sincronización.
Definir qué información se descarga, cuánto tiempo puede utilizarse y qué ocurre al recuperar conexión. Una referencia que estaba vigente al comenzar la jornada puede haber cambiado. La pantalla debería distinguir datos locales pendientes de sincronizar de datos confirmados en la fuente.
La prueba debe incluir pérdida de cobertura, cierre de la app, reconexión y modificación concurrente. Verificar que no se pierde ni duplica la solicitud. Para materiales preventivos, mostrar versión y fecha ayuda a identificar contenido que requiere actualización antes de utilizarlo.
Documentación de referencia: Develop offline-capable canvas apps.
Accesibilidad y diseño adaptable
Microsoft ofrece pautas de diseño adaptable y un comprobador de accesibilidad para aplicaciones de lienzo. Las guías contemplan etiquetas, contraste, lectura y navegación. Estos recursos ayudan a revisar la aplicación, pero su uso no equivale a certificar automáticamente toda la experiencia.
La guía de accesibilidad de Defra identifica problemas conocidos en Power Apps y remite a comprobaciones de controles concretos. Es una referencia práctica que refuerza la necesidad de probar la aplicación real, en lugar de asumir accesibilidad por utilizar una plataforma determinada.
En una app de apoyo a SST, probar lectura con ampliación, navegación por teclado, mensajes de error y botones en pantalla pequeña. No transmitir estados únicamente mediante color. El recorrido debe permitir corregir un dato sin perder toda la solicitud y confirmar qué se ha guardado.
Documentación de referencia: Build responsive canvas apps · Create accessible canvas apps · Defra: Power Apps accessibility guidance.
Creación asistida y páginas generativas
Las páginas generativas permiten describir una página de una aplicación basada en modelos mediante lenguaje natural y seleccionar datos de referencia. El sistema genera código React y permite refinar el resultado. Algunas conexiones, como determinados conectores y API personalizadas, aparecen documentadas en versión preliminar.
La generación puede acelerar una primera interfaz, pero el resultado debe revisarse como cualquier desarrollo. Comprobar campos utilizados, operaciones de escritura, permisos y comportamiento con datos vacíos. Una captura atractiva no demuestra que la lógica cumpla el objetivo.
Para un piloto, pedir una pantalla acotada y definir ejemplos de aceptación antes de generarla. Comparar la propuesta con esos ejemplos, registrar ajustes y verificarla con roles distintos. La revisión debe incluir el dato guardado en la fuente, además de lo que se muestra en pantalla.
Documentación de referencia: Generate a page using natural language.
Pruebas, publicación y mantenimiento
Power Apps dispone de recursos de comprobación, seguimiento de eventos y pruebas. Test Studio permite definir pruebas mediante expresiones o grabación de interacciones. La gestión del ciclo de vida de Power Platform organiza desarrollo, prueba, despliegue y operación de las soluciones.
Una prueba completa empieza en una necesidad y termina en un resultado persistido. Para una solicitud, comprobar que se crea una sola vez, que la persona adecuada puede revisarla y que un usuario sin permiso no puede modificarla. Incluir fallos de conexión y datos desactualizados.
La entrega debería conservar una versión identificable, un responsable y un procedimiento de cambio. Las correcciones deben probarse antes de afectar al uso real. Documentar fuentes, campos y dependencias facilita que otra persona mantenga la aplicación sin reconstruir sus decisiones originales.
Documentación de referencia: Testing and monitoring in Power Apps · Power Apps Test Studio · Application lifecycle management in Power Platform.
Licencias y cambios anunciados en desarrollo
El catálogo distingue uso para desarrollo y pruebas de licencias para ejecutar aplicaciones empresariales. Los conectores, Dataverse y capacidades de administración deben comprobarse para los usuarios reales. Que una cuenta pueda crear una app no demuestra que toda la organización tenga derecho a utilizarla.
Microsoft prevé para entornos de desarrollador no administrados: fin de creación el 15/11/2026, suspensión el 15/12/2026 y eliminación el 15/01/2027. Son fechas futuras respecto a esta revisión.
El presupuesto debería incluir usuarios, datos, administración y mantenimiento. Antes de construir, comprobar si un formulario o una función ya disponible resuelve la necesidad. Una aplicación a medida aporta valor cuando mejora una interacción concreta y existe capacidad para sostenerla después del piloto.
Documentación de referencia: Power Apps licensing and pricing · Announced changes to developer environments.
Aplicaciones en seguridad y salud en el trabajo
En SST, una aplicación acotada puede recoger solicitudes de materiales, organizar propuestas de temas para sesiones o facilitar consulta de un catálogo aprobado. Su valor está en estructurar una interacción y reducir datos incompletos. Sabentis propone estos ejemplos como apoyos auxiliares; antes de construir, comprobar si el sistema corporativo ya resuelve el proceso evita duplicar registros o generar una segunda versión de información preventiva.
Ejemplo desarrollado y comprobaciones
Una aplicación podría permitir solicitar materiales de una campaña indicando centro, idioma y cantidad. El equipo recibiría registros estructurados y comprobaría las necesidades antes de preparar los materiales, sin convertir la aplicación en un sistema de evaluación de riesgos.
- Definir tres conjuntos de datos: materiales vigentes, centros autorizados y solicitudes, con identificadores estables.
- Diseñar una pantalla que permita elegir material, idioma y cantidad, mostrando la versión del recurso.
- Separar los permisos de quien solicita de los de quien revisa; probarlos con cuentas de cada rol.
- Validar cantidades, campos obligatorios y selección de materiales retirados, mostrando mensajes comprensibles.
- Comprobar que una solicitud guardada aparece una sola vez en la fuente y que su estado coincide en la aplicación.
El ensayo debe incluir pérdida de conexión, doble pulsación y cambios de catálogo mientras alguien tiene el formulario abierto. Un mensaje de éxito solo debe mostrarse cuando el guardado haya concluido. El resultado esperado es una petición trazable y revisable, sin que la aplicación prometa existencias, envío o aprobación que el proceso todavía no ha confirmado.
Limitaciones y condiciones de uso
Crear una pantalla es solo una parte del trabajo. Deben validarse permisos, reglas, datos y funcionamiento ante errores; la disponibilidad de conectores, capacidad y funciones depende de la configuración y licencia, y requiere mantenimiento cuando cambian los procesos.
Ocultar un botón o filtrar una pantalla no constituye por sí solo una regla de acceso a los datos. Las conexiones y permisos deben revisarse en la fuente correspondiente. Un prototipo también puede fallar cuando aumenta el volumen o cambian columnas y relaciones. Licencias, conectores y capacidad se deben comprobar para los usuarios reales, no únicamente para la cuenta que construye la aplicación.
Cómo elegir y complementar la herramienta
Elegir Power Apps cuando existe un proceso definido, fuentes compatibles y responsables de administración en el ecosistema Microsoft. Power BI puede complementar el análisis agregado de solicitudes; Excel puede ayudar a preparar un catálogo inicial, evitando convertir copias dispersas en fuentes paralelas. Si solo se necesita una consulta ocasional, valorar el coste de mantener una aplicación completa.
La entrega debería incluir propietario funcional, responsable técnico, diccionario de campos y procedimiento para cambios. Separar desarrollo, prueba y uso real permite comprobar una modificación antes de afectar a quienes dependen del proceso. La apariencia terminada no demuestra que esos aspectos estén resueltos.
Preguntas frecuentes
¿Aplicación de lienzo y basada en modelos son equivalentes?
No. La primera prioriza control del diseño; la segunda organiza la experiencia alrededor de datos y relaciones en Dataverse.
¿Compartir la aplicación concede acceso a todos sus datos?
No necesariamente. Deben configurarse los permisos de las fuentes y recursos que utiliza.
¿Bajo código significa que no hace falta mantenimiento?
No. Cambios de procesos, permisos, conexiones o datos pueden exigir ajustes y nuevas comprobaciones.
