RLS no Power BI: valide o acesso por equipe de vendas

A RLS no Power BI, sigla de segurança em nível de linha, restringe os registros que uma pessoa pode consultar no modelo semântico. Modelo semântico é a estrutura de dados, relações e medidas usada pelo relatório. Uma implementação correta depende de regras de negócio, relacionamentos e permissões.

Este roteiro apresenta um cenário de vendedores que devem consultar somente clientes de suas equipes. Ele exige testes com identidades reais autorizadas e uma definição formal de quem pode ver cada registro. Esconder páginas ou usar um filtro visual não atende à mesma finalidade.

1. Defina a política antes de criar RLS no Power BI

Descreva quem acessa quais clientes, equipes e períodos. Um gerente pode precisar de várias equipes; um vendedor, somente uma. Defina como tratar transferências, substituições e clientes compartilhados. A regra deve esclarecer se o acesso acompanha a equipe atual ou a responsabilidade na data da venda.

Prepare uma pequena tabela de resultados esperados: usuário, clientes permitidos e clientes proibidos. Inclua uma pessoa sem equipe e um cliente sem atribuição. Esses casos revelam se a ausência de cadastro abre acesso ou produz uma restrição coerente com a política.

2. Prepare a tabela de autorização

Registre identidade de acesso, equipe autorizada, situação e vigência quando necessária. Use a identificação reconhecida pelo ambiente de autenticação, confirmada pela administração. Nomes de exibição não são chaves confiáveis porque podem se repetir ou mudar. Mantenha uma origem oficial para concessões e revogações.

Valide duplicidades e acessos desativados. Uma pessoa com duas equipes pode ter duas linhas legítimas, mas isso precisa estar previsto na política. Não deduza autorização a partir de participação em reuniões ou de uma lista comercial informal; confirme o vínculo com o responsável pelos dados.

3. Planeje o caminho dos filtros

Mapeie como a autorização alcançará clientes e vendas no modelo. A regra deve filtrar as dimensões corretas e propagar a restrição até os eventos. Teste o desenho numa cópia pequena antes de aplicar à base completa. Evite ativar filtros em ambas as direções sem compreender o caminho criado.

A orientação de RLS da Microsoft, consultada em 6 de outubro de 2026, discute desenho e testes das regras. O comportamento depende do modelo; uma expressão aparentemente correta não garante que todas as tabelas com dados comerciais recebam a restrição esperada.

4. Escolha regras estáticas ou dinâmicas

Uma regra estática pode restringir uma dimensão a uma equipe específica. Ela simplifica um piloto pequeno, mas exige manutenção quando existem muitas equipes. Uma regra dinâmica usa a identidade de quem consulta e uma tabela de autorização para determinar o conjunto permitido.

No cenário dinâmico, uma expressão como [UPN] = USERPRINCIPALNAME() pode filtrar a tabela de autorização. UPN é o nome principal do usuário. A expressão sozinha não protege vendas: os relacionamentos e a propagação do filtro precisam completar o caminho até os registros comerciais.

5. Crie a função e teste no Desktop

No Power BI Desktop, crie a função em Gerenciar Funções, aplique a regra à tabela apropriada e valide a expressão. Use Exibir Como para testar a função. Em regras dinâmicas, informe uma identidade compatível com os casos previstos na tabela de resultados esperados.

A documentação oficial de RLS, consultada em 6 de outubro de 2026, descreve a criação das regras, a publicação e a atribuição de membros no serviço. Teste o processo no ambiente da organização, pois conexões e configurações podem exigir tratamento específico.

6. Confira totais e detalhes para cada identidade

Num exemplo hipotético, a equipe Norte tem vendas de R$ 10.000 e a Sul, de R$ 15.000. O vendedor autorizado somente ao Norte deve observar R$ 10.000, sem detalhes do Sul. Um cartão correto não basta: teste tabelas, páginas auxiliares, segmentações e pesquisas de clientes.

Confira também o acesso a páginas de detalhamento por cliente com drillthrough. Uma página dedicada a investigar vendas deve receber o mesmo limite de autorização. Registre capturas ou resultados de teste com os dados mínimos necessários, evitando divulgar informações pessoais no registro da validação.

7. Revise as permissões do workspace

Workspace é o espaço de trabalho no serviço do Power BI. A documentação oficial informa que a RLS restringe usuários com papel Viewer, mas não se aplica aos papéis Admin, Member e Contributor. Portanto, uma regra bem construída pode não restringir uma pessoa que recebeu permissões de edição.

Confira papéis, acesso ao conteúdo e atribuição às funções no serviço antes da liberação. Não use uma conta administradora para demonstrar a experiência restrita de um vendedor. Teste uma identidade com as mesmas permissões que o público final e documente eventuais acessos elevados.

8. Investigue a combinação de várias funções

Quando uma pessoa pertence a múltiplas funções de RLS, os conjuntos permitidos podem se combinar. A orientação oficial destaca o comportamento aditivo. Não pressuponha que uma função restritiva anula automaticamente uma função mais ampla. Revise grupos e atribuições para detectar acessos acumulados.

Inclua um caso de teste com duas funções e confira clientes permitidos por cada uma. Se a política exigir um acesso específico, simplifique a atribuição ou redesenhe as regras. Mantenha a política como referência; não ajuste a interpretação do negócio para aceitar um resultado inesperado do modelo.

9. Teste ausência de autorização e alterações de equipe

Uma identidade não cadastrada deve produzir o comportamento restritivo definido na política, sem acesso amplo por padrão. Confira também cliente sem equipe, autorização vencida e mudança de responsável. Se a tabela de acesso é importada, considere o momento da atualização ao planejar a revogação.

Após publicar, use os recursos de teste de função no serviço e faça uma validação autorizada com o perfil final. Repita os casos após mudanças de relacionamento ou fonte. Segurança precisa de revisão contínua porque uma tabela nova pode introduzir dados fora do caminho de filtro original.

10. Libere com uma matriz de evidências

Monte uma matriz com cenário, identidade, resultado esperado, resultado observado e responsável pela aprovação. Priorize testes negativos, nos quais um registro proibido não pode aparecer. Verifique se a restrição compromete alguma leitura de indicadores comerciais que precisa de uma explicação ao usuário.

O modelo editável de Vendas pode ser adaptado ao desenho de acesso definido. Confirme a estrutura e implemente as regras necessárias; não presuma proteção pronta. Libere o relatório somente depois de validar funções, permissões e registros proibidos em todos os cenários relevantes.

Defina o procedimento de revogação antes de colocar o painel em uso. Registre quem remove a autorização, quem atualiza a origem de acesso e quem confirma o resultado no serviço. Uma alteração apenas na planilha não prova que a pessoa deixou de consultar os registros já disponíveis.

Inclua no teste uma tabela de resumo, caso exista no modelo. Ela deve respeitar a política mesmo quando não mostra nomes. Um total global pode revelar informações de outra equipe por diferença; valide a exposição permitida com o responsável pelos dados, em vez de presumir que agregação elimina o risco.