Power BI Embedded: como entregar seus relatórios num portal com a sua marca

Muitas empresas já têm bons relatórios de Power BI, mas a entrega ainda é improvisada: links soltos por e-mail, gente sem licença pedindo print, cliente externo que não consegue acessar e workspaces que ninguém sabe quem pode abrir. O relatório é bom. O caminho até quem precisa dele é que falha.

O Power BI Embedded resolve essa parte. Com ele, os relatórios aparecem dentro de um portal ou sistema seu, com a sua marca, o seu login e as suas regras de acesso, sem que cada usuário precise entrar no Power BI. Neste artigo, explicamos como ele funciona, quando vale a pena, como o licenciamento muda a conta e como montar um portal de relatórios do jeito certo.

O que é o Power BI Embedded?

Power BI Embedded é a forma de exibir relatórios e painéis do Power BI dentro de outra aplicação: um portal web, um sistema interno, uma área do cliente ou um aplicativo. O relatório continua sendo criado no Power BI Desktop e publicado no serviço da Microsoft. O que muda é onde ele aparece e quem controla o acesso.

Na prática, a sua aplicação pede ao Power BI um token de incorporação (embed token), uma chave temporária que autoriza a exibição de um relatório específico para aquele usuário. O relatório é carregado na página pela biblioteca JavaScript do Power BI, com filtros, navegação entre páginas e interação, como no serviço original.

Os dois cenários de incorporação

• Incorporar para a sua organização: cada pessoa entra com a própria conta Microsoft e precisa ter acesso ao conteúdo no Power BI. Serve para portais internos de colaboradores.
• Incorporar para seus clientes: a aplicação se autentica no Power BI com uma identidade de serviço, e quem acessa o portal entra com o login do próprio portal. Serve para clientes, parceiros, franqueados e equipes internas sem conta no Power BI.

O segundo cenário é o mais usado em portais de relatórios com a marca da empresa, porque separa o usuário final do licenciamento por pessoa e deixa todo o controle de acesso na sua aplicação.

Quando vale a pena criar um portal de relatórios?

Nem toda empresa precisa de um portal. Se os relatórios são usados por poucas pessoas, todas com licença e acostumadas ao Power BI, o próprio serviço resolve. O portal começa a fazer sentido quando a distribuição vira o problema.

• Você precisa mostrar relatórios para clientes, fornecedores, franqueados ou parceiros que não fazem parte do seu ambiente Microsoft.
• Muitas pessoas só consultam os números, e pagar uma licença por usuário para todas elas pesa no orçamento.
• Cada público precisa ver um recorte diferente dos mesmos dados: região, carteira, unidade ou cliente.
• Os relatórios estão espalhados em vários workspaces e ninguém encontra o que precisa.
• A empresa quer que a experiência tenha a própria marca, e não a cara de uma ferramenta de terceiros.
• Além de painéis em Power BI, existem relatórios em HTML, planilhas ou links externos que deveriam estar no mesmo lugar.

Em finanças, por exemplo, um portal reúne DRE, fluxo de caixa e despesas por centro de custo, com cada gestor vendo só a própria área. Em vendas, o diretor vê a empresa inteira, o gerente vê a regional e o vendedor vê a própria carteira. Em contact center, o cliente da operação acessa os indicadores do contrato dele sem entrar no ambiente da empresa.

Como funciona o licenciamento do Power BI Embedded?

Esta é a parte que mais gera dúvida, e as regras da Microsoft mudam com alguma frequência. Por isso, vale confirmar na documentação oficial antes de fechar a arquitetura. O princípio geral é estável: quando o relatório é incorporado para clientes, a empresa paga por capacidade, e não por usuário.

• Capacidade: uma reserva de processamento no Azure ou no Microsoft Fabric onde os relatórios rodam. Os SKUs A, do Power BI Embedded no Azure, podem ser pausados e escalados; os SKUs F, do Fabric, também servem para incorporação.
• Quem publica: os desenvolvedores que criam e publicam os relatórios continuam precisando de licença Power BI Pro ou equivalente.
• Quem consome: no cenário de incorporação para clientes, o usuário final do portal não precisa de licença do Power BI.
• Cenário interno: na incorporação para a organização, cada usuário normalmente precisa de licença, a não ser que o conteúdo esteja numa capacidade grande o bastante para liberar leitores sem licença paga.

O tamanho da capacidade depende do volume de dados, da complexidade do modelo, da frequência de atualização e de quantas pessoas abrem relatórios ao mesmo tempo. Um bom projeto começa pequeno, mede o uso real e só depois ajusta.

Como funciona o controle de acesso num portal?

Num portal de relatórios, a pergunta não é só quem entra, mas o que cada pessoa vê depois de entrar. São três camadas que trabalham juntas.

1. Login: o usuário entra no portal com Microsoft, Google ou o login da própria aplicação, e o portal sabe quem é a pessoa.
2. Catálogo: o portal decide quais relatórios aparecem no menu de cada perfil. O gerente comercial não vê o relatório de folha de pagamento, por exemplo.
3. Linhas: dentro do relatório, a segurança em nível de linha (RLS) filtra os dados. O portal informa ao Power BI a identidade do usuário ao gerar o token, e o modelo mostra só as linhas permitidas.

A terceira camada é a mais sensível. Ela deve ser feita no modelo, com uma tabela de permissões, e não com filtros escondidos na página, que podem ser removidos. Explicamos o passo a passo no artigo sobre RLS no Power BI.

Um portal bem feito também registra auditoria: quem acessou, qual relatório abriu, quando e o que exportou. Isso ajuda na governança e na LGPD, porque mostra que o acesso a dados pessoais é controlado e rastreável.

Como montar um portal de relatórios passo a passo

1. Liste os públicos e o que cada um precisa ver: perfis, recortes de dados e quais relatórios entram no menu de cada um.
2. Organize os relatórios: um modelo de dados confiável por assunto, publicado em workspaces separados para desenvolvimento e produção.
3. Defina a RLS no modelo, com uma tabela de permissões alimentada pelo cadastro de usuários do portal.
4. Crie a identidade de serviço (service principal) no Microsoft Entra ID e dê a ela acesso aos workspaces de produção.
5. Provisione a capacidade no Azure ou no Fabric e associe a ela os workspaces de produção.
6. Desenvolva o portal: login, menu por perfil, geração do embed token no servidor e exibição com a biblioteca JavaScript do Power BI.
7. Aplique a identidade visual: cores, logo, domínio próprio e, se fizer sentido, modo claro e escuro e mais de um idioma.
8. Teste com usuários reais de cada perfil, confira o que cada um enxerga e só então libere o acesso para todos.

Uma regra prática: o token de incorporação deve ser gerado sempre no servidor, nunca no navegador. As credenciais da identidade de serviço não podem aparecer no código que vai para o usuário.

Quais erros evitar?

• Usar a opção Publicar na web para clientes. Ela gera um link público, sem login, que qualquer pessoa pode abrir e compartilhar.
• Duplicar um relatório para cada cliente em vez de usar RLS. A manutenção cresce a cada novo cliente.
• Fazer a segurança só no portal, escondendo menus, e deixar o modelo sem RLS.
• Dimensionar a capacidade por um pico imaginado, sem medir o uso real.
• Esquecer a atualização dos dados. O portal mais bonito perde a confiança se os números estiverem atrasados.
• Manter o cadastro de usuários manual e sem revisão. Quem saiu da empresa ou do contrato precisa perder o acesso.

Power BI Embedded ou dashboard em HTML?

Nem todo relatório de um portal precisa ser Power BI. O Power BI é ótimo para análise, filtros e exploração. Painéis em HTML e CSS fazem mais sentido quando a experiência precisa ser muito específica, leve no celular ou integrada às telas de um sistema. Comparamos os dois caminhos em dashboard em HTML ou Power BI.

O ponto é que o portal pode receber os dois. O usuário encontra no mesmo menu os relatórios em Power BI, os painéis em HTML e até links para relatórios externos, com o mesmo login e as mesmas regras de acesso.

Como a Wolkee ajuda

A Wolkee entrega painéis em Power BI ou em HTML/CSS dentro de um portal com a marca do cliente: login com Microsoft ou Google, menu por perfil, RLS no modelo, auditoria de acessos e integração com os sistemas de onde vêm os dados. Você pode explorar um portal de exemplo, com dados ilustrativos, na página de dashboards e Power BI.

Se a distribuição dos seus relatórios virou um problema, comece por um diagnóstico gratuito de 30 minutos. Entendemos quem precisa ver o quê, olhamos o licenciamento atual e indicamos o caminho mais simples para o seu cenário.

Perguntas frequentes

Quanto custa o Power BI Embedded?

Depende da capacidade contratada, e não do número de usuários do portal. O preço varia pelo tamanho do SKU, pela região do Azure e pelo tempo em que a capacidade fica ligada, já que os SKUs A podem ser pausados. Somam-se as licenças Pro de quem publica os relatórios. Use a calculadora de preços do Azure e confirme os valores vigentes com a Microsoft.

O usuário do portal precisa de licença do Power BI?

Não, no cenário de incorporação para clientes. Nele, a aplicação se autentica no Power BI com uma identidade de serviço e o consumo é coberto pela capacidade. Quem acessa entra com o login do portal. Já na incorporação para a organização, em que cada pessoa usa a própria conta Microsoft, normalmente é preciso licença por usuário, salvo em capacidades de maior porte.

Dá para usar o Power BI Embedded com o Microsoft Fabric?

Sim. As capacidades F do Microsoft Fabric também permitem incorporar relatórios do Power BI em aplicações próprias. Isso é útil quando a empresa já usa o Fabric para engenharia de dados, porque o lakehouse, os modelos semânticos e os relatórios ficam na mesma plataforma. A escolha entre SKU A e SKU F depende do restante da arquitetura e do volume de uso.

Power BI Embedded é seguro para dados de clientes?

Sim, desde que a implementação siga as boas práticas. O token de incorporação é temporário e gerado no servidor, a RLS no modelo garante que cada cliente veja só os próprios dados e o portal registra quem acessou o quê. O risco aparece em atalhos, como usar Publicar na web ou filtrar dados apenas na tela.