La solicitud
De Jessica Turner, Jefa de operaciones de ventas
“Ahora tenemos tres gerentes de territorio y la lista de estados cambia cada trimestre. No quiero un rol por persona. Operaciones de ventas mantiene una tabla Territories con cada estado y el correo del gerente que lo tiene a su cargo. ¿Puede una sola regla leer esa tabla y mostrar a cada gerente solo sus estados?”
Tu objetivo
El modelo tiene una tabla Territories (state, manager_email; una fila por estado). Escribe una regla en la tabla customers que conserve a un cliente cuando el manager_email de su estado en Territories sea igual al correo del usuario conectado. El visual muestra lo que ve cada persona, incluida alguien que no está en Territories.
- Cada usuario ve solo sus filas: revisa cada línea del visualpendiente
Tu regla de rol
- Visual
- A card of [Sales], [Customers] for each user
- Medidas del informe
Sales = CALCULATE(SUM(order_items[line_total]), orders[status] = "completed")Customers = COUNTROWS(customers)
Panel de datos: tablas y columnas
- order_items order_item_id, order_id, product_id, quantity, unit_price, discount_pct, line_total
- orders order_id, customer_id, order_date, status, channel, shipping_fee, coupon_code
- products product_id, name, category, subcategory, unit_price, unit_cost, launched_on, is_active
- customers customer_id, first_name, last_name, email, city, state, signup_date, segment, referral_source
- returns return_id, order_item_id, returned_on, reason, refund_amount
- Date Date, Year, Quarter, Month Number, Month, Year Month, Year Quarter, Day, Weekday Number, Weekday
- Territories state, manager_email
Cargando el editor…
Solución de referencia
| User | Sales | Customers |
|---|---|---|
| Ava Reed | 5,894,284.44 | 2,018 |
| Luis Ortega | 5,894,284.44 | 2,018 |
| Grace Kim | 5,894,284.44 | 2,018 |
| Hannah Moore (not in Territories) | 5,894,284.44 | 2,018 |
Mote revisa tu resultado
Presiona Comprobar. Mote completa tu respuesta y la compara con lo que necesita el informe.
Lo que recibe Jessica, y por qué
La lección
Un rol estático contiene una lista fija. Con diez regiones mantienes diez roles, y cada reorganización es un cambio en el modelo. La RLS dinámica usa un único rol cuya regla pregunta ¿quién ha iniciado sesión? y busca la respuesta en una tabla que mantiene el negocio.
Dónde estás trabajando
Esta página es una herramienta de práctica, no Power BI. Escribes una regla en customers; el motor la
ejecuta una vez por cada persona de la lista, con USERPRINCIPALNAME() devolviendo el correo de esa
persona, y el visual muestra lo que ve cada una. Sigue las reglas de Power BI, así que la misma regla
funciona en Desktop.
En Power BI Desktop: carga la tabla Territories (Excel, una lista de SharePoint o una tabla de base de
datos) con Inicio → Obtener datos (Home → Get data), luego Modelado → Administrar roles → Nuevo
(Modeling → Manage roles → New), ponle nombre al rol, selecciona customers, Cambiar al editor DAX
(Switch to DAX editor), escribe la regla y Guardar (Save). Pruébala con Modelado → Ver como
(Modeling → View as): marca Otro usuario (Other user), escribe el correo de un gerente, marca también
el rol y pulsa Aceptar.
Quién ha iniciado sesión
USERPRINCIPALNAME() devuelve el nombre principal de usuario de la persona que ve el informe, que en la
mayoría de las empresas es su correo de trabajo, como ava.reed@harborandpine.com. En Desktop, antes de
publicar, devuelve tu propio inicio de sesión, por lo que pruebas con Ver como → Otro usuario.
También existe USERNAME(), pero en Desktop devuelve DOMINIO\usuario; USERPRINCIPALNAME() da la
misma respuesta en Desktop y en el servicio, así que prefiérela.
Buscar al propietario
LOOKUPVALUE(Territories[manager_email], Territories[state], customers[state]) = USERPRINCIPALNAME()Léela de dentro hacia fuera: para el estado de este cliente, busca la fila de Territories con el mismo
estado y devuelve su manager_email; luego compáralo con el correo conectado. Necesita una fila por
estado en Territories; de lo contrario LOOKUPVALUE no puede elegir un único correo y falla. Los
estados que nadie tiene a su cargo devuelven un vacío, que nunca es igual a un correo, así que esos
clientes quedan ocultos para todos.
La versión con relación
Muchos modelos relacionan la tabla de seguridad: Territories[state] → customers[state], con la regla en
Territories, Territories[manager_email] = USERPRINCIPALNAME(). El filtro de Territories fluye a
customers y de ahí a orders. Cuando un gerente puede compartir un estado con otra persona, la tabla de
asignación tiene varias filas por estado y la regla necesita una prueba que acepte una lista:
customers[state] IN CALCULATETABLE(VALUES(Territories[state]), Territories[manager_email] = USERPRINCIPALNAME())Errores comunes
- Correos escritos en la regla. Eso es un rol estático disfrazado.
- Mayúsculas y espacios. DAX compara texto ignorando las mayúsculas, pero un espacio al final en la tabla rompe la coincidencia. Recórtalo en Power Query.
- Dejar legible la tabla de asignación. Ocúltala en la vista de informe, o cada lector podrá ver quién tiene qué.
- Nadie en el rol. Una regla dinámica sigue necesitando que se añadan personas (o un grupo) al rol en el servicio.
¡Linterna encendida!
Practicaste: row level securitydynamic rlsuserprincipalnamelookupvaluesecurity table
- Resuelto
- Sin pistas
- Al primer intento