Una Fabric App es útil cuando el usuario no solo necesita ver un número, sino actuar sobre él: fijar un objetivo, clasificar, aprobar o registrar un estado. Consulta datos gobernados desde el modelo semántico y escribe datos operativos en una capa preparada para eso. No sustituye a un dashboard ni a una solución transaccional completa.
Muchos equipos llegan a un punto en el que el informe explica bien la realidad, pero nadie puede cambiarla desde ahí. El usuario mira una métrica, entiende que va mal y luego abre otra herramienta, escribe en una planilla suelta o manda un correo para dejar constancia de una decisión. Ese salto es donde una Fabric App puede tener sentido, y también donde conviene tener criterio antes que entusiasmo.
Qué problema resuelve una app operativa
En lectura, explicación y gobierno de métricas, Power BI junto al modelo semántico cumple muy bien. El límite aparece cuando el flujo necesita objetivos, clasificaciones, notas, aprobaciones o previsiones manuales. Esas acciones no pertenecen al informe: pertenecen a una capa escribible.
Una Fabric App empaqueta una experiencia de datos propia. Con ella, una organización crea una interfaz que consulta datos gobernados y escribe datos operativos en una base SQL administrada por Fabric. La lectura sigue saliendo del modelo semántico, con sus medidas y dimensiones oficiales. La escritura vive aparte, en una capa transaccional con permisos definidos.
La distinción es la clave del tema. Un dashboard responde "qué está pasando". Una app operativa responde "qué está pasando y qué voy a hacer con eso", y deja registro de la acción.
En qué se diferencia de un dashboard y de un sistema transaccional
Es fácil confundir una app operativa con un informe más vistoso o con un sistema de gestión completo. No es ninguno de los dos.
Una app ejecutiva no debe parecer un informe disfrazado. Si solo muestra gráficos y tablas, un informe de Power BI hace el mismo trabajo con menos costo. La app se justifica cuando el usuario debe cargar, aprobar, definir objetivos o recorrer un proceso.
Tampoco es un sistema transaccional completo. Fabric aporta alojamiento y servicios, pero los secretos, los permisos mínimos, las reglas expuestas en la interfaz y el cumplimiento siguen siendo responsabilidad del equipo. Si el caso necesita autenticación personalizada, transacciones complejas o garantías propias de una función estable, se diseña una capa de aplicación alternativa fuera de Fabric.
| Superficie | Para qué sirve | Cuándo se queda corta |
|---|---|---|
| Dashboard de Power BI | Ver, explorar y explicar métricas gobernadas | Cuando el usuario debe actuar y dejar registro |
| Fabric App operativa | Leer del modelo y escribir objetivos, estados y aprobaciones | Cuando el caso exige autenticación propia o transacciones complejas |
| Backend externo | Autenticación propia, garantías y contratos estrictos | Cuando bastaba una capa ligera dentro de Fabric |
Cómo separa datos, identidad y permisos
El valor de una app operativa depende de que no rompa el gobierno. La capa de consumo no debe saltarse las reglas del modelo: debe traducirlas a una experiencia útil por rol.
Por eso la separación entre consulta, identidad y acceso a las fuentes importa. La documentación de modelos de datos y permisos de datos distingue qué consulta la aplicación, con qué identidad y con qué acceso a cada fuente. Una cosa es la definición de una métrica, otra es quién puede verla y otra es quién puede escribir sobre la capa operativa.
Ese detalle define un principio de diseño: la escritura no ocurre sobre el modelo semántico. El modelo se lee. Los objetivos, las clasificaciones y las notas se escriben en una base SQL hija, con permisos declarados en el modelo de datos, tal como describe la guía de permisos de datos. Mezclar ambas cosas convierte al informe en una fuente paralela y rompe la única verdad.
Cómo fluyen la lectura y la escritura
Una Fabric App operativa suele organizarse en capas claras, y cada una responde a un criterio distinto.
- Lectura analítica. La aplicación consulta el modelo semántico con medidas y dimensiones gobernadas. Los valores reales, los formatos y las definiciones salen del modelo, no de cálculos improvisados en la interfaz.
- Escritura. La aplicación escribe en la base SQL hija a través de la Data API que genera Fabric Apps. Es una capa transaccional con permisos propios, separada del modelo.
- Retorno analítico. El SQL analytics endpoint expone una copia de solo lectura para Power BI, Excel o modelos enriquecidos. Si hay latencia, se documenta.
- Metadata de métricas. La aplicación lee del modelo la definición, el formato, la tendencia, el orden y la dimensión sugerida, en lugar de fijar reglas de negocio dentro del código de la interfaz.
Un patrón concreto lo aclara: los objetivos. Una tabla de objetivos guarda la métrica, el equipo, el escenario, el tipo de período, el período, el valor, la moneda, el estado, el responsable y la auditoría. El usuario no debería tipear nombres ni fechas sueltas; el período se deriva del calendario de gestión. La app puede mostrar el objetivo recién guardado desde la respuesta de la API, aunque el modelo analítico tenga una actualización pendiente.
Dónde termina el navegador y empieza el servidor
Este es el límite productivo más importante y el que más se pasa por alto. El navegador no guarda tokens, no realiza inserciones sensibles ni decide permisos por su cuenta.
Si una acción debe actualizar Power BI REST, Scorecards u otro sistema con permisos de escritura, la llamada se ejecuta en una función del lado del servidor, una CLI operada o un backend seguro. Una regla compartida que se invoca desde varios canales encaja bien en User Data Functions, la lógica sin servidor que revisamos en detalle en la guía sobre escritura gobernada con User Data Functions. Exponer un token de escritura en la interfaz es el error que convierte una app útil en un riesgo.
Hay una alternativa que solo sirve para desarrollo: localStorage. Ayuda a prototipar, pero nunca es fuente productiva y debe estar marcada como tal para que nadie la confunda con la escritura gobernada.
Qué mirar antes de decidir el despliegue
No todo necesita una aplicación, y Fabric Apps agrega condiciones que conviene revisar antes de comprometer un plan.
- Madurez. Fabric Apps está en versión preliminar, no está disponible en todas las regiones y requiere la habilitación del administrador del tenant.
- Autenticación. En producción utiliza Fabric SSO. Si el caso pide identidad personalizada, se necesita otra capa.
- Latencia. Si el SQL analytics endpoint introduce demora, se documenta y se decide si el caso tolera esa espera.
- Alcance de la escritura. Se define qué se escribe dentro de Fabric y qué exige un backend seguro por fuera.
- Operación. Los cambios importantes deben poder probarse, aprobarse y revertirse, apoyados en versionado y en pipelines de despliegue entre entornos.
Esa lista es también el borde donde una empresa suele necesitar acompañamiento, porque cada respuesta cambia la arquitectura. Evaluar fuentes, permisos, responsables y preparación antes de comprometer una experiencia operativa evita construir sobre supuestos frágiles. Si quieres ver cómo encaja esta capa en un sistema mayor, la guía sobre un sistema de datos e IA sobre Microsoft da el mapa completo.
Antes de proponer una Fabric App a tu equipo, escribe la acción exacta que el usuario no puede hacer hoy desde el informe (fijar un objetivo, aprobar, clasificar) y confirma que esa escritura tiene una tabla, una clave lógica que evita duplicados y un responsable definido. Si esos tres elementos no existen todavía, el problema no es de interfaz: es de modelo, y ahí es donde conviene empezar. Y si quieres ver en la práctica cómo se construye una capa operativa con datos gobernados, mira la demo gratuita.
Preguntas relacionadas
¿Una Fabric App reemplaza a un informe de Power BI?
No. La app lee del mismo modelo semántico que alimenta a Power BI y suma una capa de escritura para objetivos, estados o aprobaciones. Si el usuario solo necesita ver y explorar métricas, un informe de Power BI resuelve el caso con menos costo.
¿La aplicación escribe sobre el modelo semántico?
No. El modelo semántico se lee. La escritura ocurre en una base SQL hija administrada por Fabric, con permisos declarados en el modelo de datos. Escribir sobre el modelo crearía una fuente paralela y generaría cifras contradictorias entre el informe y la aplicación.
¿Se pueden guardar tokens de escritura en el navegador?
No. El navegador no guarda tokens ni decide permisos. Toda acción con permisos de escritura, como actualizar Power BI REST o un Scorecard, se ejecuta en una función del lado del servidor, una CLI operada o un backend seguro.
¿Qué condiciones de Fabric Apps hay que revisar antes de planear?
Que está en versión preliminar, que no está en todas las regiones y que requiere habilitación del administrador del tenant. En producción usa Fabric SSO, por lo que una identidad personalizada exige otra capa. También conviene medir la latencia del SQL analytics endpoint.
¿Cuándo conviene un backend externo en lugar de una Fabric App?
Cuando el caso exige autenticación propia, transacciones complejas, garantías adicionales o integración fuera de Fabric. En ese escenario se define un contrato de API, secretos, observabilidad y sincronización con la capa analítica, en lugar de forzar todo dentro de la aplicación.