Cuando el usuario tiene que actuar y no solo mirar un informe, la escritura no debería vivir en el modelo semántico. Vive en una capa preparada para operar, y User Data Functions es una de las rutas para exponer esa lógica de forma gobernada. La decisión no es técnica primero, es de criterio: qué se escribe, quién puede hacerlo y cómo queda registrado.
El modelo semántico y Power BI son excelentes para leer, explicar y gobernar métricas. El problema aparece cuando el proceso pide objetivos manuales, clasificaciones, aprobaciones, notas de seguimiento o previsiones que nadie va a encontrar en la fuente operativa. Ahí no alcanza con leer. Hace falta una capa escribible, y conviene entender antes qué patrón encaja y qué límites se documentan.
Qué hace User Data Functions y por qué no es una tabla más
User Data Functions aloja lógica de negocio en Python sin servidor, reutilizable, y la expone a Fabric o a aplicaciones externas mediante endpoints autenticados. La idea central es que la misma regla se pueda invocar desde varios canales: un Pipeline, un Notebook, Activator, un informe de Power BI o una aplicación por REST. Una regla que se escribe una vez y se llama desde muchos lados evita copiar validaciones en cada interfaz.
Eso importa porque la alternativa habitual es codificar la regla de negocio dentro de la interfaz, por ejemplo en el frontend. Cuando la validación de un objetivo vive en React, cada nuevo canal la vuelve a implementar y las versiones se desvían. Concentrar la lógica en una función del lado del servidor mantiene una única definición. La documentación de User Data Functions en Microsoft Learn describe este modelo de lógica gobernada del lado del servidor y los endpoints autenticados que lo exponen.
La función valida y escribe, pero no guarda el estado
Un punto que se confunde seguido: la función no es el almacén. La persistencia operativa vive en una base transaccional, por ejemplo SQL Database o Cosmos DB, que guarda estados, objetivos y aprobaciones con permisos y auditoría. La función valida la acción, aplica la regla y escribe sobre esa base. Los datos escritos regresan después a Power BI, Excel o a un agente mediante Direct Lake, el SQL analytics endpoint, una actualización o una API.
La separación es deliberada. El modelo semántico no se toca con escrituras: la escritura vive en una capa transaccional con permisos definidos en el modelo de datos. Si intentas escribir sobre el modelo analítico para ahorrar una capa, terminas mezclando la superficie de solo lectura con operaciones que necesitan control transaccional, y pierdes la garantía de que los valores oficiales salen del modelo y no de cálculos improvisados. La documentación de SQL database in Fabric cubre esa persistencia operativa y el acceso analítico de retorno.
Objetivos y Scorecards: el patrón que muestra los cinco controles
El caso de objetivos por métrica es útil porque obliga a resolver de una vez validación, permisos, idempotencia y auditoría. Una tabla de objetivos bien diseñada 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.
- Validación: la función revisa que el objetivo tenga métrica válida, escenario conocido y período coherente antes de escribir. El período se deriva del calendario de gestión, el usuario no tipea nombres ni fechas sueltas.
- Idempotencia: una clave lógica sobre período y escenario evita duplicados. Si la misma acción se reintenta por un error de red, no aparecen dos objetivos para el mismo trimestre.
- Permisos: la escritura se autoriza en la capa transaccional, no en el navegador. Sin tokens de escritura expuestos en la interfaz.
- Auditoría: cada escritura registra responsable y momento, para poder reconstruir quién definió qué.
Una User Data Function o un backend seguro valida y escribe esa acción. Si además hay que sincronizar un Scorecard, las llamadas a Power BI REST se ejecutan fuera del navegador, en una función o un backend, y se prueban como una integración independiente. Este mismo criterio de escritura gobernada aparece cuando la experiencia completa vive en una aplicación Fabric, tema que desarrollamos en Fabric Apps para datos operativos.
Cuándo encaja cada ruta
User Data Functions no es la única salida. La decisión depende de dónde nace la acción y de qué garantías necesita.
| Ruta | Cuándo encaja | Límite que se documenta |
|---|---|---|
| User Data Functions | La misma regla debe invocarse desde Pipelines, Notebooks, Activator, Power BI o una aplicación por REST | 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 sobre SQL Database o Cosmos DB | Región, tenant, latencia, auditoría y una alternativa para producción |
| Backend externo | Hace falta gestionar su propia autenticación, resolver transacciones exigentes o conectar con sistemas que operan por fuera de Fabric | Contrato API, secretos, observabilidad, autorización y sincronización con la capa analítica |
Si la acción debe autenticar con reglas propias o resolver transacciones complejas, un backend externo con su contrato API es la opción honesta, aunque implique operar fuera de Fabric. La escritura gobernada convive además con las reglas de acceso a los datos, un tema que tratamos en RLS y seguridad de datos en Power BI y Fabric.
Los límites que conviene escribir antes de empezar
Hay condiciones que no deberían quedar implícitas. La capacidad de flujos transaccionales y analíticos continúa en versión preliminar, así que antes de apoyarse en ella se validan la región, el tenant, la latencia, la auditoría y una alternativa para producción. Direct Lake solo se usa si el modelo y las fuentes fueron diseñados para ese modo, no como atajo. Y ninguna interfaz guarda tokens de escritura ni decide permisos por su cuenta.
El error que se quiere evitar es convertir la analítica en una base transaccional improvisada. Escribir estados operativos sin idempotencia, sin auditoría y sin una clave lógica clara produce duplicados, valores que nadie puede explicar y decisiones tomadas sobre datos que se pisaron entre sí. La capa de escritura no reemplaza al modelo semántico como única verdad de las métricas, lo complementa para las acciones que el modelo no puede representar.
Antes de habilitar la primera escritura
Antes de exponer un endpoint de escritura, escribe en una página la tabla objetivo con su clave lógica, la validación que hará la función y el registro de auditoría que dejará cada operación. Ese documento corto decide si una User Data Function alcanza o si el caso necesita un backend externo, y evita descubrir en producción que faltaba la idempotencia. Si quieres ver cómo se diseña una capa de escritura gobernada sobre tus propias fuentes y permisos, mira la demo gratuita.
Preguntas relacionadas
¿User Data Functions guarda los datos que valida?
No. La función aloja lógica en Python y valida la acción, pero el estado vive en una base transaccional como SQL Database o Cosmos DB con permisos y auditoría. La función escribe sobre esa base, no reemplaza el almacenamiento.
¿Se puede escribir directamente sobre el modelo semántico de Power BI?
No conviene. El modelo semántico gobierna la lectura de métricas. La escritura se dirige a una capa transaccional con permisos propios, y los datos regresan al modelo mediante Direct Lake, el SQL analytics endpoint o una actualización.
¿Por qué importa la idempotencia al escribir objetivos o aprobaciones?
Porque un reintento por error de red no debe crear registros duplicados. Una clave lógica sobre período y escenario garantiza que la misma acción escrita dos veces produzca un solo objetivo, no dos que se contradicen.
¿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 esos escenarios se define un contrato API con secretos, observabilidad y sincronización con la capa analítica.
¿Por qué no exponer los tokens de escritura en el navegador?
Porque la interfaz no debe decidir permisos ni guardar credenciales sensibles. Las escrituras hacia sistemas como Power BI REST se ejecutan en una función del lado del servidor o un backend seguro y se prueban como una integración independiente.