Como implementar RLS dinâmico no Power BI com múltiplas condições (sem complicar seu modelo)

Se você trabalha com Power BI e já precisou restringir dados com base em mais de uma dimensão ao mesmo tempo, sabe o quanto isso pode ser um desafio.

O método clássico de RLS (Row-Level Security) com relacionamentos diretos funciona bem para uma restrição simples (como filtrar apenas por Marca). Mas ele não funciona quando precisamos aplicar múltiplas condições independentes em diferentes tabelas de dimensão.

O Desafio Real

Imagine este cenário:

Se aplicamos o RLS clássico, conseguimos filtrar por Marca ou Continente... mas não pelos dois ao mesmo tempo de forma independente.

Tentar resolver com múltiplos relacionamentos ativos gera ambiguidade no modelo ou resultados incorretos.

A Solução: RLS Dinâmico com Tabela de Permissões Desconectada

A estratégia é simples e poderosa: criamos uma tabela de permissões sem relacionamentos ativos com o modelo principal. Usamos expressões DAX dentro de uma única Role para aplicar filtros em cada dimensão.

Isso transforma a tabela de permissões em um catálogo central de regras, que pode ser consultado para qualquer dimensão.

Estrutura da Tabela de Permissões (RLS_Permissoes)

Sua tabela precisa ter pelo menos 3 colunas. Ela ficará estruturada da seguinte forma:

Detalhe importante: não crie relacionamentos ativos dessa tabela com outras no modelo.

Filtros DAX Aplicados Diretamente nas Dimensões

Exemplo para Marca:

[Marca] IN 
SELECTCOLUMNS(
    FILTER(
        'RLS_Permissoes',
        'RLS_Permissoes'[Email] = USERPRINCIPALNAME()
        && 'RLS_Permissoes'[Tipo_Restricao] = "Marca"
    ),
    "Marcas Permitidas", [Valor_Permitido]
)

Exemplo para Continente:

[Continente] IN 
SELECTCOLUMNS(
    FILTER(
        'RLS_Permissoes',
        'RLS_Permissoes'[Email] = USERPRINCIPALNAME()
        && 'RLS_Permissoes'[Tipo_Restricao] = "Continente"
    ),
    "Continentes Permitidos", [Valor_Permitido]
)

Exemplo genérico para qualquer outra dimensão:

[NomeDaColuna] IN 
SELECTCOLUMNS(
    FILTER(
        'RLS_Permissoes',
        'RLS_Permissoes'[Email] = USERPRINCIPALNAME()
        && 'RLS_Permissoes'[Tipo_Restricao] = "NomeDaDimensao"
    ),
    "Valores Permitidos", [Valor_Permitido]
)

Passo a Passo Resumido de Implementação

1. Crie a tabela RLS_Permissoes (Excel, SQL Server, SharePoint, Dataverse etc.).
2. Importe no Power BI → mantenha-a desconectada do modelo.
3. Crie uma única Role (RLS_Dinamico).
4. Aplique os filtros DAX diretamente em cada dimensão relevante.
5. Teste no Power BI Desktop usando View as Roles.
6. Publique no Power BI Service.
7. Atribua usuários à Role.
8. Valide no ambiente real com os usuários finais.

Exemplo Prático Aplicado

Imagine um relatório global de vendas.

• O diretor de produtos só pode ver dados da marca que gerencia.
• O gerente regional só pode ver dados do continente em que atua.
• O time financeiro precisa ver tudo.

Com esse modelo:

• Todos acessam o mesmo relatório.
• Cada um vê apenas o que precisa.
• O administrador tem uma Role "Todos os Dados" com a expressão TRUE().

Vantagens

• Flexibilidade: restrições em múltiplas dimensões de forma independente.
• Escalabilidade: adicionar novas regras é simples.
• Centralização: todas as permissões ficam organizadas em uma tabela única.
• Modelo mais limpo: elimina a necessidade de relacionamentos ambíguos.

Pontos de Atenção

• Complexidade de DAX: exige conhecimento intermediário ou avançado da linguagem.
• Performance: pode ter impacto em tabelas muito grandes (bilhões de linhas), mas em cenários normais é desprezível.
• Manutenção: a tabela de permissões deve estar sempre atualizada.

Boas Práticas

• Use sempre USERPRINCIPALNAME(), pois é mais confiável que USERNAME().
• Crie uma role "Todos os Dados" para os administradores do dashboard.
• Documente claramente as regras de permissão da empresa.
• Automatize a atualização da tabela de permissões se possível (ex: conectando ao AD/Entra ID).
• Faça testes rigorosos com diferentes perfis de usuários antes de publicar.

Insight Final

O RLS dinâmico com múltiplas condições é como um porteiro inteligente: cada usuário só vê o que está autorizado, sem a necessidade de criar relatórios separados ou modelos super complicados.

Esse tipo de implementação está cada vez mais valorizado em empresas que priorizam governança, segurança e escalabilidade em seus relatórios.