junio 23, 2025

Domina los flujos translíticos: edición de datos directa en Fabric desde Power BI

Tabla de Contenido

Y si ahora, en un panel de Power Bi, no tuviéramos que conformarnos solo con ver los datos sino que también pudiéramos, editarlos, actualizarlos y demás? 

En este artículo trataré de explicar cómo lograr algo que ya se hacia configurando procesos de automatización e integrando otras herramientas y que ahora parece ser más fácil gracias a los los flujos de tareas translíticos (versión preliminar) lanzados en la actualización de Power Bi del mes de Mayo de 2025. 

Interfaz de un informe de flujos translíticos en Power BI Fabric

¿Qué son los flujos translíticos en Power BI?

Los flujos de tareas translíticos son una nueva funcionalidad en Power BI + Fabric (actualmente en public preview), que permiten a los usuarios realizar acciones de escritura directamente desde los informes: agregar, editar o eliminar datos, o bien invocar APIs externas, todo sin salir de la interfaz. Encuentra Aquí mas información.

Estos flujos se basan en las Fabric User Data Functions, que conectan elementos visuales del reporte (botones, slicers) con acciones backend, por ejemplo, actualización de registros en una base SQL, disparo de notificaciones, o consultas a APIs.

¿Qué casos de uso resuelve esta funcionalidad?

Hay una gran cantidad de casos de uso donde podríamos utilizar esta nueva función, se me ocurre por ejemplo para hacer presupuestos financieros, verificar la disponibilidad de recursos, entre otros muchos, les presento un par más pero en este repositorio de GitHub encontrarán más ejemplos:  

Ejemplo 1: Descuentos bajo aprobación

Es uno de los ejemplos que nos propone Microsoft el artículo donde presentan los flujos; un usuario propone un descuento en un reporte; al hacer clic en “Request discount”, se envía a Teams para aprobación, y si se aprueba, el informe se actualiza con el nuevo valor

Interfaz de teams con aprobación de flujos translíticos de Power BI Fabric

 

Ejemplo 2:  Gestión de disponibilidad de técnicos o personal operativo (clínicas, talleres, etc.)

Desde un informe en Power BI que muestra los turnos o disponibilidad de personal (médicos, técnicos, operarios…), un coordinador puede modificar en tiempo real el estado de un recurso: Marcarlo como «Disponible», «De baja», o «En visita externa». El cambio actualiza la tabla SQL correspondiente.

Inmediatamente, los demás visuales (calendario, planificación, tiempos de espera) se refrescan.

Valor agregado: Sin abrir un sistema externo ni cambiar de interfaz, se puede actualizar la disponibilidad directamente desde el reporte, ayudando a los equipos operativos a actuar con mayor agilidad.

¿Cómo funciona una User Data Function en Fabric?

Lo que hace posible todo este flujo es la integración nativa entre Power BI y Microsoft Fabric mediante funciones de datos de usuario (User Data Functions o UDFs). Estas funciones se escriben en Python y se alojan en Fabric, donde pueden conectarse a bases de datos SQL, Lakehouse o incluso invocar APIs externas. Cuando el usuario en Power BI interactúa con un botón o control (por ejemplo, para guardar un nuevo dato o modificar un registro), Power BI no realiza directamente la acción en la base de datos, sino que invoca esa UDF alojada en Fabric pasando los parámetros definidos por el usuario.

La función, entonces, se conecta de forma segura al origen de datos y ejecuta la lógica definida: actualizar, insertar, eliminar, llamar a una API, etc. El resultado se devuelve a Power BI, que refresca el informe para reflejar los cambios en tiempo real. Así, se establece un puente directo entre la capa visual de Power BI y la capa transaccional de los datos, sin necesidad de aplicaciones intermedias, sin Power Apps, ni infraestructura adicional.

¿Cómo crear una función que modifique registros desde Power BI?

Este es un Ejemplo que he construido de una función de usuario:

				
					import fabric.functions as fn

udf = fn.UserDataFunctions()

@udf.connection(argName="sqlDB", alias="DeudaRlombanaBl") 
@udf.function()
def actualizar_estado_deuda(sqlDB: fn.FabricSqlConnection, idcliente: int, nuevoestado: str) -> str:

    # Validar que el estado es uno de los tres permitidos
    estados_validos = ["Vencida", "Saldada", "Sin Vencer"]
    if nuevoestado not in estados_validos:
        raise fn.UserThrownError("Estado inválido. Usa: Vencida, Saldada o Sin Vencer.", {"Estado ingresado": nuevoestado})

    connection = sqlDB.connect()
    cursor = connection.cursor()

    # Actualizar el campo estado
    update_query = """
    UPDATE deuda_clientes
    SET estado = ?
    WHERE id_cliente = ?
    """
    cursor.execute(update_query, (nuevoestado, idcliente))

    connection.commit()
    cursor.close()
    connection.close()

    return f"Estado de cliente {idcliente} actualizado a '{nuevoestado}'"

Componentes Principales

  1. Importación y Objeto UDF Primero, se importa la librería necesaria de Fabric con import fabric.functions as fn. Luego, se crea una instancia udf = fn.UserDataFunctions(), que es el objeto que gestionará nuestras funciones personalizadas.
  2. Decoradores (@) Los decoradores son instrucciones que «envuelven» la función para añadirle funcionalidades.
    • @udf.connection(argName=»sqlDB», alias=»DeudaRlombanaBl»): Este es el componente de seguridad más importante. Le dice a Fabric que el argumento sqlDB de la función debe usar la conexión a base de datos guardada en Fabric con el alias «DeudaRlombanaBl». De esta manera, las credenciales (usuario, contraseña) nunca se escriben en el código.
    • @udf.function(): Este decorador registra formalmente la función actualizar_estado_deuda como una Función Definida por el Usuario (UDF) en Fabric, permitiendo que sea llamada desde otras herramientas como los notebooks.
  3. Definición de la Función La línea def actualizar_estado_deuda(sqlDB: fn.FabricSqlConnection, idcliente: int, nuevoestado: str) -> str: define la función y sus parámetros:
    • sqlDB: Recibirá el objeto de conexión seguro proporcionado por el decorador @udf.connection.
    • idcliente: Un número entero que identifica al cliente.
    • nuevoestado: Una cadena de texto con el nuevo estado («Vencida», «Saldada», etc.).
  4. Lógica Interna de la Función
    • Validación de entrada: El código primero comprueba si el nuevoestado es uno de los valores permitidos («Vencida», «Saldada», «Sin Vencer»). Si no lo es, lanza un error claro usando fn.UserThrownError.
    • Conexión y Ejecución: Se establece la conexión a la base de datos (sqlDB.connect()), se crea un cursor para ejecutar comandos y se lanza la consulta SQL UPDATE para cambiar el estado en la tabla deuda_clientes para el id_cliente correspondiente. El uso de ? en la consulta previene ataques de inyección SQL.
    • Confirmación y Cierre: Con connection.commit(), se guardan los cambios permanentemente en la base de datos. Finalmente, se cierran el cursor y la conexión para liberar recursos.
    • Mensaje de retorno: La función devuelve un mensaje de texto confirmando que la actualización se ha realizado con éxito.

 

¿Qué riesgos existen al permitir escritura desde el informe?

Aunque los flujos de tareas translíticos abren una puerta poderosa hacia la interacción directa con los datos, también introducen un nuevo nivel de riesgo: ahora no solo se consultan datos desde el informe, sino que también se modifican en tiempo real desde la misma interfaz. Esto implica que, sin una adecuada gobernanza, validaciones y control de permisos, se corre el riesgo de introducir errores en la fuente de datos, afectar procesos críticos o comprometer la integridad de los sistemas conectados. Por tanto, aunque las ventajas en agilidad, automatización y usabilidad son claras, el valor real de esta funcionalidad solo se alcanza si se implementa con un enfoque responsable, gobernado y auditable.

Rodrigo Lombana Reina. Autor

Rodrigo Lombana Reina

Read more posts by this author

Logo TheFabricOfData con colores