Para que un usuario pueda actuar (fijar objetivos, aprobar, clasificar o dejar notas) sobre datos gobernados, se agrega una capa escribible separada del modelo semántico. La lectura sigue en Power BI y el modelo semántico, la lógica de negocio vive en User Data Functions y el estado se guarda en una base transaccional como SQL Database o Cosmos DB. Los datos escritos regresan al análisis por Direct Lake, el SQL analytics endpoint o una API. Nunca se exponen tokens de escritura en la interfaz.
¿Por qué el modelo semántico no alcanza para escribir?
El modelo semántico es la referencia compartida de las métricas del negocio. Es excelente para leer, explicar y gobernar cifras: todos ven los mismos números en Power BI, Excel o cualquier IA. Pero está diseñado para lectura analítica, no para guardar estados que cambian por decisión de una persona.
Si todavía no tienes del todo claro qué es la capa de escritura y acción operativa y para qué sirve, conviene partir de esa definición antes de implementarla. Cuando el flujo necesita objetivos, clasificaciones manuales, notas, aprobaciones o previsiones que un usuario ingresa a mano, esa información no nace en la fuente operativa. Necesita un lugar preparado para operar: con permisos, auditoría y validación. Duplicar cálculos oficiales en la interfaz rompería la única verdad. La regla es clara: la experiencia consulta medidas y dimensiones del modelo, y la escritura ocurre en otra capa.
¿Cuáles son las cuatro capas de la arquitectura?
Antes de implementar conviene separar responsabilidades. Una acción escribible bien diseñada tiene cuatro piezas que no se mezclan:
- Lectura analítica. La experiencia consulta medidas y dimensiones del modelo semántico. Los cálculos oficiales no se duplican en la interfaz.
- Lógica de negocio. En User Data Functions vive el código Python que se ejecuta sin servidor propio: una regla escrita una vez queda publicada detrás de endpoints autenticados, disponibles tanto para elementos de Fabric como para aplicaciones de fuera.
- Almacenamiento operativo. SQL Database, Cosmos DB u otra base transaccional guarda estados, objetivos y aprobaciones con permisos y auditoría.
- Retorno analítico. Los datos escritos regresan a Power BI, Excel o agentes por Direct Lake, el SQL analytics endpoint, una actualización o una API.
Esta separación es la que permite que la escritura no contamine el gobierno de las métricas y que todos sigan analizando sobre las mismas cifras.
¿Qué ruta de implementación conviene según el caso?
No hay una sola manera de habilitar acciones. La ruta correcta depende de qué necesita el flujo y de qué límites estás dispuesto a documentar. Cada ruta obliga a dejar por escrito sus condiciones de uso, incluido el modelo de permisos sobre los datos que la sostiene.
| Ruta | Cuándo encaja | Límite que se documenta |
|---|---|---|
| Fabric App y Data API | Hace falta una interfaz hecha a medida, alojada como aplicación Fabric, capaz de leer y de actualizar datos sin salir del entorno | Estado de disponibilidad según la documentación oficial, región, autenticación, modelo de permisos y responsabilidad de la interfaz |
| User Data Functions | Varios canales (Pipelines, Notebooks, Activator, Power BI o una app vía REST) tienen que ejecutar exactamente la misma regla | Identidad, conexiones, idempotencia, errores, registros y librerías del entorno de Python |
| Flujo transaccional y analítico | Un informe de Power BI necesita ejecutar una acción acotada y escribir con una función sobre SQL Database o Cosmos DB | Se revisa el estado de disponibilidad en la documentación oficial y se validan región, tenant, latencia, auditoría y una alternativa para producción |
| Backend externo | El caso exige autenticación propia, transacciones complejas, garantías adicionales o integración fuera de Fabric | Contrato de API, secretos, observabilidad, autorización y sincronización con la capa analítica |
La idea de fondo es reutilizar la lógica: una regla compartida se actualiza una vez y se invoca desde varios canales, en lugar de reescribirla en cada informe o aplicación.
¿Cómo se implementa paso a paso el patrón de objetivos y Scorecards?
El caso más común es guardar objetivos por métrica, equipo, escenario, período y moneda. Es un buen patrón de referencia porque toca las cuatro capas. Estos son los pasos:
- Diseña la tabla de objetivos. Debe guardar 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. Define una clave lógica que combine período y escenario para evitar duplicados.
- Escribe la lógica de validación. Una User Data Function (o un backend seguro) valida la entrada y ejecuta la escritura; si dudas cuándo conviene añadir esta capa con User Data Functions, esa decisión va antes del código. Ahí verificas permisos, formatos y reglas antes de tocar la base.
- Persiste el estado en la base operativa. SQL Database en Fabric o Cosmos DB guarda el objetivo con permisos y auditoría. La clave lógica impide que dos cargas del mismo período y escenario se dupliquen.
- Devuelve los datos al análisis. Los objetivos escritos regresan a Power BI o Excel por Direct Lake o el SQL analytics endpoint, y quedan listos para compararse contra los valores reales del modelo semántico.
- Sincroniza el Scorecard si aplica. Si también actualizas un Scorecard, las llamadas a Power BI REST se ejecutan fuera del navegador y se prueban como una integración independiente, no dentro de la interfaz de usuario.
Lo mismo aplica a clasificaciones manuales que no nacen en la fuente, a notas ejecutivas con responsables y estados, y a reglas compartidas entre canales.
¿Qué errores de seguridad y diseño hay que evitar?
Una capa de escritura mal montada abre riesgos que no existían en un tablero de solo lectura. Cuídate de estos puntos:
- No expongas tokens de escritura en la interfaz. El navegador nunca debe portar credenciales que permitan modificar datos. La escritura pasa por una función o backend autenticado.
- Usa Direct Lake solo si corresponde. Direct Lake se aplica únicamente cuando el modelo y las fuentes fueron diseñados para ese modo. Forzarlo sobre un diseño que no lo contempla degrada el retorno analítico.
- Documenta el estado de disponibilidad de cada capacidad. Revisa en la documentación oficial de Microsoft en qué estado se encuentra cada pieza antes de comprometerla. De cara a producción se validan región, tenant, latencia y auditoría, y se define una alternativa.
- Garantiza idempotencia. Si la misma acción puede invocarse dos veces (por reintentos o desde varios canales), la lógica y la clave lógica deben evitar escrituras duplicadas.
Estas reglas son las que separan un experimento de una herramienta confiable que dirección puede usar para decidir.
¿Cómo se sostiene la capa una vez en producción?
Una capa escribible es software que evoluciona, así que necesita disciplina de operación. Git integration versiona los elementos compatibles y permite colaborar con historial. Los Deployment pipelines mueven los cambios entre desarrollo, pruebas y producción de forma repetible. Las Variable libraries ajustan parámetros entre entornos sin duplicar la lógica.
La definición de cambio resume el criterio: todo cambio importante debe poder probarse, aprobarse y revertirse. Si una acción de escritura no cumple esas tres condiciones, todavía no está lista para producción.
Cómo empezar con criterio
Diseñar esta capa exige criterio antes que herramienta: primero se ordenan las métricas y las decisiones, después se elige la ruta. Si quieres ver cómo se ve en la práctica una capa de acción gobernada sobre datos reales, con permisos, auditoría y retorno analítico, mira la demo gratuita. Ahí presentamos cómo abordamos este tipo de arquitecturas y qué camino conviene según el punto de partida de cada empresa. Con eso, decidir escribir sobre los datos deja de ser un riesgo y pasa a ser una decisión ordenada.
Preguntas relacionadas
¿Por qué no puedo escribir directamente en el modelo semántico de Power BI?
Porque el modelo semántico está diseñado para lectura analítica y gobierno de métricas, no para guardar estados que cambian por decisión de una persona. Objetivos, notas o aprobaciones se guardan en una capa transaccional aparte con permisos y auditoría.
¿Qué guarda una tabla de objetivos bien diseñada?
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. Una clave lógica que combine período y escenario evita duplicados.
¿Cuándo conviene un backend externo en lugar de User Data Functions?
Cuando el caso exige autenticación propia, transacciones complejas, garantías adicionales o integración fuera de Fabric. En ese caso se documenta el contrato de API, secretos, observabilidad, autorización y la sincronización con la capa analítica.
¿Es seguro exponer la escritura desde la interfaz del usuario?
No se deben exponer tokens de escritura en la interfaz. La escritura pasa siempre por una User Data Function o un backend autenticado, y las llamadas a Power BI REST se ejecutan fuera del navegador como integración independiente.
¿Qué necesita cumplir un cambio antes de pasar a producción?
Todo cambio importante debe poder probarse, aprobarse y revertirse. Se apoya en Git integration para versionar, Deployment pipelines para mover cambios entre entornos y Variable libraries para ajustar parámetros sin duplicar lógica.