Cuando un mismo informe de ventas lo tienen que ver tanto el director general como cada delegado regional, pero cada uno solo debería ver «sus» datos, la respuesta en Power BI se llama Row-Level Security (RLS). No es una función de un solo clic: hay que entender bien cómo se definen los roles y qué cambia según el modo de conexión del modelo.
Qué es Row-Level Security
RLS es un mecanismo que restringe qué filas de una tabla puede ver cada usuario, en función de reglas DAX definidas en roles de seguridad. Es importante tener claro qué no hace: RLS no oculta tablas, columnas ni medidas completas, solo filtra filas. Si quieres ocultar una columna entera para ciertos usuarios, esa es otra funcionalidad (seguridad a nivel de objeto), no RLS.
Roles estáticos vs. roles dinámicos
Un rol estático tiene una regla DAX fija, sin depender de quién ha iniciado sesión. Por ejemplo, un rol «SoloNorte» con el filtro 'Región'[Nombre] = "Norte": cualquier usuario que se asigne a ese rol ve exactamente esas filas, sean quienes sean.
Un rol dinámico, en cambio, usa una función que identifica al usuario conectado para decidir el filtro en tiempo de consulta, normalmente USERPRINCIPALNAME() (devuelve el nombre principal de usuario, típicamente su correo, en Power BI Service) o USERNAME() (en Power BI Desktop suele devolver el formato DOMINIO\usuario). Con una tabla puente que relacione usuarios con regiones, un único rol dinámico sirve para todo el equipo comercial sin tener que crear un rol por cada delegado.
| Rol | Tipo | Filtro DAX de ejemplo |
|---|---|---|
| SoloNorte | Estático | 'Región'[Nombre] = "Norte" |
| SoloDirección | Estático | TRUE() (ve todas las filas) |
| PorUsuario | Dinámico | 'MapaUsuarios'[Email] = USERPRINCIPALNAME() |
Cuidado con los roles múltiples: si un mismo usuario pertenece a más de un rol de seguridad, Power BI no aplica el más restrictivo, sino la unión de lo que cada rol le permite ver. Diseña los roles pensando en esto, porque es una fuente habitual de sustos en producción.
Power BI Desktop vs. Power BI Service
Los roles y sus reglas DAX se definen y editan en Power BI Desktop, desde la opción «Administrar roles» del menú de modelado. En el servicio Power BI, no puedes crear ni modificar la lógica de un rol: solo asignas usuarios, grupos de seguridad de Microsoft Entra, o grupos de distribución a los roles que ya vienen definidos desde el modelo publicado. Para probar cómo verá los datos un rol concreto, Desktop ofrece «Ver como rol» (View as role) y el servicio su equivalente «Probar como rol» (Test as role).
Modelos importados vs. DirectQuery
En modelos de importación, el filtro RLS se aplica sobre los datos ya cargados en memoria por el propio motor de Power BI: es rápido y totalmente controlado desde el modelo. En modelos DirectQuery, la regla DAX del rol se traduce y se envía como parte de la consulta que se lanza contra el origen en cada interacción, así que su rendimiento depende también de cómo esté indexado el origen; además, ciertas funciones de contexto avanzado de DAX pueden no estar soportadas en reglas RLS sobre DirectQuery, por lo que conviene mantener esas reglas lo más simples posible.
- Aplica siempre el filtro RLS sobre la tabla de dimensión (por ejemplo, Región) y deja que se propague a la tabla de hechos a través de la relación, en vez de filtrar directamente los hechos.
- Asegúrate de que las relaciones implicadas están activas: RLS solo se propaga a través de relaciones activas del modelo.
- En roles dinámicos con condiciones IF, define siempre un «else» que deniegue el acceso (FALSE) en vez de concederlo por defecto, para que un valor inesperado no exponga todas las filas.
- Añade una medida de depuración tipo
QuienSoy = USERPRINCIPALNAME()en una tarjeta visual mientras pruebas roles dinámicos: ayuda mucho a confirmar qué identidad está viendo realmente el modelo. - Prueba cada rol con «Ver como rol» antes de publicar, y repite la prueba con «Probar como rol» ya en el servicio, porque el formato de usuario puede variar entre entornos.
Antes de ponerte a securizar filas con RLS, merece la pena asegurarte de que las consultas de origen que alimentan el modelo ya están bien optimizadas.
Leer el artículo sobre pasos aplicados y query folding en Power Query