Un solo modelo de Power BI para varios clientes, sin filtrarlos entre sí

Cuando un producto de datos empieza a venderse a más de un cliente aparece la misma pregunta: ¿un informe por cliente, o uno solo que sepa quién lo está mirando? La primera opción funciona con tres clientes y se vuelve insostenible con quince.

Por qué duplicar no escala

El coste de duplicar no está en crear la copia, está en mantenerla. Una corrección en una medida hay que aplicarla quince veces, y basta con que una se olvide para que un cliente vea un número distinto al del resto. El día que eso se descubre, se descubre delante del cliente.

Seguridad a nivel de fila, bien planteada

La herramienta correcta es la seguridad a nivel de fila (RLS), pero casi siempre se implementa mal: se escribe un filtro que compara el correo del usuario contra una columna de la tabla de hechos. Funciona en la demostración y se degrada en producción, porque obliga al motor a evaluar el filtro sobre millones de filas.

El planteamiento que aguanta es distinto:

• Una tabla de usuarios que relaciona identidad con organización.
• Una tabla de organizaciones que actúa como dimensión.
• El filtro se aplica sobre la dimensión, no sobre los hechos, y se propaga por la relación.

La diferencia en rendimiento no es sutil: filtrar una dimensión de cientos de filas y dejar que el motor propague es incomparablemente más barato que evaluar cada fila de hechos.

La trampa de las medidas que ignoran el contexto

El fallo más peligroso no es de rendimiento, es de aislamiento. Una medida que usa ALL() para calcular un total o un porcentaje elimina el filtro de seguridad junto con los demás filtros. El resultado es un porcentaje calculado sobre los datos de todos los clientes, mostrado a uno solo.

La fuga no se ve: el cliente no ve las filas ajenas, ve un denominador que las incluye. Es la clase de error que sobrevive años sin que nadie lo detecte.

La forma correcta de quitar filtros sin tocar la seguridad es ALLSELECTED() o, mejor, REMOVEFILTERS() aplicado solo a las columnas que hace falta liberar. Nunca al modelo entero.

Cómo se prueba que el aislamiento funciona

Probar RLS «a ojo» no vale. Lo que hacemos nosotros:

• Un juego de datos de prueba con dos organizaciones cuyos totales sean deliberadamente distintos y fáciles de reconocer.
• Recorrer todas las medidas del modelo suplantando a un usuario de cada organización, no solo las visibles en el informe.
• Comparar cada resultado contra el valor esperado de esa organización. Cualquier medida que devuelva el total conjunto tiene una fuga.

Es tedioso, y es lo que separa un producto que se puede vender a varias empresas de uno que solo se puede enseñar.

Cuándo NO usar multi-tenant

Si los clientes necesitan métricas distintas — no los mismos números sobre datos distintos, sino cálculos diferentes — forzar un modelo único produce un monstruo lleno de condicionales. Ahí sí conviene separar. La pregunta que lo decide no es cuántos clientes hay, sino cuánto se parecen sus preguntas.